Web Services for Interoperable Management
Extend J2EE and .NET enterprise management with Web services.
by Mitch Gitman

Posted March 15, 2004

Interoperability. It's a good enough reason to implement Web services.

But once you have some Web services up and running, what about exploiting their interoperability to manage them? That is, rather than treating Web services as just another layer in an application stack, what about using Web services to manage Web services? And while you're at it, what would it entail to use Web services' interoperability to manage diverse resources across an entire enterprise, thus easing overall operations management?

This article examines some of the technical considerations involved in managing production Web services and using Web service-based solutions to manage production environments. I'll look at some of the latest Web services management tool approaches and the evolving specification landscape for Web services management. Plus, I'll show simple, code-it-yourself management examples for both Java 2 Platform, Enterprise Edition (J2EE) and the .NET Framework.

A typical management architecture consists of two kinds of components: a single manager and any number of agents or observers, one for each observed element. The manager informs the agents of what they should observe. The agents can send the manager or the administrator alerts when certain conditions or thresholds are reached. The manager can query the agents for management data. The administrator can view logs and reports in the manager's user interface.

You can see that the observed element doesn't have to be a Web service, client, or Web services infrastructure. Regardless of what's observed, there's value in the agents and manager exposing Web service interfaces to each other. The prototypical case is when you have agents on multiple platforms. A single manager could collect data from various J2EE application servers along with an IIS installation running ASP.NET.

The Agent and the App Server
If we limit ourselves to Web services but no clients, a natural arrangement is one agent per server potentially observing any number of Web services. But then, where should the agent be placed in relation to the server?

Michael Hui, product manager of Unicenter Web Services Distributed Management (WSDM), Computer Associates' Web services management tool, identifies two possible placements:

• Native: The agent is embedded in the server. By the time control reaches the agent on an incoming request, the server infrastructure has already processed the request's transport wrapper (typically HTTP) and parsed the Simple Object Access Protocol (SOAP) message's XML. The agent accesses an outgoing response at the corresponding processing point in the reverse direction.
• Proxy: The agent intercepts the SOAP message on the wire, outside the application server.

Naturally, a native observer provides superior performance because it can piggyback on work the application server must do anyway. Unicenter WSDM and most other management tools for Web services are implemented this way. A proxy version of Unicenter WSDM exists, but only in combination with a hardware implementation of the message processing to mitigate the performance hit.

The hardware is there primarily for encryption and decryption. Otherwise, if you want to monitor unscrambled data, you must go native. With transport-level security, such as Secure Sockets Layer (SSL), that's a gimme. The Web server, IIS for instance, takes care of decryption and encryption at an outer layer. With message-level security, where the body of the SOAP message is encrypted or signed using a scheme such as WS-Security, a monitoring agent at the destination obviously still should receive an incoming message post-decryption. Even so, when outputting to a log, the management tool should be able to hash sensitive data.

The need to go native requires different versions of agents for different application servers. The most commonly supported servers are Microsoft IIS, IBM WebSphere, and BEA WebLogic Server. Even when an agent implements the latest J2EE specs, portability between J2EE application servers is not quite there.

One such agent comes with Service Integrity's SIFT; version 2.0 is in its final beta (see Resources). For WebLogic Server and WebSphere, the SIFT Server component implements a standard servlet filter that monitors the HTTP traffic. It also implements a JAX-RPC handler, as specified in J2EE 1.4, to process the incoming request's SOAP envelope after the application server has parsed it but before the Web service implementation method is called. (Flip the order for an outgoing SOAP response.)

To instrument—or make manageable—an enterprise application in WebLogic Server, SIFT takes each WAR file (or Enterprise JavaBeans [EJB] JAR) in the EAR and specifies a servlet filter in the web.xml deployment descriptor and a JAX-RPC handler in the web-services.xml descriptor; SIFT also inserts a small plug-in JAR. On WebSphere, you specify the JAX-RPC handler using a different schema in a different file, webservices.xml (no hyphen). (For ASP.NET on IIS 6, SIFT uses an HTTP module.)

Managing Your Own
With J2EE, the servlet filter construct allows you to write your own monitoring, logging, and alerting code for Web applications in general; the JAX-RPC handler construct lets you write your own management code for Web services in particular.

Does this mean you should reinvent the wheel? Well, certainly not one as sophisticated as SIFT 2.0 or other management tools on the market. But filters and handlers let you augment such tools, or meet more simplistic management needs yourself.

Use a JAX-RPC handler by defining a class that implements the javax.xml.rpc.handler.Handler interface, which has methods such as handleRequest() and handleResponse(). Or extend an abstract GenericHandler class that has dummy method implementations, so you implement only those you want to customize.

Here's a handleRequest() implementation that calls a custom trace method:

public boolean 
   handleRequest(MessageContext mc) {
     SOAPMessageContext messageContext = 
	    (SOAPMessageContext) mc;
    trace(messageContext.getMessage().toString());
    return true;
}

The MessageContext and SOAPMessageContext classes are defined in the javax.xml.rpc.handler and javax.xml.rpc.handler.soap packages, respectively.

