Web applications built on a service-oriented architecture (SOA) promise to greatly improve IT efficiency and business agility. SOA establishes data and protocol standards so that existing internal and third-party application modules or services can be reused and orchestrated into business applications. Unfortunately, while SOA enables the rapid implementation of business applications, it also greatly increases the complexity of managing performance when these applications are deployed in production – often diminishing the benefits of the SOA adoption. Without an effective way of monitoring application performance, and quickly diagnosing and correcting problems, there is a high likelihood that an SOA application could be dead on arrival (DOA).

There are several aspects to implementing SOA that makes it difficult for IT to manage application performance:

Slowest Common Denominator: The service level of an SOA application is limited by the service level achievable by the worst-performing services it touches on the network. For maximum flexibility, services can even be supplied by third-party vendors and may be running on different computing platforms. This makes it virtually impossible for IT to characterize the performance of constituent services or control the numerous moving parts that can affect application delivery and performance. Reusing services also means that performance flaws found in common services are replicated across applications, creating multiple points of failure. As a result, it’s very difficult to determine quantitatively if the service level exceeds end-user expectation or, at a minimum, meets the performance targets stipulated in service level agreements (SLA).

Rube Goldberg Machines: For a Web-delivered SOA application, it is also difficult to quickly determine the existence and source of service delivery problems. Culprits can include any of a myriad “moving parts” in the delivery mechanism, such as the client’s PC, the Web cloud, the data center, the composite services, and/or third-party service provider’s services or infrastructure. No list of “likely suspects” can possibly be exhaustive enough for such a complex environment.

The Tangled Web: The task of diagnosing SOA application performance problems is further complicated by the lack of a predictable or pre-determined path a particular transaction takes when traversing though the application or infrastructure. Unlike client/server computing where, for example, an inventory lookup is routed through a defined network segment and is served by an ERP application installed on a fixed physical server, that same inventory lookup in an SOA environment can be routed dynamically through the Web cloud, and be served by multiple virtual or physical servers on multiple logical tiers of the infrastructure. A third-party Web Service call might also be initiated to a supplier’s infrastructure to account for any inventory en route from the supplier’s factory. This complex orchestration involving a non-deterministic transaction path makes re-creating and diagnosing performance problems very difficult.