Increased demands to meet customer service-level agreements often put a great burden on IT to deliver a robust architecture for application management. Organizations wishing to deploy a management solution must consider a number of important requirements. For instance, sufficient monitoring must be in place to ensure the availability, performance, and system health of deployed applications and business processes. Additionally, management solutions must allow IT to control and configure applications. This control is vital to ensuring that the deployed assets can adapt to change over time.

Meeting these management requirements becomes even more difficult as organizations must manage components that are distributed and deployed on heterogeneous operating systems, platforms, and languages. IT management often requires the merger of a variety of management technologies, standards, and tools to successfully manage these IT assets. Some of these management standards, such as JMX and WMI, define standard interfaces for a particular platform that are resource specific and do not generally interoperate well.

The Web Services Distributed Management (WSDM) Technical Committee was formed within OASIS to meet these challenges. This committee's charter is to define protocols for managing distributed resources using Web services standards and to develop a model for representing Web services as a manageable resource. As a result of this work, many organizations are asking questions such as "How can I leverage WSDM in my development?" and "Should I abandon JMX development in favor of WSDM?"

JMX and WSDM can and should fulfill an important role in the management of your IT environment. JMX is a key technology for instrumenting Java applications with manageability, and WSDM can serve as the overall interaction technology between your management systems and managed resources.

This article offers you further guidance on the use of these two management technologies in a single management ecosystem. We begin by reviewing the current state of JMX and WSDM. We then present specific challenges in mapping from JMX to WSDM. We present one potential solution to this mapping problem, followed by specific steps that you can take with JMX today to be better prepared for WSDM tomorrow.

Overview of Java Management
We will begin surveying the state of the Java Management Standards and the work done by the Java Community Process (JCP) to support management in both the J2SE and J2EE platforms.

The JMX 1.2 specification, defined in JSR 3, was initially created to specify an API and overall management architecture for the Java platform. The architecture, illustrated in Figure 1, consists of three distinct layers:

• Instrumentation layer: Responsible for encapsulating management resources using MBeans. MBeans are Java objects that implement resources and their instrumentation and follow the design patterns and interfaces defined in the JMX specification. The JMX specification defines four types of MBeans: standard, dynamic, open, and model MBeans.
• Agent layer: Contains an MBean Server that acts as a registry for MBeans, allowing clients to locate and access them through a standardized interface. All management operations on MBeans are brokered through the MBean Server. Additionally, the Agent layer contains a series of additional services (timing, dynamic class loading, monitoring, and relationship) that can be dynamically loaded to extend the functionality of a JMX agent.
• Distributed layer: Contains a series of adapters and connectors that make the JMX agent available remotely. An MBean can be accessed either by local clients residing within the same JVM, or through remote clients running outside the address space of the JMX Server hosting the MBeans. The remote clients could be developed using a programming language other than Java. These clients access the MBean Server and the MBeans through a JMX Connector.

One important feature missing from the JMX 1.2 specification is a standard way for remote clients to access the management capabilities exposed through MBeans. The JMX Remote API 1.0 specification, defined in JSR 160, fills this gap and defines JMX connectors for RMI and an optional JMX Management Protocol (JMX-MP).

JMX-MP is a TCP-based protocol for accessing the MBean Server and MBeans from non-Java clients. A JMX-MP?based JMX connector would allow, at least in theory, non-Java management systems to manage Java applications. In practice, however, this approach is unlikely to find wide industry adoption because it requires implementing a new wire protocol for program-to-program interaction in different languages where many already exist.

You will notice that these specifications only outline the basic management mechanisms and do not define the specific management models, that is, the MBeans and their interfaces, for managing either a J2SE JVM or a J2EE Server. These tasks are addressed through two separate specifications, JSR 174 and JSR 77.

JSR174 defines a management model for a Java Virtual Machine (JVM). This JSR has added management and monitoring APIs in J2SE 5.0 that expose valuable information about the JVM, including health indicators such as memory usage, thread contention, class loading behavior, and garbage collection frequency. With the JMX support added in J2SE 5.0, JMX and RMI connectors are now part of J2SE, and a platform-level MBean Server is available within every JVM. Packaging of the JMX protocol within the JVM makes it much easier to instrument any Java application with manageability.

JSR 77 defines a management model for J2EE Server. This JSR defines a set of managed interfaces for resources exposed within a J2EE Server, including JMS, EJBs, and Web applications. These managed resources define a standard way to model and interact with the J2EE container, including dependencies between objects, and state and metrics on the components.

Overview of Web Services Management
Before making specific recommendations for how to evolve JMX toward supporting Web services management technologies, we should spend a few minutes reviewing the state of Web services and Web services management. It would not be hard to argue that XML and Web services have emerged as the dominant distributed interaction mechanism across heterogeneous platforms over the Internet. Much of this adoption is due to their platform neutrality, extensibility, ease of use, and wide industry acceptance. Broadly accepted standards such as WSDL, SOAP, and UDDI are also helping to drive the use of Web services within and outside corporate boundaries.

