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

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.

The client-side listener receives an object as indicated by the definiton of Notification in the picture.

State Management

When an object indicates that it can manage a state (see the J2EEManagedObject.stateManageable() method), it implements the StateManageable object containing an integer indicating the state and the timestamp for when the object was last started. In addition, it implements the start(), startRecursive(), and stop() methods. This start() method starts the object; the startRecursive() also starts all state-manageable children of this object after the object is started; and the stop() method first stops the object and then all of the state-manageable children; therefore, we have no stopRecursive() method.

Diagram.
Figure 5. StateManageable and State Change Diagram.

The State Change diagram (on the right of Figure 5) shows all of the valid changes state can make. The states Starting and Stopping are intermediary states, meaning that an object should not remain in this state for long. Any state change will end up in either Running, Stopped, or Failed.

Performance Monitoring

One of the most important tasks for an administrator is to figure out the performance of the servers and adjust accordingly. Therefore, a big piece of JSR-77 is to provide statistics. Statistics are provided in an object called Stats, which is created by Statistics objects:

Diagram.
Figure 6. StatisticsProvider and Statistics.

Each managed object that indicates it provides statistics (see the J2EEManagedObject.statisticsProvider() method) implements a StatisticsProvider object, which in turn contains a Stats instance. The Stats are tailored for each managed object, as shown in Figure 7.

Diagram.
Figure 7. Stats and its Sub Interfaces.

To show a little bit more what the Stats look like, Figure 8 shows EJB Stats.

Diagram.
Figure 8. EJBStats.

EJBStats is a type of Stats, and for each type of EJB there is a particular type of Stats. The various EJB Stats contains the Statistics appropriate for the managed object they represent. The Stats retrieved from a statistics provider is a snapshot taken in time. The client can evaluate the Stats, but to get a trend, you have to retrieve these Stats over a longer period of time.

Client's View

Up to now we've discussed how a JSR-77 compliant application server offers the management interface, but we did not mention how the client can retrieve the data. According to the specification, you always can retrieve the data from the Management EJB (MEJB). Every server vendor is required to provide this MEJB; thus, you can deploy it on the server and the client can access the management data. JSR-77 also contains the specifications for SNMP and CIM protocols.

Here we want to focus on the MEJB, because it is most likely that a client will be using Java as well (via a Java client- or JSP/Servlet-based Web application). Finally, we can decide what Java classes are used in JSR-77, which are:

  • Notification
  • Stats and Statistics
  • MEJB Home and Remote Interface
  • ListenerRegistration
  • Some classes from JMX, which are Attribute, AttributeList, MBeanInfo, and its contents, ObjectName

Note that for MEJB, the data type OBJECT_NAME maps to the JMX ObjectName.

When you are familiar with JMX, these classes should be well-known with the exception of the ListenerRegistration. This class is provided by the MEJB and allows the client to create a listener that can be registered on the server side, and is able to transfer the notification instance over the wire to the local listener provided by the client.

How the Client Finds the MEJB

Look up the MEJB Home Interface and create the MEJB:

Context c = new InitialContext();
Object o = c.lookup( "ejb/mgmt/MEJB" );
ManagementHome home =
  (ManagementHome) PortableRemoteObject.narrow(
    o,
    ManagementHome.class
  );
Management mejb = home.create();

Find all J2EEApplication managed objects:

ObjectName searchpattern = new ObjectName(
  "*:type=J2EEApplication,*"
);
Set managedObjects = mejb.queryNames(
  searchpattern
);
System.out.println(
  "Found " +
  managedObjects.size() +
  " matching Managed Objects."
);

Get some attributes of the J2EE Application:

ObjectName app =
  managedObjects.iterator().next();
// Is State Manageable
System.out.println( app +
  " is state manageable: " +
  mejb.getAttribute(
    app,
    "StateManageable"
  )
);
// All Modules belonging to the application
ObjectName[] modules =
  mejb.getAttribute(
    app,
    "Modules"
  );

Retrieve the information from a managed object:

Iterator i = managedObjects.iterator();
while( i.hasNext() ) {
  ObjectName name = (ObjectName) i.next();
  //get MBeanInfo and print the info
  System.out.println( name );
  MBeanInfo info = mejb.getMBeanInfo( name );
  MBeanAttributeInfo[] attrs =
    info.getAttributes();
  for( int k = 0; k < attrs.length; k++ ) {
    System.out.println( "Attribute Info " );
    System.out.println(
      "Name: " + attrs [ k ].getName() );
    System.out.println(
      "Type: " + attrs [i].getType() );
    System.out.println( "Value: " +
      mejb.getAttribute(
        name,
        attrs [i].getName()
      )
    );
  }
}

Finally, we want to register a local listener to receive notifications from an event provider:

// Register an event listener
name = new ObjectName(
  domainname +
  ":type=J2EEDomain,name=Andy's J2EE Domain"
);
System.out.println(
  "addNotificationListener( " +
  listener + " ) to " + name
);
ListenerRegistration registry =
  mejb.getListenerRegistry();
registry.addNotificationListener(
  name,
  localListener,
  null,
  "MEJBTester"
);

Vendor-Specific Information

A specification like JSR-77 can be as advanced as possible, but there will be always vendor-specific information that is not included. The specification does explicitly say that a vendor can add its own managed objects, attributes or events, as long as JSR-77 is implemented completely. Because JSR-77 does not specify Java classes, these add-ons do not hurt a client that does not understand these add-ons. The client can ignore them or it can investigate additional objects, attributes, or events. Unless the client knows the vendor's application server explicitly, it can only present the objects or values.

JBoss Implementation Strategy

JMX is the backbone of JBoss, and most of the services are indeed already MBeans. It would also need a lot of resources to manage the managed objects without using JMX, because we would have to code what JMX is already doing. Therefore all of the managed objects in JSR-77 are implemented as MBeans, but to decouple JBoss development from JSR-77 development, the managed objects are created beside the regular MBeans. All of the JSR-77 MBeans contain two static methods:

  • create(): creates an instance of the JSR-77-managed object the method is part of and hides all of the internal knowledge of how to create and register the object.
  • destroy(): removes the JSR-77 MBean.

The purpose of these methods is to decouple the code base as well. Now we only need a reference to the JSR-77 MBean class. Currently we use Standard MBeans, but in the near future we will migrate to Dynamic MBeans to improve performance.

Finally, the MEJB converts a call from a client to a JMX request on the JBoss MBeanServers. This is because JSR-77 objects managing their state with the methods start() and stop() conflict with existing methods in JBoss MBean life cycle. To avoid this, the methods are internally renamed to mejbStart() and mejbStop() and the MEJB Session Bean makes the transition.

Conclusion and Outlook

JSR-77 provides a good foundation for both sides; the application server vendor does not have to create an advanced management tool because any JSR-77 compliant management client can also manage its server, and the software company developing the management tool can create it for any compliant J2EE server. It will certainly provide the administrator with enough common elements to manage many different J2EE servers without learning each server from the ground up.

Currently, JSR-77 is in "proposed final draft" version 2 and the final release will likely come out some time this year.


Return to ONJava.com.