SOA & Response Time: A Generational Issue?

by Don Fowler
March 1, 2008

Consistency Is Key  

In a June 2007 article for ComputerworldUK titled “Eight Rules of Network Performance Management,” Joel Trammel noted: “ 

The best way to understand the notion that all performance is relative is to ask someone who uses a networked system or application if a 3-second application response time is good or bad? The answer is, it depends. If the normal response time is 10 seconds, a 3-second-response time is very good. But if the normal response time is 1 second or less, 3 seconds isn’t very good at all. For the same measurement, different circumstances lead directly to different interpretations.” 

Performance is usually based on either previous experience or a user’s changing expectations. 

Consistent response is the key to SOA acceptance. The timely provisioning of session and asset resources to ensure response consistency is a critical factor. 

At the IBM 2006 SOA Architect Summit, a presentation on SOA governance discussed the impact of high transaction rates on response time. New and reasonable SLAs are required to set service requester expectations to the appropriate level and provide the correct service targets for the governance team’s operational measurements. 

A recent Microsoft manual, Principles of Service Design: Patterns and Anti- Patterns, offers some relevant points: “ 

(SOA) services are dynamically addressable through URIs, enabling their underlying locations and deployment topologies to change or evolve over time with little impact upon the service itself (this is also true of a service’s communication channels). While these changes may have little impact upon the service, they can have a devastating impact upon applications consuming the service. What if a service you were using today moved to a network in New Zealand tomorrow? The change in response time may have unplanned or unexpected impacts upon the service’s consumers.  

“Service designers should adopt a pessimistic view of how their services will be consumed—services will fail and their associated behaviors (service levels) are subject to change. Appropriate levels of exception handling and compensation logic must be associated with any service invocation. Additionally, service consumers may need to modify their policies to declare minimum response times from services to be consumed. For example, consumers of a service may require varying levels of service regarding security, performance, transactions, and many other factors. “ 

A configurable policy enables a single service to support multiple SLAs regarding service invocation (additional policies may focus on versioning, localization, and other issues). Communicating performance expectations at the service level preserves autonomy since services need not be familiar with the internal implementations of one another. “