A Handler implementation can also employ a HandlerInfo class to store extra information about the handler. For example, the HandlerInfo class has setHeaders() and getHeaders() methods where you can specify any SOAP header blocks that the handler handles.

The Handler init() method is passed a HandlerInfo object, which you might make a member variable. This example refers to a HandlerInfo member as mHandlerInfo:

public void init(HandlerInfo hi) {
    mHandlerInfo = hi;
}

On WebLogic Server, you specify handlers in the Web application's web-services.xml file. Specify a handler-chains element under the root web-services element:

<handler-chains>
  <handler-chain name="TraceHandlerChain">
    <handler class-name="test.TraceHandler" />
  </handler-chain>
</handler-chains>

Also, for each Web service method on which you want to use the handler chain, you need to specify a handler chain by name using a handler-chain attribute on an operation element. For more details, locate some sample web-services.xml files in a WebLogic Server install.

Micro-Managing
On the .NET Framework side, you can implement the abstract System.Web.Services.Protocols.SoapExtension class to inspect or modify the SOAP message during processing.

When you extend SoapExtension, you must implement the ProcessMessage() method:

public abstract void 
   ProcessMessage(SoapMessage message);

The SoapMessage parameter can be of type SoapClientMessage or SoapServerMessage.

The method is called at any of four SOAP message-processing stages, as specified by the members of the SoapMessageStage enum: BeforeDeserialize, AfterDeserialize, BeforeSerialize, and AfterSerialize. The SoapMessageStage.AfterSerialize and SoapMessageStage.BeforeDeserialize values give access to the stream sent over the wire. Your ProcessMessage() implementation should check the stage using the SoapMessage object's Stage property. (For finer prioritizing, override the ChainStream() method.)

Once you've derived a class from SoapExtension, you can indicate when it's run in two ways:

• Specify the SOAP extension with an add element under the soapExtensionTypes element in an applicable configuration file (typically Web.config). This runs it with all Web services in the config file's scope.
• Define a class that implements the abstract SoapExtensionAttribute class. That means implementing the ExtensionType property to return the type of the SoapExtension. Then apply the attribute to a Web service method or client proxy class method.

Web Services for More Than Web Services
Go back to the concept of agents and managers exposing Web service interfaces to each other. That's what SIFT does, allowing its own manager, SIFT Console, to provide a unified management view of both ASP.NET and J2EE Web services.

Now take the next logical step and swap out the thing being managed. The agent and manager can still act as an interchangeable Web service and client to each other, but now the content they're managing isn't only Web services, but potentially the whole IT infrastructure.

For managing sundry aspects of its server systems, Microsoft offers the Microsoft Operations Manager (MOM) 2000 application. Last fall, Microsoft introduced the MOM Connector Framework (MCF), which, for one thing, exposes MOM 2000 as a Web service (see Resources). At the same time, Microsoft and other software vendors announced the availability of "product connectors" to reconcile the MOM/MCF API with the APIs of those vendors' management tools. Result: MOM 2000 can do two-way alerts with other management systems.

When you inspect the Web Services Description Language (WSDL) document generated to define the MCF Web service, you find that there's nothing really Web services-centric about its content. It defines a ConnectorService that has, among other operations, a GetData operation that requests arrays of new alerts and old alerts. An alert XML Schema type defines 27 kinds of child elements, all relating to the Windows enterprise.

Web Services' Potential for Management
Another ambitious vision of how Web services can provide interoperable management is taking shape with the WS-Manageability specification, which is intended to describe how you can use Web services to manage Web services. The Web Services Distributed Management (WSDM) Technical Committee of OASIS, a standards body active in Web services, is developing WS-Manageability and keeping an eye toward using the same Web service standards for managing other IT resources in the future (see Resources).

Whereas the MOM product connectors maintain a sort of maternal link back to MOM 2000, WS-Manageability promises a kind of any-to-any interoperability. The Unicenter Web services manager now has its own proprietary WSDL, Computer Associates' Hui explains, so only Unicenter agents can communicate with it, albeit from divergent servers. With WS-Manageability, he says, any Web services management provider's agent can communicate with any other provider's manager. The agent WSDLs and manager WSDLs will be standardized.

A WS-Manageability implementation doesn't exist yet, and while the likes of BEA Systems, Computer Associates, Hewlett-Packard, and IBM are well represented on the committee, Microsoft is not involved in the effort.

That kind of interest, and competition, suggests the broader promise of Web services for management. But are Web services protocols the future lingua franca of operations management? At least at the higher levels where applications can write and read SOAP messages, they should be. Eventually.

In the meantime, the current crop of Web services management tools provide integration with sister products or more primitive management protocols such as Simple Network Management Protocol (SNMP). It's common for a Web services management tool to be able to send a trap to an SNMP manager on an alert condition.

In the long term, it might not matter if Web services ultimately pervade operations management as long as you're happy with what you can get out of the box. If your central management tool can transparently exchange data with other managers and agents, who cares how it exchanges the data?

About the Author
Mitch Gitman is a developer and consultant specializing in Web services, XML data binding, and J2EE/.NET Framework interoperability. He recently worked on Web services and XML Schema implementations for a major system and tools vendor. Reach Mitch at mgitman@usa.net.