Introducing A New Vendor-Neutral J2EE Management API

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.

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:

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.

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

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.

Andreas Schaefer is a system architect for J2EE at SeeBeyond Inc., where he leads application server development.

Return to ONJava.com.