Service Oriented Architecture (SOA) enables the reuse of software functions as services. These services can be easily orchestrated together to form new business applications without regard to underlying technology, algorithm or schema of the component services. This new approach to application development has the potential of reducing development cost, better aligning IT to business, and improving business agility. However, without a systematic approach to managing the performance and availability of these more complex applications, the benefits of SOA can easily be mitigated by higher IT operational cost and degradation in end user satisfaction.

Benefits of SOA

By enabling a "Lego" approach to application development, SOA promises to lower development cost, and shrink the development cycle. To the business owner, SOA allows the direct matching of business processes to software functions or services to deliver unmatched business agility. Business applications are no longer monolithic pieces of code that cannot respond to changes in business processes. Using SOA, changes in business processes simply require a re-orchestration of the constituent services.

The web further extends the capability of SOA. Third party functionality, like credit check, account balance query, delivery tracking, etc., can be exposed by the service provider on the web and incorporated into business applications without having to deal with proprietary Application Programming Interface (API) or Electronic Data Interchange format.

The Cloud with Silver Lining

While SOA can be implemented using a variety of technologies, the majority of SOA applications are built using the web services standard. In some cases, web services are developed to provide entirely new functionality. More often, services are created by wrapping existing legacy application modules to make them accessible and re-useable in an SOA setting. SOA based applications can be customer-facing like e-commerce or e-banking applications, partner-facing like order processing or supply chain applications, or internal applications like employee portals or other enterprise applications. These applications are typically delivered via the Web using standard internet protocols to a distributed population of end-users.

SOA helps lighten the workload on developers by allowing them to link together existing or third-party services to form applications that can be delivered on the Web. SOA allows developers to focus on improving the business value of applications instead of wasting time recreating common software functions from one application to the next.

Unfortunately, as the complexity of these applications pose many new management challenges, the same ease of use advantage does not extend to IT operations personnel. While generally accepted industry standard and tools governing the creation and utilization of SOA and web services exist, there is a general lack of tools that can monitor the performance of the Web-delivered applications, and more importantly, identify the causes of performance incidents so they can be remedied efficiently. Let's look at some real world challenges:

While the function, data representation and usage policies of services can be clearly defined and standardized, the performance characteristics of services running on real world production platforms cannot be accurately characterized and documented. As a result, critical services might become the "weakest link" in an orchestration, impacting the performance and availability of one or more SOA applications.

If third-party services are used, it is difficult to determine if: the service provider's infrastructure that delivers the services is experiencing problems; and the network link between the application owner and the service provider's infrastructure are performing at a level that permits the overall application to meet its expected service level.

With the unpredictable, dynamic and interconnected nature of the Web cloud coupled with the ambiguities surrounding the relationships and volume of interactions between reused services, all of which are sitting on physical or virtual infrastructure that can also affect performance, it is impossible to assure that the application will meet service level requirements; or discover and improve application performance - especially from the end user perspective - in production.

Unlike mainframe or client-server computing, application performance as experienced by end users of web-delivered SOA applications cannot be directly correlated with the performance of the computing platforms or network infrastructure. In other words, having servers with "five-9s" (99.999 percent) uptime is no guarantee that the end user is receiving an adequate level of application performance.

Above are just some of the challenges facing IT personnel. The traditional approach of using triage teams-consisting of server, network, application, database and other domain experts-to troubleshoot and recreate performance problems by manually analyzing data from various monitoring tools and log files is frustratingly error prone, labor intensive and slow. Furthermore, this approach is not practical if third party services are incorporated into the application. How can the triage team gain real time access to the service provider's personnel, log files etc. so as to determine the cause of the problem? The answer is more than likely they can't. As you can see, this approach can quickly degrade into a non-productive blame game.

To effectively manage SOA application performance, IT needs a new approach that: (i) accurately detects the occurrence of an end user performance problem, and (ii) pin-points the cause of problems so that the right expertise and tools can be deployed to resolve the issues efficiently.

An End-to end Approach to SOA Performance Management

There are two inter-related facets to this approach:

Because one cannot manage what one cannot measure, there has to be an accurate way to measure application performance. With SOA services, which may depend upon any combination of web, application and/or database tiers of a physical or virtual, local, third-party or hosted infrastructure, it is impossible to use existing server or network performance metrics as a proxy for overall application performance. The only accurate way to measure application performance is to directly measure at the point the real users interacts with the application. For web-delivered SOA applications, the point of interaction occurs at end user's browser. Measuring application performance directly at the real user's browser also has the added benefit of detecting any performance issue attributable to the network, or the end user's computer. It can also accurately measure the performance of Web 2.0 and "mashup" applications.

Once the application performance can be measured from the real user perspective, any slow transaction has to be traced and monitored from end-to-end so that the cause of the slow-down can be pin-pointed. For a complex SOA application, slow downs may occur in the end user's computer, internet cloud, application delivery appliances (including firewall and load balancer), physical or virtual servers within the application owner's infrastructure, third-party service provider's servers, method calls, database queries, or any other components that are in the transaction path of the orchestration. To avoid wasting time and resources in triage team meetings, it is imperative that IT obtains, in near real-time, a holistic view of how an ill-performing transaction is being processed as it traverses its unique transaction path from end-to-end. With this information, IT can quickly spot the bottleneck, whether it is a machine failure, an error or a bug that causes the slow-down. For SOA applications, this transaction tracing methodology should also accommodate machine-to-machine or even third-party calls.

The key success criterion for deploying this SOA management approach is that browser-based performance monitoring has to be carried out in a non-intrusive manner. In other words, monitoring and transaction tracing should not require agent or browser applet download by end users; or code modification like manually adding tags into HTML. With a heightened sense of security, it is difficult if not impossible to convince end users to download any kind of monitoring software. Furthermore, with the ubiquitous nature of Web applications, it is costly to manage and update tens of thousand if not millions of these downloaded agents or applets. Source code modification, on the other hand, is not practical if third-party service and/or packaged applications are involved since it is difficult to convince outside vendors to implant a foreign monitoring function into their code that they might not directly benefit from, but still have to support and maintain.

A practical method of browser-based performance monitoring is to dynamically inject the monitoring instrumentation onto a page as it is served from the Web server or an Application Delivery Controller appliance. No code modification is required. The instrumentation will become part of the page requested by the end user, and will not require an explicit download by the end user or be blocked by the end user's firewall.

Conclusion

The advantage of implementing an end-to-end approach is obvious: IT can proactively detect SOA application performance problems before the end user complains, and be able to quickly pin-point the causes of problems so the right domain expert can be mobilized to solve the right problem. The net result is a decrease in mean-time to problem resolution so that the benefits of SOA deployment are not diluted by application performance and availability issues. Indeed, beyond development and testing strategies, performance management considerations should be an integral part of the deliberation before an organization embarks on an SOA initiative. ENS