RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Learn the Eight Principles of Web Services Management : Page 10

So now that you know how important foresight and planned management are to the success of your organization's Web services transition, the next step is knowing what you need to squeeze out of your management platform. We give you practical advice in eight easy steps.

Changing Your Current Management Model
Let's put these principles to work for the platforms being used today to run Web services. The remainder of this article will fill in the gaps between current-day management technology and the requirements and principles we have seen.

Traditionally, management environments contain a management agent that is a process or operating system service living on each host machine. It manages "objects," which can be any application, component, network element, or Web service that requires management. The agent collects management data and reports back to a collection point, perhaps a separate management server (see Figure 2). Management tools are then used to collate and display the analysis results.

Figure 2: A typical management platform model reports back to a central collection point.

Management agents are also capable of sending stimuli of various kinds to the managed objects to cause them to change state or behavior. One example stimulus would be changing the state of a running application. In this scenario, management personnel use a management console (a unified set of screens—see Principle #1) to view the condition of the managed objects.

These managed objects are given unique identities when placed under management control. This allows for the existence of multiple copies of a Web service on the same platform and multiple instances of the Web services platform itself. Without the use of such identities, you could not monitor all instances of a Web service or platform in one console.

Web services require management agents that allow SOAP messages to be intercepted on their way to the managed service. The management agent can be viewed as a SOAP message interceptor that detects certain facts about any incoming or outgoing message and logs them or sends them to the management information collection point. These SOAP messages can be translated from requests sent to the Web services management agent in other formats.

The management agent provides a layer of indirection between the Web service being managed and the tools that are sending or receiving management events. This agent's functionality may be built into a server process representing the Web service platform or into a library that is used by the Web service under management. The management agent, therefore, is an extension to current-day SOAP handlers with a specific purpose of monitoring and controlling the services on the platform.

Figure 3: A Web services management agent acts as a SOAP message interceptor.

The management agent plays a role similar to that of the JMX Mbean server shown in Figure 4. It communicates directly with the services under management in formal ways. The Web services management agent must "speak any language" to the tools and Web services with which it communicates. On receipt of a SOAP message from the management tools, the management agent may choose to convert that message into a JMX request or a WMI call because it knows that the particular service understands that protocol.

Figure 4 shows one use of JMX to gather data in J2EE. Here, the Web service may be complemented by a custom set of JMX beans that provide access to key Web service objects.

Figure 4: The management agent should operate similarly to JMX Mbeans in an application server.

The Benefits of Being Principled
The preceding article in this series discussed the fundamental requirements for a Web services management platform. In this article, I outlined a set of practical principles for designing Web services and their hosting platforms that will help developers achieve a consistent level of manageability.

By applying these principles, developers will find it's easier to create Web services that are manageable and independent of the platform on which the services reside. Some principles require the developer to achieve separation of business and management interfaces, while others require the developer to judge the Web services platforms against them when choosing an infrastructure to rely on. As technologies emerge in the Web services management space, more of these principles will become standard practice in the mainstream construction of Web services.

Justin Murray is a technical consultant at HP and has worked for the company for 14 years. He has taught and delivered consulting to HP customers and staff on a variety of subjects including optimizing performance of Java and Web-services applications. He can be reached at justin.murray@hp.com.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date