Introducing A New Vendor-Neutral J2EE Management API

Listen Print

Introducing A New Vendor-Neutral J2EE Management API

by Andreas Schaefer
03/27/2002

Through J2EE it became possible to create nearly vendor-neutral applications. These parts, which were still vendor-specific, were extracted in files, which could be adjusted during deployment of the application. For developers, this is great, but the development is only one part in the life cycle of the application. The management of the various J2EE application servers is especially difficult because every vendor has its own tool, which usually varies from version to version (see BEA WebLogic 5 and 6).

In December 2001 Sun released for public review JSR-77, which promises to create a vendor-neutral API to manage J2EE application servers. This should enable J2EE vendors to implement this API and other software companies to use this API to create management tools to manage all JSR-77-compliant J2EE servers.

Java Management eXtension (JMX) enables Bean developers to also provide a management interface, which the user can then incorporate into his management tool. What JMX doesn't do is to specify the meaning behind the management interface. Therefore, the client has to investigate the interface at runtime and then provide a management UI dynamically. JSR-77 now specifies the management interface; therefore, the management tool can be more specific for the J2EE environment. In addition, it defines how the information is made available to the remote client(s).

Differences Between JMX and JSR-77

Note that JSR-77 does not provide Java classes for its implementations (with some exceptions). It does provide a model and a meta-model of how the data is presented to the client. The model describes how the data is grouped together into objects and how the objects are related to each other (inclusive cardinalities).

Since JSR-77 does not provide classes, the term object should not be associated with Java instances. Here, it just means a group of information representing a logical object of the J2EE server, such as a Web module, a JNDI service, a computer, and so forth. Because of the general nature of JSR-77, it does not have to represent physical objects when the application server is built differently.

Also noteworthy is the fact the JSR-77 does not have a notion of an agent. Each J2EE server provides one or more points of access for remote clients. The Management EJB is required but JSR-77 also contains specifications for the SNMP and CIM protocols.

Introduction to the JSR-77 Model

The objects in the JSR-77 model are created by:

Object Name (containing a domain name and a list of key-value pairs)
Basic Data Types
Strings
Arrays of object names, basic data types and strings
start(), startRecurvise(), and stop() methods
Stats (containing a set of statistics, depending on their source)

Object Name

An Object Name references another object, like the ObjectName in JMX does. It contains a domain name that is the same for all objects in the same J2EE server. Then it contains a key "type," which indicates the type of object it represents (EJBModule, EntityBean, ResourceAdapter, etc.) and a key "name" with the name of the object. Finally, it contains a list of key-value pairs where "key" is the type value and the "value" is the name value of their parent objects.

Basic Data Types and Strings

Except for Stats and Statistics, all objects in JSR-77 contain only Object Names, Basic Data Types, and Strings and their arrays.

`Start()`, `StartRecursive()`, and `Stop()` Methods

Each StateManageable object in JSR-77 can be started, along with all of its children, or stopped, which also stops all of its children. It also has to provide its current state.

Stats and Statistics

Each Statistics Provider object in JSR-77 provides statistics about itself. The information is grouped into Stats, which are tailored for each managed object. There are Stats like JTAStats, ServletStats, and JavaMailStats. Stats contain Statistics representing particular information like destroyCount (CountStatistic), activationTime (TimeStatistic), or freePoolSize (BoundedRangeStatistic).

Managed Objects

After all this dry stuff, let's dig deep into JSR-77. In this section, we'll take a look at the objects in JSR-77, as depicted in Figure 1.

Diagram.
Figure 1. JSR-77 Objects Overview.

J2EEManagedObject

Figure 1 shows that the J2EEManagedObject contains its own Object Name, and indicates if this object supports state management, is a statistics provider, or is an event provider.

J2EEDomain

Diagram.
Figure 2. J2EE Domain and its related components.

In the J2EE Domain, OBJECT_NAME refers to the related object(s) but it does not contain it as a Java class reference. In JSR-77, the relations also contain a cardinality, which is omitted here. The J2EEDomain contains a list of logical servers (mostly a cluster) and a list of deployed objects that are deployed on at least one server.

J2EEServer

J2EE Server represents a logical application server that is more likely to be a cluster spawning than it is to be one server instance on one box. It contains a list of deployed objects on this server, a list of available resources, a list of computer boxes participating in the cluster, a list of JVMs it uses, and the name of the server vendor.

JVM

This is a representatin of a JVM where Java instances are running and also the computer it is running in.

5. J2EEModule

Diagram.
Figure 3. J2EEModule and its related objects.

J2EE Module is a J2EE-Deployed Object like the J2EE Application. The J2EE Module can be an EJB-, Web-, ResourceAdapter-, or AppClientModule. The EJB Module represents a JAR file containing EJBs; the Web Module a WAR file containing servlets or defined JSPs; the ResourceAdapter Module a RAR file containing resource adaptors; and the AppClientModule a JAR file containing client classes.

The JSR-77 specification contains many more objects (as you can see in the overview) but the concept remains the same. For more information, see the specification.

Events

Just to prevent some confusion: events here are similar in concept to the JMX's notifications or SNMP's trap concept. Any server-side event provider can send the client a message. This prevents the client from polling the server to see if any events are in the queue, and the client can inform the users immediately when the event is received.

Basically any Managed Object can send an event by indicating that it is an event provider (see the J2EEManagedObject.eventProvider() method). Then the client can register a listener for this Managed Object and receive an event when the object sends one. Currently ,it is up to the implementation of the server-side to define how the events are transferred. It can be RMI or JMS, because they come with the J2EE server.

When an object indicates that it is an event provider, it "implements" the EventProvider object, containing a list of types of events it emits. As a reminder, "implements" here means not the implementation of an interface, but merely the providing of another attribute. The Event Provider is defined as shown in Figure 4.

Diagram.
Figure 4. EventProvider and Notification.