“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)

I’ve been following the whole SOAP vs REST debate for some time now. I still remember the first time that anyone ever challenged me on why I recommend SOAP to clients and not REST. It was James Duncan Davidson (creator of Tomcat and Ant) and we were speaking together on the “No Fluff Just Stuff” symposium tour in 2001. Frankly, I was dumbfounded. Why don’t I recommend REST? I do recommend rest. I think that a good night’s sleep is very important. James explained it briefly to me and then I set out on learning more about this hidden knowledge. Since that time I’ve gotten educated and even found a few situations where I do suggest REST over SOAP.

Earlier this week, I came across a couple of posts in the blogosphere that caught my eye. The first is a post from the Glassfish community: “Why would I need to be reliable?”. The author identifies three ways in which SOAP solves better than REST: “contract-first” design driven by WSDL, end-to-end security through WS-Security, and reliable message delivery through WS-ReliableMessaging. There were some interesting posts there (especially by Steve Loughran) and then on other discussion boards.

The second post on this topic that caught my eye is from Ryan Heaton. About a month ago he posted a very well reasoned, balanced discussion of SOAP and REST. He makes some great points. As with so many things in life and business, it’s foolish to try and identify the one right answer that will work for every circumstance. SOAP and REST both have their place. But debate sure is a fun way to pass the time…

As SOA increases in maturity and we understand it better, inevitably we develop standards and common design strategies. One such design strategy that I am closing monitoring is the evolution of the Enterprise Service Bus (ESB). In particular, I am interested in the potential development of a standardized SOA middleware framework framework that can be implemented by multiple vendors to supporting portable process definition, component/service assembly, mediation logic, messaging, and a data service layer.

OSOA seems to be making some considerable headway on Service Component Architecture (SCA) and Service Data Objects (SDO). OASIS has certainly cornered the business process / service orchestration side of things with the Business Process Execution Language [which evidentally now is shunning the all upper-case (BPEL) acronym in favor of the much stranger looking (BPel) case]. This still leaves me wanting to see some standardization in mediation logic and messaging. I hope that Chappell and friends will pick up the ball with Synapse and run with it, but it doesn’t appear to be moving especially fast right now. Until then, or until another initiative comes along, I guess I’ll just have to settle for vendor lock-in on the messaging / mediation middle-tier.