10.2 J2EE Management

Although all J2EE application server products must adhere to the specifications and pass the compliance tests, the details of their internal architecture and implementation are all quite different. Some server products employ many processes to create a virtual application server; others use a single process for a server. Some are 100 percent Java implementations ; others include significant doses of native platform code.

These architectural differences are important because it is in this area where vendors have the opportunity to demonstrate the value of their product over other compliant servers. The fact that the same application can run in many different application servers does not imply that it will run with the same efficiency or reliability in all of them. So J2EE application server vendors are always struggling to find areas where they can excel without straying from the specification and breaking application portability. One of these areas is product and application management.

The lack of a common management service definition in J2EE did not significantly affect early adopters. Most people were consumed with understanding the details of how to use the specification to create applications that were portable and had the proper architecture to perform well under heavy use. However, as the specification matures and more companies have followed it as their application development standard, the lack of any common tools for management has become a more troublesome issue.

The first step toward a common application server management system is to define a management model that all vendors can agree on. This is the motivation behind the J2EE Management specification (JSR 77). ^[9] This specification represents a model of the J2EE application server, and its subcomponents, that all J2EE-compliant application vendors are required to expose. Regardless of their true internal architecture, all application server vendors will have to expose a set of management objects that follow the JSR 77 model.

According to the base J2EE specification, application servers consist of special containers that provide an operating environment for the application components deployed in the server. Application component examples are the EJB module that contains Enterprise JavaBeans, and the Web module that contains servlets and JSP (Web application components ). Prior to the J2EE Management specification, there was no common representation of the EJB module for external management. Some versions of some application server products did not expose the EJB module at all.

The JSR 77 management model includes a representation of the EJB module, as well as all of the other relevant components that logically make up an application server. So when JSR 77 becomes a required subspecification under J2EE 1.4, all compliant application server vendors will expose a representation of the EJB module (and every other object defined by the JSR 77 model). A management tool that can access and manipulate components of one J2EE 1.4 application server product will be able to manage all other compliant application servers.

One detail that may not stand out from a casual reading of the J2EE Management specification is that JSR 77 requires an underlying implementation of JMX (JSR 3). JSR 77 is built on top of JMX. JMX classes and interfaces are included in required interface definitions that are part of JSR 77. The JSR 77 compliance tests use classes defined by JMX. So JSR 77 can be thought of as a specification that takes the general management framework of JMX and defines how it will be used to manage a specific application domain ”that of the J2EE application server.