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:
Managing Quality of Service Levels
- 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
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.