Web Services Maintenance: How to Plan for Change in a Service in the Network

In many cases, intentional IT actions may cause unexpected impact to the service network. These intentional actions can bring about the need to implement Web services maintenance on a planned basis: introducing new applications; replacing and enhancing existing applications and Web services; upgrading systems; bringing systems up and down for maintenance; relocating servers; and outsourcing applications.

Examples of intended change with unintended consequences include:

• Change: A pharmaceutical company has made the decision to replace a custom-built inventory management system with a packaged application. A collection of Web services had been built in front of the old system to allow other applications access to the information and processes in the system. The new packaged application comes with pre-built Web services, but while they are richer in functionality, the Web service interfaces are different.
  Result: Service locations change, because the application moved, and the Web service interfaces change.
  Impact: Systems that rely on the old version and location of the service (identified by a URI) will abruptly lose contact with that system, sending messages into a void. Even if the messages were to arrive at the new system, the service request message form would be alien to the application. Service requests fail. And ripple effects begin.
• Change: An aircraft manufacturer creates a new portal that will display real-time manufacturing process status. This portal is to leverage a Web service that returns the current status of a given aircraft assembly project. The Web service is enhanced to accept a more detailed query and to return a more detailed response.
  Result: Service contract changes.
  Impact: As above, systems bound to the old version of the service suddenly find their message formats are invalid. There were some systems that relied on the old version of the service that were not even known to the Web service owner. A developer in another group had discovered the availability of the service over a water cooler conversation and had built a system that relied on the service, albeit infrequently. Discovery and quick utilization of a service that enables the quick creation of a business-enhancing application is a big benefit of the SOA approach. That system is a time bomb waiting to detonate the next time it tries to access the service through the old contract.
• Change: A financial services organization acquires a regional commercial bank. The newly acquired bank has a collection of systems that must leverage an existing loan yield calculation Web service engine for consistency across the organization and to meet certain regulatory reporting requirements. The systems at the new bank are connected to the existing yield calculation Web service.
  Result: Service performance degrades on the yield Web service and eventually the application is overloaded to the point of failure.
  Impact: Similar to the scenario covered in the section on unexpected change, applications that rely on the yield calculation engine begin to unexpectedly fail across the bank. Many of these applications rely on the service indirectly through other Web services that build their capabilities on the back of the yield Web service. Diagnosing the root cause is a nightmare.

In order to effectively deal with this problem, there must be a facility to:

• Understand the makeup of the service network – the true Web services dependencies and dependencies between systems, even those that leverage a service infrequently
• Predict the impact of a change – will this new application overload the Web services to which it will connect? If I move an application providing services, which applications must be updated to interact with the new service?
• Insulate the downstream applications from negative impact while still allowing the change. It is not a solution, for example, to gate the enhancement of a service or the replacement of an application on the re-binding of dozens of applications to a new service location. (While this would not be an issue if organizations were to adopt and require the use of service registries like UDDI, the reality is that universal adherence to this policy, even in a single enterprise, will never be a practical assumption.) Neither is it a solution to re-bind the applications to a new service contract where the message schemas change (this is not addressed by a registry solution alone).

Summary

The requirement for Web services maintenance is a given. And a Web services platform for management is required to address the three types of change – including maintenance – in an enterprise service network that dominate rising costs: unexpected change to a service in the network, planned change (maintenance) to a service in the network and planned simultaneous change to many services in the network.

For More Information

Learn more about the importance Web services maintenance – and how Web services management can help. Download the free webinar, Runtime Governance