The factors that make these technologies attractive for general-purpose distributed applications also make them an excellent choice for exchanging management information. As we have seen with Java management standards, two important things are necessary for developing management standards based on a new technology:

1. The basic mechanisms to format the management information
2. A model to manage the technology itself

To meet these objectives, the OASIS WSDM TC has been working on defining an approach for representing manageable resources using Web services interfaces, in addition to developing a management model of a Web service as a manageable resource. These capabilities are represented in the Management Using Web Services (MUWS) and Management of Web Services (MOWS) specifications, respectively. An important goal of the WSDM work is to provide an extensible architecture that complements existing management technologies (e.g., JMX, CIM, SNMP/MIB) while still offering model neutrality across these heterogeneous interfaces.

The basic architecture of a WSDM-based environment follows the typical SOA-based model of "publish-discover-interact," shown in Figure 2. A manageable resource is represented with a Web services interface using WSDL. This manageability interface is then exposed by a manageability provider. The manageability provider acts as a proxy between the client and the managed resource, enabling clients to execute management operations. The additional steps of describing the management interfaces, interacting between clients and management providers, discovering the endpoints, and securing the overall interaction are addressed by applying the corresponding Web services technologies.

MUWS defines a wire-level specification for managing distributed resources based on Web services technologies. It relies on a number of open standards, including XML, WSDL, SOAP, and UDDI. Additionally, the specification incorporates new standards such as WS-Notifications and WS-ResourceProperty.

Besides supporting traditional request-response interactions for invoking operations and accessing attributes, managed resources must also be able to send out one-way asynchronous notifications. Support for notifications is defined within the WS-Notifications specification.

While the Manageability Endpoint operations are describing using WSDL, the management capabilities, or attributes, are defined using resource properties as defined within the WS-ResourceProperty specification. A management capability could represent any number of aspects of a management interface for a resource, including:

• How do I distinguish among manageable resources?
• How do I get metrics (e.g., performance data) about a manageable resource?
• How do I monitor and configure manageable resources?
• How do I control (start, stop, restart) manageable resources?
• How is one manageable resource related to another manageable resource?

Figure 3 shows the relationships among some of the entities defined within the MUWS specification. Listing 1 outlines a few examples of how resource identity, state, and metrics can be represented using the MUWS specification. The Identity type is used to distinguish among manageable resources, ResourceState defines operations for starting and stopping the service, and the Metrics identify the metrics for the managed resource. These management capabilities help in exposing the management model for a resource, and MUWS offers the appropriate constructs for this model to be exposed in a standard way. It is important to keep in mind that WSDM MUWS does not define a management model but has constructs to expose such models.

JMX for Instrumentation, WSDM for Interaction
The WSDM MUWS specification is being developed primarily as a single, standards-based mechanism for management applications to interact with manageable resources. Yet it is also clear that MUWS is not intended to replace JMX-based instrumentation or other similar technologies. As Figure 4 illustrates, MUWS can serve as a bridge to these existing instrumentation technologies, including aspects of SNMP/MIB, CIM, JMX, or other proprietary management frameworks.

It should be evident that JMX continues to be a very relevant standard for instrumenting Java-based applications, even with WSDM in the picture. WSDM MUWS is not a programming language API, and developers still need the capability to instrument their applications with the appropriate messages, metrics, and control mechanisms; JMX clearly serves this purpose. But for more general management interactions (e.g., across applications, management systems, or managed resources), a more cross-platform, standards-based interface is required. For example, if you had a requirement to aggregate JMX resources with WMI resources in a distributed manner, this would not be a straightforward task. The WSDM MUWS specification provides the needed mechanism and platform neutrality to address this challenge.

The complementary nature of JMX-based instrumentation and WSDM-based interaction among managed applications and management systems is clear. However, to make integration a reality, developers need a mechanism to expose their JMX-instrumented applications using WSDM interfaces. Referring to the JMX architecture, this mapping could be addressed through a JMX-WSDM connector. Developers could use JMX to build manageability into their applications, and WSDM-compliant managers could be used to manage these applications through a JMX-WSDM connector.

Challenges
Creating a bridge between JMX and WSDM may appear to be a trivial matter. However, in practice, a number of factors complicate the mapping process. We have already discussed the lack of JMX APIs for exposing management models in standard manner. There are also some other difficulties in mapping from JMX to WSDM, as well as some specific WSDM constructs that are not present in JMX today.

