IN THIS CHAPTER
For many network administrators, daily activities involve managing a wide variety of hardware devices. An enterprise setting requires the routers, gateways, bridges, and network servers to be managed and be manageable. For network administration, the Simple Network Management Protocol (SNMP) has emerged and established itself as the de facto management protocol. Because service-based architectures, such as J2EE, become more common in these same enterprise environments, a need to manage large software systems has become apparent.
You saw earlier in this book how JMX enables you to manage software components and applications locally as well as remotely. However, the requirements of large software installments, where several dozen or even hundreds of servers, JVMs, and MBean servers are involved, have not been addressed. The efforts to find a uniform way of managing such large systems are the focus in this chapter.
In comparison to the number of devices the network administrator has to manage, the number of software components can become considerably larger. For such systems to be manageable, you need to find ways to present the management information to the administrator in a model that allows him or her to filter and categorize the management information.
The JMX specification itself does not define a management model for large systems, such as those previously described. Issues, such as MBean server federation or management of clustered servers, are not addressed as part of the specification. However, a Java Specification Request has been created for defining a management model for the J2EE platform. The expert group working on this specification, JSR-77, aims to define a management model for large installments of J2EE servers. The specification request reached a public review status in the of Fall 2001 and, hopefully, by the time you are reading, it has reached the final status.
In the second part of this chapter, you will go through what the JSR-77 expert group has specified at this stage of the process. It should give you a good idea regarding how the expert group sees the management of the potentially complex, service-based J2EE platform.
As was mentioned, the JMX specification does not have any notion of a set of computers or a set of software components that are distributed across several JVMs. If a management client needs to manipulate several resources that are all distributed across different physical nodes and MBean servers, you need to individually connect to all the relevant servers from the management client. This complicates the implementation of the client, because it has to deal with the complexity of communicating to several MBean servers at the same time.
What would be more desirable from the management client's point of view would be the ability to have one common logical view of the entire distributed system (see Figure 11.1). This would allow the client to deal with one connection and MBean server only and keep the implementation simpler at the management client. On the server side, the added complexity of a distributed environment can be handled transparently to the client application. A single MBean server would be able to service all the requests of the client and forward them to the correct nodes and MBean servers that host the requested resources.
To implement a federation between MBean servers, a simple proxy-based design can be used. You can build a common view of all distributed components of a system by having a proxy represent each component. The proxies can then forward any requests for specific components to the server that actually hosts the required component. This enables the client to be unaware of the topology and the location of managed resources across distributed MBean servers.
The federation itself does not reduce the number of software components the administrator needs to manage. A federated management system gives a single view to the entire group of servers. In many cases, however, it would be desirable to actually lessen the number of individual manageable components. If the individual components can be represented as logical groups, it will allow management operations to be easily performed to a group of resources. For example, the administrator can target a specific group of user resources instead of executing the same management operation one-by-one on a single managed user resource.
To ease the task of the administrator, you need to reduce the number of components that must be managed. You can achieve this by forming groups of managed components that represent the same type of resource with identical or similar management interfaces. You can then expose the group of components to the administrator as one logical entity that the administrator can manipulate.
A group of managed resources represented as a single logical entity allows the administrator to perform group operations on them. A group can be managed in synchronization instead of as several separate units. You can build groups and hierarchies of managed components that are easily managed via simpler interfaces.
To implement the logical view, you have the following three options:
The client management tool connects to all servers, and creates and presents the logical view to the user. This enables the client to connect to different applications/components and still provide a logical view.
A separate server connects to all the servers, and creates and presents the logical view to the client management tool.
A component on the cluster presents the logical view.
The first implementation is a little bit tricky, because the tool can miss a server when the client did not add all servers to the cluster. Either the client can look up all the participating servers on a JNDI-server or at least find an object delivering this information.
The second implementation does not rely on the cluster because the application or component presenting the logical view runs outside the cluster. Consequently, you can manage the cluster without having the cluster running. The downside is that when the server goes down, there is no administration anymore.
The third implementation runs inside the cluster and can also be clustered to increase the uptime of the administration as well, but the cluster has to run to be able to manage the application.
As was mentioned at the beginning of this chapter, the JMX specification does not define the model for forming logical groups or hierarchies of managed resources. Such a model would be required for management applications to be able to discover group management information without relying on management domain specific conventions. Advanced configuration and management of software systems that involves clusters of servers and services are, therefore, left outside the scope of the JMX specification.
The J2EE specification defines a distributed, service-based platform architecture. However, as far as management of the platform goes, there has not been an effort to standardize the management architecture or model for the J2EE platform implementations so far.
In the J2EE specification, the System Administrator is mentioned as one of the platform roles, but the administration of the platform is not defined. As a result, there is no vendor-neutral J2EE system administration today. Instead, the administrators are focusing on specific implementations of the J2EE platform, because no management model that would allow all the J2EE implementations to be managed in a consistent manner exists (see Figure 11.2).
The JSR-77 took on the task of defining a management model for the J2EE platform. The specification was created to meet the following requirements:
Support to manage any resources defined in the J2EE specification, such as EJB-Container, Web-Container, JMS, Connector and Connection Pools (JDBC as well as EIS), and so on
Support to deploy applications (EJBs, servlets and JSPs, Connectors)
Support to start and stop any resources and applications at runtime
Support to get runtime information about the performance and resources of the application server, such as memory, heap size, number of threads, size of bean pool, size of active beans, and so on
Note
At the time of this writing, the JSR-77 had just been closed for the community review but had not yet entered the public review state. You can follow the progress of each specification request at http://www.jcp.org.
The JSR-77 expert group created a specification for a management interface for J2EE application servers.
What then is the idea is behind JSR-77? The Java 2 Platform, Enterprise Edition Management Specification will provide server vendors and tool vendors with a standard model for managing the J2EE Platform.
In a little more in detail, the Specification proposes a standard management model for exposing and accessing the management information, operations, and parameters of the Java 2 Platform, Enterprise Edition components.
The management model will:
The JSR-77 specification defines a model layer (or metadata layer) defining the information layer and describing the format and semantics of the data. All models combined build up the meta model of the J2EE platform. It also describes the meta model layer (or meta-metadata layer) defining the model layer, describing the structure and semantics of the metadata. This meta model is described by the associations and cardinalities of the J2EE Management Model components.
JSR-77 does not deliver objects from the J2EE application server but instead delivers a representation of the logical view of the J2EE application server. Most parts of the specification do not talk about a particular server but of the logical view grouping all the participating servers together. You can manage one or many servers under the one logical representation. This enables the management provider to build the application accordingly because it is guaranteed that the J2EE server has to be compliant.
The specification is composed of four parts:
Event model required by the managed objects that emits events, whereas the implementation is optional
State management model required by managed objects to optionally support state manipulation and, if so, it also emits events
Performance monitoring model required by managed objects that optionally supports state manipulation
Each managed object specifies if it emits events, maintains a state (state management), or provides performance-monitoring data. Every managed object maintaining a state also automatically emits events.
Every object represented by JSR-77 implements the J2EEManagedObject, which provides its name and states which of the optional models (events, state management, and performance monitoring) it implements or supports.
A JSR-77 represents one management domain containing a list of applications, servers, and deployments, which is a temporary object available during the deployment of an application. The application contains modules, such as a Web module, EJB module, and Connector module. Each of these modules represents an appropriate archive—Web Archive (WAR), Java Archive (JAR), and Resource adapter Archive (RAR), whereas the application represents the Enterprise Application Archive (EAR) (but can also be the container for one single module archive). The server represents an application server cluster containing the deployed applications, resources (JNDI, JMS, URL, JTA, JavaMail, JDBC, RMI, and IIOP) and the nodes, which are the physical computer.
All J2EEManagedObject emitting events implement the EventProvider interfaces specifying a list of event types that they emit. The event (J2EEManagementEvent) contains the source (J2EEManagedObject), time, sequence, type, and message. The type is a dot-separated list of names (like the package name in Java). All types prefixed with j2ee. are reserved for events emitted by the components of the management system implementation, such as j2ee.object.created. All types prefixed with state. are reserved for state manageable objects, such as state.starting. Otherwise, the event source is free to be named as you want.
A J2EEManagedObject supports the state management and must implement the StateManageable interface delivering the current state, the time the object was started, and the operations start(), startRecursive(), and stop().
The performance data framework allows the client to get information about the performance of the managed objects. Each J2EEManagedObject providing performance data must implement the StatisticsProvider interface providing a list of Stats. Note that the performance data of a managed object are bundled in a Stats. Each Stats contains a list of Statistic objects that represents a statistic value. There are the following types of statistics: Count-, Boundary-, Range-, BoundedRange- and TimeStatistic. The StatisticsProvider interface provides a list of Stats instances.
The JSR-77 requires each implementation to provide an implementation of the Management EJB, which must be deployed on at least one server. The design of the MEJB is nearly a 100% copy of the JMX MBeanServer with some changes made by adding the J2EE prefix to some class names.
Maybe you are a little bit puzzled why anyone would go the whole nine yards to come up with something similar to JMX but not utilize JMX. One of the reasons is that the JSR-77 group didn't want to bind JSR-77 together with JMX because there are not requirements in the J2EE specification to do so. On the other hand, an EJB can be deployed on each J2EE-compliant application server, but it also provides a distinction between these two. JMX hosts any JMX-compliant MBeans, but the MEJB should only provide J2EE managed objects compliant to JSR-77. Note that in the MEJB, the MBeans are replaced by J2EEManagedObjects, Notifications are replaced by events, and state management and performance monitoring are additional.
As said earlier, the MEJB does not return any J2EE-related instances but only information about the specified managed objects. That is why JSR-77 talks about a model and not about Java instances. The following is an example:
Client obtains the remote interface of the MEJB Session Bean, which represents the management domain the client wants to manage.
Client retrieves all the attributes of the management domain, which is the list of deployed applications, the participating clusters (logical server), and applications in the process of deployment.
All items in this list are themselves managed objects, so the MEJB only returned their object names. Thus, the client can navigate through the list of deployed applications. Each of them is of type object name.
Client retrieves the attribute of the managed object referred by the object name (as in JMX where the client retrieves the attributes of an MBean by the object name).
The attribute of the deployed application is a list of modules that are managed objects as well, so an object name is returned instead.
Client retrieves the attributes of a cluster, which is a list of deployed applications, resources, nodes, ports, and JVMs. In addition, it also supplies the name of the J2EE server vendor. All attributes (except the name of the server vendor) are a list of object names. The server vendor name is returned as
Stringbecause its value describes an attribute of the cluster and not another managed object.
The JSR-77 client has to do the following simple steps:
Get the remote interface of the MEJB of the management domain on which the user wants to work.
Get the attributes of the management domain.
Check if an attribute is an object name and, if so, prepare to retrieve its attributes when requested.
Allow the client to set attributes on the managed object. The JSR-77 client has to convert a reference to another managed object into an object name.
Allow the user to invoke methods on the managed objects, which is an invocation of the method on the managed object referenced by the object name.
Allow the user to listen for events emitted from any managed object emitting events, but the user has to register a listener to receive those events.
Of course, the programmer can hide all these conversions and mapping behind a set of Java instances that would create a nearly transparent view to the management domain. Now a JSR-77 client works on an application server like a management tool running in the same JVM (works like a JMX Connector).
On the other hand, an HTML client can be easily created by displaying the object names as links to another page and the other attributes as simple text on the current page, which would look like the HTML-Adaptor of JMX-RI.
JSR-77 does not really provide an API (except the classes for the MEJB and the appendixes), but it provides a model the client can use to investigate and work on the application server it manages. Thus, any JSR-77 client can let a user manage any JSR-77–compliant J2EE application server. This allows companies specializing in building management tools to create one management tool to manage all compliant application servers. When JSR-77 becomes part of the J2EE specification, this will mean all application servers.
On the other hand it frees the J2EE application server vendors from creating a management tool of their own. They can simply provide a JSR-77 implementation and rely on existing management tools implemented by third-party vendors.
Finally it enables an application server administrator to manage different vendors with the same tool, the same knowledge, and from the same place.