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.
Back to top