Inadequate support for exposing management models.
As we noted earlier, the WSDM MUWS specification has the notion of a state model, metrics, and relationships that allow a management model to be exposed in a standard way. Today JMX does not support these capabilities at the same level, often leaving the architects or developers to create the necessary APIs on a per-project basis. This situation can be problematic, making it almost impossible to create a simple, automated way to translate any JMX-exposed management model through WSDM.

This isn't to imply that JMX cannot be used to expose a well-designed management model. But it is hard for a client to extract that model by simply using the available JMX APIs. The good news is that work is being done to expose management models via JMX. The J2EE Management specification, for example, exposes a J2EE Server management model built on JMX.

Data type impedance mismatch.
A JMX MBean in its most general form can use complex Java objects to represent attribute values, operation arguments, return values, and JMX notification fields. While WSDM offers support for complex types, automated translation from a JMX type to an appropriate XML Schema data type is not always straightforward.

In fact, this data type mismatch is problematic even in an all-Java world. The management application requiring access to the MBean needs to load the JAR files provided by the managed application. With such tight coupling, it can become quite challenging to manage two different applications instrumented with different versions of an MBean. The use of XML and Web services, by way of MUWS, can offer some assistance in shielding the client from being aware of these complex types.

Complex mechanism for relationships.
Relationships between managed resources are an important aspect of any management model. JMX supports the notion of relationships through its relationship service and Relation MBeans, but it is cumbersome to use in practice. Both the J2EE and JVM management models built on JMX do not currently take advantage of the relations construct. Although the details of how WSDM would represent relationships are not yet available, it is unlikely that there will be a one-to-one mapping with JMX.

Given these challenges, it would seem there are a few aspects of the base JMX specification that might make it difficult to support WSDM MUWS. Additionally, it may not be clear what you as a developer or architect should be doing in the JMX world to better prepare yourself for WSDM. To address both these concerns, let's turn our attention to some of the existing JMX-based management models, followed by a discussion of best practices that you can follow in your development today.

Towards the Solution
Earlier, we briefly discussed additional work being done in the JMX community to support management models. JSR 174 and JSR 77 define management models for the JMX and J2EE Server respectively. Let's take a minute to see how these models address some of the inherent limitations in JMX.

JSR 77 defines a set of conventions and classes for representing a J2EE Server management model. This includes support for a state model, notifications, and metrics:

• Mandatory attributes: Defines a set of mandatory attributes to allow a client to easily introspect the management model. These attributes identify whether the object supports a state model, metrics, notifications, etc. This support simplifies the step of automating the mapping between JMX and WSDM.
• State model: Defines the operations, state values, and valid state transitions for any managed resource that supports a state model. Supported operations might include deploy, undeploy, etc.
• Event notifications: Defines any notifications to be exposed by a managed resource, including state model transition and other changes in the management model.
• Metrics: Represents metrics to be exposed by a managed resource. To support this, a resource sets a mandatory attribute and implements an interface that allows a client to query about available metrics.
• Relationships: Describes containment relationships between objects. For example, a container-managed resource would typically store the list of contained managed resources in an array attribute.

Furthermore, the J2EE Server management model avoids the problem of data type impedance mismatch by restricting itself to only primitive types and data types defined in the specification itself.

For the JVM management model, JSR 163 introduced the notion of MXBeans. MXBeans are managed beans that conform to the JMX Instrumentation Specification and use only a specific set of data types. For example, MXBeans are provided to monitor and track memory consumption (via the MemoryManagementMXBean, GarbageCollectorMXBean, etc.) and CPU usage (via the ThreadMXBean, RuntimeMXBean, etc.)

One advantage of MXBeans is that they can only use a set of basic data types that can be marshalled and unmarshalled in a platform and programming language-neutral manner. These data types include primitive types (int, long, boolean, etc.) and their associated wrapper classes (Integer, Long, Boolean, etc.), enumeration classes (Enum), and classes that define a mechanism to convert from an input CompositeData class to an instance of that class. Additionally, List and Map types are supported as long as the contained objects are primitive types, wrapper classes, enumerations, or a class supporting CompositeData conversion.

Note that most of these data types are not specific to the JVM or J2EE Server management model, and they can help guide the definition of a management model for any Java-based application.

Mapping JMX to WSDM
Based on our discussion so far, let's take a stab at defining a very high-level mapping from JMX to WSDM. This mapping is shown in Table 1.

We acknowledge that we have glossed over many details and that the actual mapping of various JMX classes to WSDM MUWS structures might require a bit more work. But even this minimal mapping gives us a feel for how JMX and WSDM could work together.

However, before you rush to develop your own connector between JMX and WSDM, it is important to realize that several questions need to be answered:

