eb services are more complex to deploy than Web sites or intranet applications. They are based on intricate platforms, or runtime environments that, like any software, can have their own runtime errors. It simply isn’t safe to assume that a debugged Web service will remain running properly without mechanisms to monitor its health.
Web services can have a much larger community of users than traditional (non-Web service) applications?potentially a worldwide audience. In that sense, a Web service is more like a Web site than a traditional application. Other software can also use Web services, possibly even without human intervention. These factors combine to suggest that a sophisticated Web service management infrastructure is needed to ensure quality of service.
Developers should consider the management and deployment of their Web services while developing the Web service, not after the development is done. After looking into the various aspects described in this article, developers should see the advisability of building a management interface, or conforming to a standard one, that is separate from the business interface of their Web service. It is also advisable for Java developers to give attention to the JMX-style beans that application servers support for reporting internal conditions and for correcting them. This should be built and tested early in the development lifecycle.
By planning for a managed Web service environment today, developers will reduce the overall cost of deploying their services and save themselves the pain of intervening when the Web service is giving problems in production. The most important reason to design for deployment is your customer. Customers making use of applications that use or contact a faulty Web service will be at the least dissatisfied, and at the most will not want to be a customer of that Web service any longer.
The consideration for management of Web services has become a crucial part of deploying and operating those services successfully. This article offers eight principles for designing and using a Web services management platform.
Understanding SOAP Interfaces
As background for these principles, a quick overview of some common Web services terms will be helpful. It is also useful to have a cursory view of existing management platforms.
A SOAP interface is a set of operations that can be invoked on the Web service through message invocations. These valid operations are frequently described using a set of documents written in WSDL. This article uses the terms SOAP interface and WSDL interchangeably.
WSDL bears many similarities to the interface definition language (IDL) in CORBA, COM+, and Distributed Computing Environment (OSF/DCE) styles of computing. That is, the WSDL document, itself written in XML, specifies the types of operations that the Web service promises to obey, when invoked with correctly formed argument types. One particular flavor of SOAP, called SOAP-RPC, commonly used to invoke a Web service today, has a close parallel to the RPC-style invocation of an object in CORBA terms. The other main flavor of SOAP is the document exchange form.
A Web services platform is required to host any Web service you write. This platform is typically either J2EE or .NET. Platforms handle runtime issues for your Web service, but are complex and need to be managed to be sure that they are operating correctly. A Web service management platform is a separate software system that will manage both the platforms and the Web services running on those platforms.
Principle #1?Know What Information You Need from the Web Service Platform
To manage the Web service platform, it is important to know the following characteristics:
- the identity of that platform (host computer name, port number, version number, for example)
- whether the platform is functioning correctly
- whether the platform process is communicating with other peer platforms on the network
- the list of Web services currently hosted on that platform
- the list of Web services currently responding or not responding
- the identity of all Web service instances on a given platform
- the throughput rate for that platform in terms of overall incoming and outgoing messages
- the average dispatch time for messages
- the contents of the error log for the platform
- the nature of any asynchronous events generated by the Web services that are hosted on this platform
- the last message receipt time and last message transmitted time
- the largest, smallest, and average message sizes
Note that many of the above measurements will also be useful to have on each Web service that resides on the Web services platform.
Principle #2?Enforce the Separation of Management Concerns from Business Concerns in the Web Service Interface
When building a Web service, one of our first concerns is what business operation it must support, for example, order placement or quote requests. Let’s call this the “business interface.” We also need to think about the “management” or “operational” interface to the Web service, such as operations for figuring out its current state of health and whether or not it needs management intervention.
These two types of interfaces, business interface and management interface, should be separated. There may be a WSDL description of the business interface that is separate from that for the management interface, so that developers can clearly identify when they are using these different operations.
Separation benefits overall operations for the following reasons:
- Management operations need not be present in each WSDL-described business interface that the Web service supports, thus reducing both duplication and the opportunities for errors.
- When management and business operations are mixed it makes it difficult to compare Web service interfaces. Comparison might be needed to validate interface contents, or to match contents with the version of a Web service.
- Other client applications may see, and therefore attempt to use, the management operations that are visible if they are contained in the business interface. It may be desirable to set different restrictions on clients who can manage a service as opposed to those who can use it.
- Management operations may not be published in the same way as business operations. Many Web service interfaces are published in a registry, but management interfaces are typically thought of as private.
- When management and business methods are mixed, you cannot achieve separation of concerns in the security area. For security paradigms, it is often desirable to hide certain interfaces from clients.
It is also desirable that both business- and management-oriented interfaces should be exposed through WSDL and contacted through SOAP messaging. This maintains uniformity of the Web service programming environment and helps lower the overall cost of development of the Web services platform.
Such a “management-oriented” WSDL may well become a standard that applies to all robust Web services in the future, as the same management operations will apply to most Web services. Development teams should consider creating such a common management WSDL for integrating their separate efforts in Web services development, so as to be ready for that standard.
Principle #3?Adopt SOAP Messages for Management
As much as possible, Web service management operations should be conducted via SOAP messages to the Web services platform, rather than through proprietary interfaces or commands (this is really a consequence of using Principle #2). Conforming to SOAP messages provides a uniform model for invoking management operations.
Managing Web services at the SOAP level complements and does not compete with other capabilities for management, such as WMI (Windows Management Instrumentation) or JMX (Java Management Extension), that are available through C#, Java, VB, or C++ methods. JMX is a standard in the Java environment for management of Java objects. WMI is an equivalent management standard in Windows. These two technologies support the Web services platform “under the covers” in their respective fields. They will be mentioned again in this article as playing an important role in the management tasks. Notice that relying on a SOAP interface frees management clients from the particular language implementation.
Web services, like objects, may conform to more than one interface within one WSDL document. This is achieved using different port specifications, where a port is a WSDL facility that allows for different contact points with a Web service. This presents an opportunity to the developer to have one or more business interfaces in one WSDL document and one or more management interfaces in a separate WSDL specification for the same Web service.
Benefits of Managing Through SOAP Messages
Organizing the management of a Web service by sending and receiving SOAP messages to it provides the following benefits:
- the developer of the Web service can avoid dealing with a separate management programming API
- management functionality can be discovered in the same way as Web service business interfaces
- security of management actions can, to a certain extent, leverage the same technology used for secure invocation of the business interface
- the SOAP servers, the common gateways for calling a Web service, can also form an access point for management functionality as well as business functionality for a Web service
- intermediaries between the service consuming party and the service providing party can perform management from an aggregation or “portal” site (see Figure 1)
|Figure 1: Management platforms should manage remote Web services from a central point.|
There are several good examples illustrating the application of a management interface. In the SOAP interface for managing a Web service, we may have operations that:
Principle #4?Create an Alternate Route into the Web Services Platform
There is one exception to the guideline for managing the platform only through SOAP messaging. When the processing of the SOAP messages themselves by the Web services platform is not functioning correctly, it should be possible to reach the Web services platform through an alternative mechanism.
This is a good argument to provide WMI-based or JMX-based management of the Web services platform alongside the SOAP-based mechanisms proposed in this article. Many Web services platforms are themselves J2EE application servers and use custom JMX MBeans, for example, to allow you to view their condition. There are comprehensive consoles available that make use of these JMX Mbeans to show the effects of the Web services on the underlying J2EE application server. These can be used in conjunction with the Web services management platform in normal operation to give another view of the system. The status of the Java beans or servlet objects that make up the implementation of the Web service at the J2EE level can be viewed through these tools. WMI-aware tools provide a similar capability in the .NET world.
Principle #5?Enable a Central View of Operations and Performance
Ideally, an operations manager will manage the condition of all Web services and their platforms from one management-application console, using a single tool. This should be the case regardless of the mix of hardware and software platforms in use. It is natural for corporate Web services to be deployed on more than one platform. Web services already run on Windows, Linux, and other UNIX flavors and currently incorporate two popular platforms, Java/J2EE and Microsoft .NET, for development and deployment. Creating a centralized operation reduces costs by bringing all problem events together into a single console. This means that operators can leverage the training they have received on the standard management tools for their enterprise.
Notice that in some cases there will be a point of aggregation for Web services. This may be viewed as a portal or a registry of Web service descriptions. The Web services may be remote from that point of aggregation, where the central point may not “own” the managed Web services. It should be possible to manage these remote Web services from the central point. This is made easier by management through SOAP messages, provided they can be secured on their way to the remote Web service (see Figure 1).
|Figure 1: Management platforms should manage remote Web services from a central point.|
This principle implies that the Web service can be managed remotely and by software that is not a part of the Web service hosting environment. This parallels the application service provider model. Passing SOAP messages through firewalls in order to achieve this type of management is very feasible. SOAP is an attractive mechanism to achieve this decoupling of management platform and Web service platform.
Principle #6?Distinguish Platform Management Issues from those that are Specific to the Web Service
Whether J2EE or .NET is used as the platform, there are many parts that must perform properly for a Web service to function. Should there be a problem with the Web services platform environment, such as running out of memory or disk space, the Web services in that environment would likely begin to fail. Therefore, any overall management strategy must first conclude whether the Web services platform is running correctly before diagnosing the state of the Web services within it. J2EE and .NET management consoles go part of the way to fulfilling this requirement. However they do not have visibility of individual services within their containers today.
This can only be achieved if the issues of managing the Web services platform (such as a J2EE server with its SOAP handlers) are separate from that of the Web service itself. To achieve this separation, separate instrumentation of the platform itself is required. This instrumentation should be based on the types of issues described in Principle #1 above. With confidence in the healthy state of the Web services platform, the operator can move on to diagnosing the condition of each Web service hosted on that platform.
Principle #7?Give Priority Attention to Management Messages
It can be very important to prioritize the management messages above the business-oriented messages in the Web services platform and in the Web service itself. When a management message and a business message arrive at the platform at the same time, priority should be given to the management message; the business-oriented message should be queued for later processing.
Experience suggests that Web services management messages be distinguished and treated differently from other business-oriented SOAP messages. Moreover, the guidelines for managing the Web service differ from managing the platform. Let’s assume the platform is functioning properly and attention can be focused on the requirements of any Web service that is using it.
Principle #8?Minimize the Role of Web Services in Managing Themselves
The Web services platform is the reception and transmission point for all SOAP messages. Thus, it can be used to determine whether the service is responding to messages and how long these responses take.
The Web services platform can, for example, interact with the management tools to determine the time taken to process any incoming or outgoing SOAP message. In fact, the Web services platform plays an important role in delivering most of the management information about the Web services it supports to the management tools. It can relieve the Web services themselves of most of this duty. The exception to this is the case where unexpected events occur in the Web service; it must have some way of notifying the platform directly about such conditions.
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.