WSDM for J2EE provides next-generation management

The software industry has embraced Web services in a big way and with good reason. Web services is another step toward the goal of language-neutral software interoperability with its loose coupling between the provider of the software service and the consumer of that service. One area where this loose coupling and dynamic interoperability is extremely applicable is IT management. The myriad systems and protocols that expose computer systems management functions beg for a standard to allow interoperability and reuse of the investments made over decades of development.

Through its continued investment in J2EE, Web services, and self-management technologies, IBM has thrown a lot of support behind JSR 077 (for J2EE management) and WS-Distributed Management (for general IT management). Naturally, the questions arise:

• How are these two standards for software management related to each other?
• Are they complimentary?
• Is there any overlap?
• Can the two be merged?

As it turns out, the answer to each question is "yes," including the most important one -- you can gain substantial benefit by combining the two specs to build robust manageability interfaces.

In this article, you learn how the IBM Manageability Endpoint Builder, a component of the IBM Autonomic Integrated Development Environment (AIDE), available from IBM alphaWorks (see Resources), and the JSR 077 API can be used to build a WSDM-compliant manageability endpoint for Java application servers. The final product is a Web application that you can deploy on any J2EE-compliant application server.

A little background on the elements

Let's start by exploring the background of these components:

• WSDM, Web Services Distributed Management
• JSR 077, J2EE Management (plus JSR 088-Deployment, JSR 003-Management Extensions, and JSR 160-JMX Remote API)

What is WSDM?

WSDM is a specification that describes how any product management function can be made accessible through a Web services interface. The WSDM specification was developed by the OASIS standards organization.

Many IT vendors (including IBM and its partners) participate in the OASIS committee that is working to shape WSDM in a way that allows for maximum interoperability between management applications and the IT systems they manage. One of the most important aspects of the WSDM standard is that it begins to lay the foundation of common semantics for IT management by defining a common set of manageability capabilities that can be applied in a consistent way across heterogeneous resources. By defining these capabilities, any management application may effectively interact with resources in a well-defined, predictable manner.

The standard is broadly divided into two sections:

• A general standard for how any management function (also known as a management capability) can be exposed through an interoperable Web services interface. This section of the WSDM specification is known as MUWS (Management Using Web Services).
• If the product being managed is itself a Web service, what attributes, operations, and notifications would it be expected to expose to a management system? This is the topic addressed by the second section of WSDM -- MOWS (Management Of Web Services).

For more background on WSDM, see Resources.

What is J2EE Management (JSR 077)?

The J2EE series of specifications describe a particular kind of software product, the Java Application Server. As the J2EE specifications matured, a set of sub-specifications related to managing this environment were developed by the Java Community Process (JCP) and included in the 1.4 version of the J2EE specification. The Java Specification Requests (JSR) that cover management of Application Servers are:

• JSR 077 - J2EE Management Specification
• JSR 088 - J2EE Deployment Specification
• JSR 003 - Java Management Extensions (JMX)
• JSR 160 - JMX Remote API Specification

The JSR 077 specification defines a set of managed objects that conceptually form the run time of any J2EE-compliant application server. The specification defines a set of Java APIs for accessing and managing these run-time objects. Figure 1 is an illustration of the J2EE-managed objects as defined in JSR 077.

All J2EE application server vendors are required to submit their products to a J2EE Compliance Test Suite (CTS) to certify that their product adheres to the full set of standards. Because JSR 077 interfaces are part of the specification, all compliant application server products implement these interfaces for controlling their product. Whatever value-add features and functions are included in their products, WebSphere®, WebLogic, Oracle, JBoss, Sun, and every other J2EE application server product must support the JSR 077 management set of APIs.

Because all J2EE application server products are required to support a common Java API for accessing their management functions, there is a great opportunity to achieve better interoperability and integration between the different vendors and between the different layers of the enterprise stack.

For more on JSR 077, see Resources.

How does WSDM apply to J2EE?

How are the two standards for software management related to each other? Are they complimentary or overlapping? Is there any benefit to combining the two? In the case of WSDM and J2EE, there is a very substantial benefit in combining the two management specifications:

• WSDM specifies a loosely coupled, interoperable, and dynamic mechanism for managing any kind of software.
• JSR 077 defines a standard for managing one specific kind of software.

Combine the two and you get an implementation that provides all of the advantages of a Web service management interface (loose coupling between resource and manager, interoperability, and language independence), but is applicable and deployable into every J2EE application server on the planet. It is a common management implementation that works for every application server and allows it to be linked with management functions for the operating system on which the app server is installed and with the other middleware with which it must collaborate.

How WSDM and J2EE Management coexist

JSR 077 defines the basic "model" for the management of J2EE application servers. This model defines a set of "classes"; for example, J2EEDomain and J2EEApplication. It also defines the properties that each "class" contains, as well as additional characteristics used for management, such as statistics. Inside a J2EE-compliant application server, instances of these classes maintain the state of the resource they modeled.

