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


Choosing the Right Web Services Management Platform

When you deploy any application, you are expected to have a plan for management and maintenance of that codebase: That's part of the job. But developers have been so busy learning Web services that management issues have taken a back seat. Use these requirements as a checklist for investigating products that should underlie your company's vital Web services and facilitate their long-term management.

s companies begin to implement Web services, IT managers are being confronted with the long-term ramifications of their deployment. Namely, management and support of Web services will ensure that they are well integrated, scalable, and maintainable. It is rare to find an organization that has considered these issues adequately in their current Web service implementations.

If you take only a cursory look at current Web services architectures, you might assume that once a Web service is deployed it can remain a viable entity. Pull the covers back and support issues become evident, such as:

  • What happens if the service crashes?
  • What happens if service resources become consumed?
  • What happens if performance becomes unacceptable?
And there are more concerns where those came from. Because Web service environments are inherently more intricate, it's unlikely that developers will be able to create a management model that can suit every service. For example, some services can return results through computation done right at the location of the service. However, most Web services need to get their results from databases or other applications within the corporate firewall, and this adds to complexity, vulnerability, and the potential for elements to fail. IT administrators in this position may even want to bring in developers with expertise to diagnose and fix problems in a production environment, although this adds to the overall cost of the service.

Outline Key Functional Requirements
It is useful to separate out the management of the Web service from the management of the platform on which the service runs (the Web services platform). Think of the Web services platform as the interpreter of SOAP messages on their way to the Web service itself. By making use of its understanding of SOAP messages, the Web services platform can help the developer by taking over parts of the management functions.

Many vendors have Web services platform products on which developers will build their Web services, and those vendors will also supply some management capabilities with their products. However, developers cannot rely solely on the management features that come with the platform; you'll need to build some extra functionality to ensure your Web service is indeed manageable.

The key concerns in managing Web services begin with runtime instantiation and responsiveness to requests. These issues include:

  • How the Web service can be instantiated or started up
  • How multiple instances of the Web service may be handled concurrently
  • How the load is being dealt with—by one instance or shared across those instances
  • How any instance of a Web service may be shut down
  • How the operations staff will monitor the stability of a running Web service at any time
  • How the loading characteristics on that Web service can be discovered and presented to a manager
  • How the operation of the Web service can be changed
In order for management data to be extracted, a Web service must conform to certain interfaces, or rules. These rules will be the "management interface" to the Web service and are made up of appropriate responses to messages for:
  1. Starting up the service
  2. Shutting down the service
  3. Checking that the service is alive and responding
  4. Re-initializing the data structures or component objects that make up the internals of the service
  5. Requesting the service to report the number of concurrent messages it is processing at any time
  6. Requesting the service to report the number of messages in its queues (inbound/outbound) at any time (if it implements queuing of requests)
  7. Requesting that the Web service display its identifications, including its current version number
  8. Requesting that the service display its current set of dependencies (other Web services)
  9. Requesting that the service send any error messages to a named target or file
  10. Producing current load statistics—including the "weight" of any type of message dealt with, such as its byte size (This is particularly relevant in document exchange scenarios.)
  11. Producing unsolicited events or warnings of occurrences within the service that require attention
  12. Decommissioning the Web service at the end of its lifetime
Requirements 1 through 3, 5 through 8, and 12 may be performed by the Web services platform rather than the Web service itself. However, the Web service developer must implement the cases where the management platform should be notified of unexpected internal events. This is also true of certain internal properties of the service, such as in requirements 9 or 10. The operations shown above may be included in a common management WSDL that all managed services should obey.

A set of standard SOAP messages is required for all but the first of the above functions. Some of these facilities are built into today's tools, but the coverage is not complete.

If these capabilities will be invoked in the service through a set of management-specific SOAP messages, then the management side of any service can parallel the client side in its implementation. The Web services platform may intercept some of these management messages and act on them on behalf of the Web service.

Web Service Status
To monitor a Web service, a Web services platform might watch SOAP messages and expect a response from a Web service in a specified amount of time. Should no response message be generated by the Web service, the management platform would raise an alert with associated information about the request and the component that has seemingly failed.

Another way to check the status of a Web service is through its interface. By sending a ping-like message to the service, a management agent can detect that the service is up and running, as well as measure the round-trip response time of the SOAP message. This approach does not require explicit coding in the Web service itself.

Checking the status of a Web service can be extended to produce a description of the entire interface as a WSDL specification. This can be useful to both potential consumers of the service and to a testing framework. In this case, the developer would provide a method that returns the WSDL specification of its interfaces. A testing framework could use this information to generate a suite of test programs that exercise the interfaces.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date