In the world of information technology, the concept of abstractions are particularly handy. Take, for example, the services abstraction at the heart of SOA, which masks the complexity of the underlying technology implementation while presenting composable business services to internal and external users. But every abstraction comes at a price, and the services abstraction is no exception. Loose coupling, composability, agility, and the other benefits of SOA all introduce performance overhead. For limited sets of services with small numbers of users, this performance hit may be minimal. For SOA implementations with large numbers of users, services, or traffic, however, maintaining the necessary performance levels presents a substantial challenge, both to the architects who design the infrastructure as well as IT operations personnel who are responsible for keeping the lights on.
In fact, in SOA environments with the highest performance requirements, maintaining the services abstraction in the face of high traffic is a paramount concern. Fail to maintain the abstraction, and the services no longer meet the agile needs of the business, and the quality of the SOA implementation comes crashing down like a house of cards.
Performance beneath the services abstraction
The SOA performance problem falls into two broad areas: ensuring sufficient performance of atomic services as well as of composite services. Atomic services provide service interfaces that abstract existing systems, so ensuring their performance necessitates managing the performance of the components, applications, and systems that lie beneath the services abstraction. As you might expect, dealing with the performance of atomic services leverages well-established capacity planning and performance quality assurance (PQA) techniques, including clustering, virtualization, and load testing. Today's architects are adept at making infrastructural decisions that ensure, for example, s
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
ufficient database performance, distribution of traffic onto a cluster of application servers, and the like.
Furthermore, traditional PQA also serves atomic services well. Simulating loads on service interfaces is quite similar to simulating traditional Web page performance, after all -- and many Web Service PQA tool vendors have predictably based their products on Web page PQA tools that performance test traditional Web applications via their Web interfaces. But while Web Services share some similarities with Web pages, there are some fundamental differences. In particular, Web page interactions are usually request/reply, but Web services support a wide variety of interaction styles, including asynchronous, synchronous, event-driven, publish/subscribe, and one-way. Load testing a Service that has such a wide range of interaction styles requires more sophisticated tooling than traditional Web page-centric PQA tools.
Performance above the services abstraction
While SOA manifestly relies upon services, there is far more to properly architecting SOA than simply building a bunch of services. Architects must consider the consumption of those services as well, including the dynamic, business-driven composition of services into Service-Oriented Business Applications (SOBAs). Unfortunately, the very nature of SOBAs as flexible, continually changing, potentially ad hoc compositions presents complex performance challenges to architects and operations personnel alike.
In fact, there are several dimensions of SOBA performance that architects must consider as they plan their SOA:
Tackling the SOA Performance Problem
Dealing with performance bottlenecks is like playing whack-a-mole: defeat one and another immediately pops up. Even worse, implementing SOA just increases the number of moles you have to whack. It's essential, therefore, for the architect to plan for performance bottlenecks at different levels, both above and beneath the Services abstraction. In other words, the architect must craft a performance plan that might take advantage of some combination of the following approaches:
The ZapThink take
Analyzing SOA performance highlights the fact that SOA is more evolutionary than revolutionary. Architects must still know how to use every capacity planning and performance enhancement tool in their toolbelt, only now they're able to add a few new tools to the mix. In fact, there's no way we'd be able to figure out how to scale Web services if we hadn't already worked out how to scale traditional Web applications.
It's also important to note that SOA performance is about more than ensuring that Services perform as required, just as SOA is about more than building Services. SOA best practices also cover the consumption of Services -- within SOBAs as well as at the user interface. As a result, the comparatively mundane world of SOA performance has direct relevance to the sexy world of Enterprise Web 2.0. After all, no enterprise would depend upon rich, collaborative applications if there were no way to ensure their performance.
Finally, dealing with SOA performance requires an Enterprise Architecture approach to SOA. Those bottleneck moles in the whack-a-mole game can appear anywhere in the enterprise, at any level of abstraction. The fact that SOA hides the complexity of the infrastructure from the user only exacerbates the need for an enterprise perspective, because high quality, high performance SOA requires high performance from every part of the enterprise.