WSDM is based on the Web Services Resource Framework (WS-RF), which specifies how to implement stateful Web services. A WSDM implementation is a Web services application that is easily deployed into J2EE application servers. Therefore, a basic approach to creating a WSDM endpoint for J2EE is to model and implement a WSDM "wrapper" over the standard JSR 077 management model APIs. When the WSDM management consumer sends a request to the WSDM interface, the request is mapped to a local JSR 077 API call.

Each of the J2EE-managed objects in the JSR 077 management model can become an individual Web service representing a managed resource. The J2EEDomain service is the entry point for J2EE management functions and represents the entire set of resources within the targeted endpoint. The J2EEServer service represents the application server run time and its contained components. The J2EEDeployedObject service represents hosted application elements deployed into the application server.

Because each of the managed objects in the JSR 077 model represents some resource with unique management capabilities, it seems reasonable to map each to its own WSDM Web service. In practice, this is probably a bit too fine-grained and some of the objects can act as "containers" for the more low-level resources within them.

As much as combining WSDM and J2EE Management is appealing, there are challenges. Both specifications include a notion of managed state, but the semantics are different. Both specifications also include a concept of metrics (statistics in JSR 077), but again the semantics are slightly different between the two. As a local Java interface, the JSR 077 specification includes some sophisticated aspects such as the ability to dynamically extend the basic statistics interface with vendor supplied data.

Modeling J2EE Management for WSDM

Even though the WSDM specification has only recently been approved by the OASIS Technical Committee, there are already development tools available to accelerate implementations of WSDM-managed resources. One such tool is the Manageability Endpoint Builder (MEB), a component of the IBM Autonomic Integrated Development Environment (AIDE), available from IBM alphaWorks (see Resources).

Starting with Eclipse and Rational Application Developer

For this implementation of WSDM for J2EE, we downloaded this Eclipse plug-in and applied it to Rational Application Developer V6.0. The plug-in also works when applied to standard Eclipse 3.1 with some additional dependent plug-ins added. Figure 2 shows the Rational Application Developer IDE augmented with the AIDE/MEB plug-in for WSDM.

The Manageability Endpoint Builder models the endpoint in three distinct sections: capability, type, and implementation:

• The capability is essentially an interface that represents a set of operations and properties that your endpoint will implement.
• The manageability endpoint type is a named assembly of capabilities.
• Finally, the implementation is what guides code generation and deployment.

This layered approach maximizes reuse and provides flexibility in implementations

Creating the J2EE capability

The first step in developing a WSDM implementation using the Autonomic Integrated Development Environment is to create a Manageability Endpoint Project in the Eclipse workspace. For each high-level managed object in the JSR 077 model, create an individual Management Capability model in the WSDM for J2EE project. This Management Capability model contains the attributes, operations, and notification definitions unique to this managed resource as defined in the JSR 077 specification.

Also create a Touchpoint Type definition for each JSR 077 managed object. The Touchpoint Type allows you to combine several Management Capabilities for a complete managed resource model that meets the WSDM specification requirements. In addition to the capabilities defined specifically for JSR 077 functions, the AIDE/MEB plug-in provides all the capabilities defined in the WSDM MUWS specification, such as Identity and Description.

After the individual Touchpoint Types are defined for all the JSR 077 managed resources, combine those into a single Touchpoint Implementation definition in the IDE. From this implementation model, the actual implementation project and stub code is generated automatically. The whole process is very rapid and flexible, allowing for frequent adjustment and re-generation of the implementation stubs so that the newly generated code is merged with the existing code non-destructively.

Completing the implementation

Correct modeling of the WSDM-managed resource is by far the most important aspect of the process to get right. After you have the resources and management capabilities of those resources modeled to satisfaction, completing the implementation involves just a few more steps.

Implementing the generated classes

When you select the "Generate Touchpoint" action from the pop-up menu for the Touchpoint Implementation model in the IDE, the development tooling generates two additional projects:

• One project is the Web Application project holding the generated Web Service Definition Language (WSDL), stub Java implementation classes, and many other artifacts for the Web services function represented in the models.
• The other project is the EAR project, a J2EE Enterprise Application project that is used to deploy the finished WSDM implementation to a J2EE application server.

The vast majority of the code generated by the tool should be left unmodified, but there is one Java package generated that is meant to be edited. This package contains stub Java classes that must be modified to include whatever code is needed to execute the functions defined in the models. The source code generated for these classes contains special tags that allow new source to be generated and merged with the prior version, as long as the tags are properly maintained by the developer.

Figure 3 shows the Rational Application Developer development environment opened to one of the WSDM for J2EE implementation stub classes.

Listing 1 contains the code that is shown in Figure 3. You can see a setAc4j method that was generated and is not intended to be modified. And you can also see the stop and start methods that were generated from the models and are intended to be modified to hold real implementation logic.

public void setAc4j(Resource newAc4j)
{
     Resource oldAc4j = ac4j;
     ac4j = newAc4j;
     if (eNotificationRequired())
          eNotify(new ENotificationImpl(this, Notification.SET, oldAc4j, newAc4j));
}

