“SOA is fine, unless of course you want a system with decent performance.”
“XML is slow and all the added layers that SOA demands will cripple any marginally high-transaction system.”

I’ve heard uneducated statements like these, and many others regarding SOA, XML, and the prospect of service orienting high performance, mission-critical systems. The truth is, that these statements are ill-informed and those that make them rarely have anything beyond vague anecdotes from “some Fortune 500 company a few years ago” to back them up.

Generalizing SOA

First, we’ll start with some broad sweeping generalizations regarding SOA. These have some truth to them and do, in fact, characterize a typical utilization of SOA. In general, SOA is realized as follows:

• Multiple layers of abstraction
• Standard XML message format (typically SOAP)
• Standard Web transport (typically HTTP)
• Non-reliable (no guaranteed delivery by default)
• Oriented more toward reuse and agility rather than performance or scalability

Breaking the perception barrier

There is more than one way to skin a cat and there is more than one way to implement SOA. HTTP is simple and cheap, but not robust or performant. HTTP-based SOA’s are certainly the most common as they are simple to setup, simple to exploit, cheap, and widely available. The problem is that HTTP isn’t reliable, suffers from high latency, has limited bandwidth, and does not offer any sort of message buffering or message durability. High performance SOA solutions must take a different approach. Messaging middleware solutions such as IBM WebSphere MQ, SonicMQ, or TIBCO hold one answer. These platforms are designed with scalability and performance in mind and are increasingly supporting SOA right out of the box.

High Performance SOA

Designing a high performance SOA solution is possible. Gerardo Pardo-Castellote, PhD, recommends the following steps:

• Select a Messaging Fabric/Bus
• Select an appropriate Architecture (hub-spoke, clustered, federated, peer-to-peer)
• Identify Quality of Service requirements (reliability, latency, flow control, lifespan, history, transport priority, etc.)
• Leverage Performance Technologies (multicast, message batching, asynchronous writes, compression, etc.)
• Select and monitor appropriate Metrics (throughput, latency, scalability, etc.)

Still skeptical? Consider the following examples:

• Network Management example
• Data Sharing example
• Data Fusion example
• Emergency Response example

As with so many things, there just is no simple answer. The only absolute is that there are no absolutes. SOA is a style of enterprise architecture for which the focus tends to be more upon flexibility and reuse. However, to the extent that solution performance is a priority, the architecture can be tweaked accordingly.

For further reading on this topic, I suggest the following:

• High Performance SOA (Jason Bloomberg)
• High Performance SOA - A Contradiction in Terms? (Patrick Leonard)
• Implementing a High Performance SOA (gridwisetech.com)
• High Performance SOA with Software Pipelines (Cory Isaacson)

Last month, Aberdeen Group released a report detailing the findings from analyzing the service orientation results over a period of eighteen months for approximately 400 companies. The analysis revealed a ‘deep division’ between enterprises that simply deploy ‘a bunch of Web services’ and those that take a more strategic and comprehensive approach to service orientation. A lot of great analysis of these findings has emerged within the blogosphere:

• Survey: Done right, SOA pays by Joe McKendrick
• SOA Beginning to Pay Off by David Linthicum
• Survey points to SOA pay off by Tom Jowitt

I’ll let you dig through the report as well as the above posts for more details, but I would like to highlight one interesting aspect of the report. Aberdeen identifies three classifications of SOA maturity that categorize the survey respondents:

1. Best-in-Class (top 20% of aggregate performance scorers) - Characterized by organizations that prioritize investments in education/training, architecture, SOA middleware and infrastructure, and processes aimed at measuring and tweaking performance
2. Average (middle 50% of aggregate performance scorers) - Characterized by organizations that have made minor investments in SOA middleware and infrastructure, very little in education/training, and have virtually ignored organizational performance measurement metrics for refining the enterprise
3. Laggards (bottom 30% of aggregate performance scorers) - Characterized by organizations that have made little to no investment in SOA tools or training/education, tend to deploy Just a Bunch of Web Services (JBOWS), and virtually ignore the importance of governance

Beyond just identifying and labeling these groups, the report provides some compelling metrics around how these three categories drastically impact the ROI realized from service orientation. For example, every one of the Best-in-class organizations saw a reduction in application development costs, compared with only 59% of Average organizations. Those companies identified as Laggards, however, actually saw an increase in application development costs. Similar trends were identified regarding maintenance costs and impacts to user satisfaction.

So the question remains – Are you a SOA Laggard?

I’m pretty excited about the recent release of JAX-WS 2.1. The 2.1 build is a complete re-architecture aimed at performance and extensibility and the JAX-WS team has been working on it for nearly a year. They have FINALLY shed the old JAX-RPC skin and done a full redesign. The new release also includes WS-Addressing support and JAXB 2.1 support.

I’m also very interested in the on-going work on the Eclipse SOA Tools Project (STP). I haven’t gotten an opportunity to play with it yet, but it looks to be pretty extensive. I also like that it is built around JAX-WS.