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:
- Starting up the service
- Shutting down the service
- Checking that the service is alive and responding
- Re-initializing the data structures or component objects that make up the internals of the service
- Requesting the service to report the number of concurrent messages it is processing at any time
- Requesting the service to report the number of messages in its queues (inbound/outbound) at any time (if it implements queuing of requests)
- Requesting that the Web service display its identifications, including its current version number
- Requesting that the service display its current set of dependencies (other Web services)
- Requesting that the service send any error messages to a named target or file
- 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.)
- Producing unsolicited events or warnings of occurrences within the service that require attention
- 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.
SOAP Message Monitoring and Logging
Web service management platforms must be able to monitor the input and output messages for all active services. This requirement allows the platform to track and forward SOAP messages, and data about these messages, to management tools for diagnostics and performance measurements purposes.
Many industries are required to provide tracing and logging capabilities for accounting as well as regulatory purposes, so a management platform will play an essential role in these situations. Message monitoring allows the management platform to log all messages. There is also a need to provide filtering of messages, based on policies, so that only select messages are logged. Again, a management platform can fulfill this filtering requirement.
Measuring Usage
To adequately understand the usage of a service, a management platform must know the flow of messages in and out of a Web service. It also must watch the consumption of the Web service by different consumers. Information about service consumers includes:
- Who is using the service the most or least?
- How are consumers using the service’s internal components?
- When are services either in use or not in use?
To accomplish this, either the Web service itself or the Web service platform on which it runs, must be able to identify the source and destination of SOAP messages.
Managing Robustness of Web Services
There are a number of circumstances that must be considered by the developer before a Web service can be put into production. For example, how many instances of that service should be allowed to run? What difficulties are faced when replacing a Web service with a new version? Runtime performance is often crucial to customer satisfaction, so assistance in this area is a must.
Managing Multiple Instances of a Web Service
Successful Web services, like successful Web sites, are used by many consumers and are expected to be available all the time. To achieve this, the designer of a Web service-based system will need to eliminate single points of failure. One way to implement this is to allow multiple instances of the service to be coexist, perhaps on multiple machines. From the perspective of the management platform, an additional qualifier is needed in these situations to identify each particular instance of a Web service.
Multiple instances of Web services are required in order to balance a high load of request traffic from consumers. The Web services platform can be the software that is responsible for load balancing. In this case, the platform must be able to interrogate all instances of a particular Web service, to determine what the relative loading is on each of those instances. Management platforms should allow for visibility of the load on all instances and for shifting of excess load from instance to instance. This would allow developers and administrators flexibility to handle many types of high-load situations.
Managing the Provisioning of a Web Service
Until testing of a Web service is performed, it is unclear exactly how many instances are required to handle certain types of high loads. Once load testing is performed, the management platform should allow an administrator to chose the appropriate number of instances for a given circumstance and the machine locations where they will best operate. The management platform can then provision these instances and know ahead of time when to invoke instances on different machines.
Managing the Performance of a Web Service
The management tools should allow the developer to detect any bottlenecks that exist in the use of the Web service or in its internal workings. Both response time and uptime are measures of the quality of a Web service. Web services may be used in situations where a service-level agreement (SLA) exists between companies. For example, a Web service may need to achieve a response time of 1 second or less and it must be available 24 hours a day, 7 days a week. The management platform must be able to recognize when these requirements of an SLA are not being met, based on the traffic it sees the Web service handling, and take some action at that point.
This is an area where management and testing of Web services overlap. The same tools that a developer might use to test runtime performance might also be used to identify deployment issues.
These measures are useful throughout the development lifecycle. For example, the overhead in processing a very large XML document may need to be taken into account when designing the granularity of a Web service. After customers use a Web service that uses document-style messaging, management information might show that performance can be improved by implementing RPC-style messaging.
Web Service Change Management
Because Web services are used to implement business functions, and these functions change as business changes, there needs to be platform support for commissioning and decommissioning different versions of a service over time. There are several aspects of this requirement that need to be considered. Foremost, will the public interface to the service change or remain the same? If the interface remains the same, then replacing old versions of a service with a newer version can be transparent to the consumers. The management platform must keep track of the service and its versions.
When the service interface (i.e. the set of operations it obeys) changes, the management platform has a much more difficult task. It could simply discontinue using the older version, but then any consumers that depend on that version would no longer be able to contact their Web service. Rather, the management platform must be able to keep track of the versions that are in use. The Web services platform can invoke the appropriate version based on consumer requests, if the consumer is prepared to nominate the version in which they are interested.
For this kind of change management to exist, mechanisms must be in place to:
- Tell the running service to stop dealing with new incoming messages
- Redirect incoming messages to that Web service to another target (perhaps a queue)
- Take the Web service out of service for a period of time (perhaps replacing it with some form of proxy)
- Replace the Web service with a new version of itself
- Reactivate the new version of the service and have it deal with the backlog of messages that was stored away during its absence
Managing Quality of Service Levels
Web service developers may require various Quality-of-Service (QOS) levels for different types of consumers. For example, premium partners may be allowed priority access to services. This requires that service-level objectives (SLOs) be made available for deployment and that the management platform monitors the service to ensure the SLOs are met.
Web Services Interoperability
Web services extend the promise of allowing disparate applications to talk to each other via a common data and operation representation, i.e. the SOAP messages and the WSDL interfaces to which they conform. Managing this interoperability feature means that certain compliance tests are needed to ensure that new Web services conform to the rules of engagement between, for example, a J2EE-based Web service and a .NET-based Web service. Management tools are required to facilitate sending test messages to a Web service to ensure that it responds in an appropriate way. A repository of test messages must be maintained and updated such that suitable interoperability testing can easily be done, even in the absence of a real client application.
Managing the Security Aspects of Web Services
Web services can represent interfaces into business functions of a corporation. As such, proper levels of security must be strictly enforced. Early adopters are using Secure Socket Layer (SSL) technology as an introductory step to security. This technology secures the connection between two endpoints and allows for client- or server-side authentication and message encryption. It falls short, however, in the areas of:
- Storing a secured message in a queue for processing later
- Relaying a message through third parties
- Tunneling a message over other protocols
These concerns have generated much attention and led to the creation of the WS-Security industry standard, which is still evolving. The first release of the specification for this standard can be found at http://schemas.xmlsoap.org/specs/ws-security/ws-security.htm.
There are really two main issues for securing Web services. The first is the secure communication of SOAP messages across the network, which is addressed by the WS-Security standard. The other is the secure management of Web services.
Secure SOAP Messaging
When sending SOAP messages across the firewalls that protect enterprises from attack (and in some cases within an enterprise), there is a need for Web services to have adequate levels of security in the following ways:
- SOAP messages, in particular the payload of the message, must be capable of being encrypted in full or in part.
- SOAP messages must be capable of being digitally signed, such that there is trust in the origin of the message and the message may not be repudiated. Parts of a SOAP message must also be allowed to have separate digital signatures.
- SOAP messages must be capable of being relayed through several intermediary parties in a secure fashion before reaching their final destination.
- Replay and denial of service attacks using SOAP messages must be handled.
- Truncation of SOAP messages or of an ordered sequence of SOAP messages must be handled (for example, the deletion of a critical message from a series of messages).
The WS-Security specification addresses requirements 1 through 3, but does not address 4 and 5 as yet. WS-Security work includes key and certificate handling, called XKMS (XML Key Management Services). Further work is required in the WSDL area to ensure that the client invoking an operation from a WSDL specification is allowed to make that call.
Secure Management of Web Services
There are additional requirements, beyond the level of the SOAP message, for the secure management of Web services.
- Management of a Web service should be restricted to authorized individuals.
- Management roles, with different capabilities, are needed for managing the Web service
- for interrogating the current status of a Web service
- for starting a Web service up or shutting it down
- for allowing particular groups of users, or client programs, to use instances of the service (sometimes called provisioning the Web service)
- for measuring usage of the service by particular groups
These roles require that users be authenticated and granted different privileges for access to services via the management platform. Ideally, the developer should not be required to construct the security layer that protects the service from outside threats. This work should be accomplished in the management platform at service deployment time.
Putting Requirements to Good Use
The purpose of generating these requirements is to help developers who are building Web services achieve a successful, maintainable implementation over the long haul, regardless of their deployment platform. No single company or organization has yet proposed an implementation for the rich set of requirements for the management of deployed services, although the industry is working on this. For now, IT departments are on their own to define them.
Furthermore, these requirements can be used by IT developers and managers to influence tool and platform vendors and to judge management products for purchase decisions. If you’re making a buying decision, do not hesitate to confront your vendor about all the requirements discussed in this article; each of them is important to your success.
Finally, developers who are keenly aware of deployment and management issues are on the right path to deploy truly robust Web services that will satisfy customers and partners and keep coming back for your business.