• Should every JMX MBean map to a manageability provider? The existing JMX instrumentation mechanism does not use MBeans as a proxy for real managed resources. By blindly making every MBean a WSDM Manageability Endpoint, we may end up with a large number of MUWS Manageability Providers that do not conform to the spirit of MUWS.
• How do we handle Java data type mismatches? As per the JMX specification, developers are free to create their own Java classes for MBean attribute types, MBean operation parameters/return values, and JMX notification fields. The mapping doesn't specify what to do about Java classes that lack a straightforward counterpart in XML.
• How should we handle JMX relationships? Given the state of the MUWS specification today, is it appropriate to map a Relationship MBean to a Manageability Provider?
• How does this mapping account for a state model and metrics?

Clearly, our mapping mechanism doesn't fully represent how JMX and WSDM would work together. There is still much to be done by the Java and WSDM communities to clearly define how these two management technologies would work together. In the meantime, it is still possible to adhere to an MBean design that would allow a much smoother transition to a WSDM-based management architecture.

JMX Development Guidelines
Many software projects focus on implementing the important functional requirements for an application. Often, these stated requirements do not consider manageability aspects of the application in the production environment. Applications "thrown over the wall" to production often leave the IT operations group with little information to guide them toward resolving application problems. In situations where the application has not been designed with manageability in mind, developers are frequently called in to help resolve these IT support problems.

We firmly believe that in today's complex and distributed world, manageability must not be an afterthought in the development process. Application manageability must be embraced early in the application development life cycle. And even if you are not considering WSDM in your design, the most important guidelines that we can provide are to first think about designing for manageability, and to understand which management technologies are most appropriate to address these concerns.

JMX defines a very powerful manageability architecture and API for Java applications. In fact, most J2EE platforms are being built with robust JMX mechanisms. Still, there are cases where an additional level of instrumentation is required to expose application-level manageability interfaces. If you are thinking of using JMX, you can refer to the following guidelines. These guidelines help pave the way for embracing WSDM in the future as well as improve the overall quality of a JMX-instrumented application.

1.  Do not fall into the trap of creating a JMX MBean for every single business object in your application. Instead, strive to cleanly separate MBean interfaces from the implementation-level business objects. Ideally, create MBeans as entities that expose management operations on resources that you would want to manage from an external management application. Use of the facade and proxy patterns can also help to expose the right management interface.

2.  As we have pointed out here, there are many challenges involved in managing data type conflicts between WSDM MUWS and JMX. To address these challenges, avoid using complex data types wherever possible. JSR 174 and the MXBean interface define a strict set of guidelines for interoperable data type usage. We recommend that to minimize mapping issues, you follow those guidelines in the development of your own MBeans.

3.  Finally, we have identified some gaps in JMX as it relates to support for state and metrics. Being able to define these manageability capabilities is essential for enabling an application to be managed, monitored, and controlled. Examine the conventions defined in JSR 77 and apply some of the same principles in your MBean design.

If you already have a JMX-instrumented application that does not follow the above guidelines, you can achieve a greater degree of interoperability through design patterns and frameworks. For example, you can create a Wrapper MBean around your existing MBeans to conform to some of these guidelines. By exposing your JMX instrumentation in a standard way, you can support WSDM management interfaces more easily in the future.

What's Next?
As demonstrated here, we are still far from the dream of using JMX as the instrumentation technology and WSDM as the interaction technology. To move toward making the dream a reality, we make the following recommendations to the Java community:

1. The JMX specification should be enhanced to support MXBeans and the capabilities from JSR 77 that help in representing a management model. This would allow application developers to reuse these APIs in a standard way. It would also be helpful to simplify the current JMX mechanism to support relationships.
2. A JMX-WSDM connector specification should be developed through the JCP so that any JMX-instrumented application becomes WSDM-manageable without any additional effort on the developer's part.

This article provided a solid background on JMX and WSDM as well as guidelines and best practices for using JMX in preparation for WSDM.

References

For more on what HP is doing with JMX and WSDM, visit HP's developer resource portal (devresource.hp.com).

Java Management Extensions: Instrumentation and Agent Specification: http://jcp.org/aboutJava/communityprocess/final/jsr003/index3.html

Java 2 Platform, Enterprise Edition Management Specification, JSR77: http://java.sun.com/j2ee/tools/management/reference/docs/index.html

Java Management Extensions (JMX) -- Remote API 1.0 Specification: http://jcp.org/aboutJava/communityprocess/final/jsr160/index.html

MXBean description: http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ management/ManagementFactory.html

WSDM MUWS Working Draft: www.oasis-open.org/committees/download.php/ 8464/wd-wsdm-muws-1.0-20040803.doc

WS-ResourceProperty specification: http://docs.oasis-open.org/wsrf/2004/06/ wsrf-WS-ResourceProperties-1.2-draft-04.pdf

Web Services Notification specifications: www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn

• Figure 1
• Figure 2
• Figure 3
• Figure 4
• Source Code
• Table 1