Web Services Response Time

A key part of establishing confidence in a network of shared services is providing infrastructure that gives customers, suppliers, and, just as importantly, various divisions and departments of the enterprise with consistent and timely feedback on the performance of services provided. Simply put, it's just as important to manage expectations across user communities as it is to deliver adequate Web services response time.

The Impact of Change on Web Services Response Time

IT efforts associated with keeping this growing network of shared services running and meeting performance and response expectations can be extremely costly, not to mention complex and time consuming. As a service network grows, the marginal cost of change in the network grows at an accelerating pace. We will examine some of the contributors to change and how change (however slight in some cases) can have a ripple effect throughout the services network.

In a growing network featuring many Web services dependencies, service changes can occur suddenly and unexpectedly. For example, a manufacturer faces a sudden increase in market demand for a product. Traffic increases to an e-commerce site as customers place orders. B2B partner traffic to the direct ordering system also increases. Both of these systems link to an inventory level Web service being provided by the inventory management system. The service begins to degrade under this increased load and there is an unexpected decrease in the response time of the inventory level Web service.

Change can also be planned. An environment of shared services lends itself well to the creation of new applications at will – changing business conditions can lead IT to implement a new application (assembled using existing Web services) which can lead to a drop in Web services response time resulting in ripple effects and cost. For example, a packaged goods manufacturer signs on a new large distributor. This new distributor has a collection of systems that must leverage the existing inventory level Web service for direct ordering. The systems at the new distributor are connected to the existing inventory level Web service and ordering begins. Service performance begins to degrade under this new load and eventually the application is overloaded to the point of failure impacting all distributors using this service as well as all internal and customer-facing applications using this service.

In other cases, change is sudden and unexpected and can come in from outside the organization. For example, this same packaged goods manufacturer adds a new set of distributors to its partner network. These new distributors will integrate their own inventory application with the manufacturer. The manufacturer and partners both make this possible through a collection of Web services that are provided by a number of different systems, and some processes that are managed by an EAI platform. Then the outsourced Web service providing partner inventory levels fails. This is an immediate and unexpected impact to the service network. Ripple effects follow and costs accumulate as both organizations work to figure out the root of the problem.

The Impact of Change

Whereas the service-oriented approach to application architecture was meant to accelerate the response time of the IT organization, the impact of changes to the service network and the ripple effects that ensue can quickly lead to precisely the opposite result on Web services response time. This is why a Web services management approach is critical.

For More Information

Learn more about Web services response time and how to manage user expectations: download the free white paper, SOA Infrastructure: Strategies for Meeting Global Enterprise-Class Challenges