Modifying Web Services: Unexpected Changes to a Service in the Network

In a growing network featuring Web services dependencies, the need for modifying Web services can occur suddenly and unexpectedly. Examples include:

• Change: A manufacturer faces a sudden increase in market demand for a product. Traffic increases to an e-commerce site as customers place orders. More calls come in to the call center where customer service representatives take product orders. Both of these systems link to a customer management Web service being provided by a CRM system.
  Result: There is an unexpected decrease in the response time of the customer management Web service.
• Change: A brokerage is using an external provider of market quotes for equity securities. The quotes are retrieved via a Web service. The quote supplier's system providing the Web service unexpectedly crashes.
  Result: The quote Web service is no longer available.
• Change: The finance organization in a large retail chain has built a dashboard application to monitor key business metrics. This application links to an inventory Web service provided by a homegrown warehouse management system in one division. That division replaces the application with a packaged inventory management application.
  Result: The inventory management Web service has moved and the contract (WSDL) for that Web service has changed slightly in the new application from that provided by the original system.

The impact of each of these examples to the service network is similar. In the first (customer-service) example, the problem starts with the degraded performance of the customer management Web service. That change ripples throughout the service network, eventually impacting systems that are several times removed from the initial problematic service.

While this problem certainly represents an ugly picture, the picture depicted below is even uglier. The reality is there are no lines painted on the floor of the data center highlighting the interdependencies among the loosely coupled systems in a service network. There are no dials and gauges displaying Web service performance. There are no alarm bells that sound when service performance moves outside normal bounds. There is no facility for tracing failures back through a tree of application interdependencies to get to the root of a service network problem.

The need for modifying Web services to respond to change is constant. But there are no lines painted on the floor of the data center. Failures appear to be random and unrelated.

Instead, the organization responsible for keeping the service network up and running is faced with what appears to be a bewildering set of coincidental system failures. And there are more to follow. These failures are expensive. In the example above, orders are lost, customers turn to competitors and valuable IT personnel are frantically troubleshooting problems, with limited insight, rather than innovating to improve the business. Even in a service network of a single service provider and one Web service consumer, the inability to rapidly detect changing service conditions and actively deal with them can be extremely costly. As the service network grows, those costs explode – the impact of a service network change ripples through a larger network of business applications.

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

• Know there is a service network problem – that the network of services is deviating from its normal operating range
• Identify the root cause of the problem – if it is a service network problem, which application, service and operation is at the head of the cascading chain of trouble
• Insulate the downstream applications from the root failure – minimizing ripple effect costs and providing breathing room to address the underlying problem

Summary

The requirement for modifying Web services, simply put, is a daily reality. And a Web services platform for management is necessary to address the three types of modification in an enterprise service network that dominate rising costs: unexpected change to a service in the network, planned change to a service in the network and planned simultaneous change to many services in the network.

For More Information

The need to modify Web services to cope with changes on the network is constant. Find out how to manage this challenge – throughout the development cycle. Download the free webinar, Runtime Governance