public void start()
{
     // TODO: implement this method
     // Ensure that you remove @generated or mark it @generated NOT
     throw new UnsupportedOperationException();
}

public void stop()
{
     // TODO: implement this method
     // Ensure that you remove @generated or mark it @generated NOT
     throw new UnsupportedOperationException();
}

In fact, if you don't put some implementation logic in these methods, they will throw an exception. Listing 2 shows another section of the source code for the WSDM for J2EE project, where the methods have been modified to include real JSR 077 APIs that accomplish the function modeled.

public boolean isStateManageable()
{
     Boolean stateManageable = null;
     try {
        stateManageable = (Boolean)mejb.getAttribute(thisObjectName, "stateManageable");
     }
     catch (Exception e) {
        e.printStackTrace();
     }
     return stateManageable.booleanValue();
}

public String getServerVersion()
{
     String serverVersion = null;
     try {
        serverVersion = (String)mejb.getAttribute(thisObjectName, "serverVersion");
     }
     catch (Exception e) {
        e.printStackTrace();
     }
     return serverVersion;
}

Note that the @generated tag in the method prolog has been deleted so that subsequent re-generation of source code from the models will not overwrite these modified methods. Don't forget to do this step or you will need to redo the implementation code more than you'd like.

Deploying the MEP

After you have filled in the stub methods for the implementation classes, deploying the Web service is relatively easy in the Rational Application Developer or Eclipse environment. Both environments have the Eclipse Web Tools Project (WTP) plug-in code available, so the Enterprise Application project generated from the models can be deployed directly into a test application server without ever leaving the IDE. Several J2EE application server run times are supported by WTP. If the one that you are targeting isn't supported (yet), you can also export the EAR project to the file system and use the application server vendor's deployment tools.

Testing

Among the artifacts generated from the WSDM models are a variety of test programs. There is a simple Web application that is a Web services client for the WSDM interface in the models. This simple test client is great for quick sniff testing of the management Web service interface.

If the resource to be managed is more sophisticated, you can use the Web service proxy classes that are also generated from the models and build your own management client application. To test the WSDM for J2EE resources, we built a Web application console that displays data and exposes control functions defined by the models. Figure 4 shows a screen shot of this simple console application.

You can see that this console was targeted to display managed resources surfaced by the WSDM for J2EE Web service deployed in an Apache Geronimo application server. Because the WSDM for J2EE Web service application is implemented using only totally portable J2EE Management APIs, it can be deployed to any compliant application server. The client Web application console is a J2EE application that can be deployed to any J2EE app server also.

In conclusion

WSDM is the next generation of management. Using existing development tooling, the process of enablement is quick and straightforward. Modeling the management capabilities of existing resources can be more involved than actually implementing the management service once modeled.

Using WSDM allows consolidated and service-oriented management using existing APIs such as JSR-77, JMX, or CIM. The next generation of Manager products will be able to leverage WSDM interfaces to dynamically discover and introspect the capabilities of new resources that may not have existed when the manager program was originally written. Because of its inherent decoupling of management client from managed resource (including implementation language), there is tremendous opportunity to combine and correlate between systems employing wildly different native management interfaces.

Editor's note: The AIDE, the Autonomic Task Manager for Administrators, and the WSDM Browser for CIM and OSGi tools at alphaWorks have recently been updated. Please visit alphaWorks and try them out (see Resources for URLs to the tools).

Resources

Learn

• "SOAP is not enough (developerWorks, February 2006): Discusses the need for a common set of WS-RF interfaces that includes a sample WS-RF implementation provided by AIDE.
  
  
• OASIS Web Services Distributed Management technical committee: The committee is charged to define a "Web services architecture to manage distributed resources." Find the specification here.
  
  
• Self-Managing Autonomic Technology solutions: IBM is delivering technologies to help companies transform their IT infrastructures.
  
  
• developerWorks technical events and webcasts: Stay current with the latest technologies.
  
  

Get products and technologies

• Autonomic Integrated Development Environment: The IBM AIDE is a set of software development tools that embrace the WSDM standard.
  
  
• Autonomic Task Manager for Administrators: The IBM ATMA is a spreadsheet-based scripting environment for quickly composing and automating system management tasks.
  
  
• WSDM Browser for CIM and OSGi: Provides a demonstration that illustrates how WSDM's consistent interface allows a single application to manage disparate types of resources without requiring any special knowledge of the types of resources, their models, or their implementation technologies.
  
  
• JSR 077 J2EE Management Specification: This specification defines the J2EE Management Model, designed to be interoperable with many management systems and protocols.
  
  
• IBM trial software: Build your next development project with trial software, available for download directly from developerWorks.
  
  

Discuss

• developerWorks blogs: Get involved in the developerWorks community.
  
  

About the authors

Comments

Back to top

Trademarks

Table of contents

• A little background on the elements
• How does WSDM apply to J2EE?
• How WSDM and J2EE Management coexist
• Modeling J2EE Management for WSDM
• Completing the implementation
• In conclusion
• Resources
• About the authors
• Comments