Up until now, there has been such a rush to roll out initial SOA services and supporting infrastructure, that little attention has been given to what good service design truly entails.  This is a natural evolution that must occur with any technology or methodology.  Throughout this summer, I plan on releasing several posts regarding proper service design.

Initially, I would like to focus on the subject of ‘composability’.  Composable services have several important qualities:

• composable services stictly adhere to their service interface, Service Level Agreements(SLAs), and supporting metadata
• service operations always leave enterprise data in a valid business state
• service operations can be called indepently, in parallel, or as a part of a larger service orchestration
• service operations can be called within or without a transaction context

When you boil it down to the essentials, composable services clearly define what they do and they do exactly what they have defined.  Consumers of composable services are then at liberty to determine how they want to use that service’s operations, rather than the service having certain built-in assumptions regarding how the service will be used or what the larger business context ought to be.

To learn more about the merits and details of composable services, I recommend the following resources:

• “Composable Services” (MSDN Library)
• “Service Composability” (SOAprinciples.com)
• “A Composable Service is a Good Service” (Presentation at SOAWorld 2008 next week)

There’s another, less tangible benefit of composable services — they are lower stress.  The frustration and stress associated with consuming a service that later fails due to some unknown buisiness logic violation is supremely frustrating.  Consuming services that are not composable is stressful, because they cannot be depended upon to work in whatever context you choose.  Likewise, publishing non-composable services for consumption is stressful because the service provider is constantly in fear that someone will ‘misuse’ a service.  This is no way to run an enterprise or encourage the adoption of service orientation. 

I’ll explore all of these topics next week in my presentation at SOAWorld on composable services.  I’ll post the completed presentation as well as perspectives from the audience next week.  Have a great weekend and I’ll see you in New York!

“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 traveling and teaching a lot since the SOAWorld conference. This past week, a couple of my students challenged me on some statements that I made during the course regarding the notion that Microsoft has arrived a bit late to the SOA table. I find this particularly interesting considering the fact they Microsoft was so instrumental in the early Web services innovations around SOAP, WSDL, etc., but it seems that they have gotten distracted with lawsuits, Office, and Vista, and taken a while to come along with a comprehensive SOA story and supporting infrastructure.

After some interesting and sometimes heated discussions, these students points me toward some resources that shed some interesting light on what Microsoft has been working on. I must admit that I had lost track of .NET 3.0 and the evolution of Indigo into the Windows Communication Foundation (WCF). The work that Microsoft has done in this arena is quite impressive and, in true Redmond fashion, elegantly simple. Additionally, one of the students turned me on to Juval Lowy, who has been recognized by Microsoft as a Software Legend and a Regional Director for Silicon Valley. Juval is the brains behind IDesign, a great resource for .NET 3.0, and provides master-level workshops on .NET 3.0 and especially the WCF. The guy is brilliant, has a fascinating perspective on SOA, and a rather compelling and authoritative delivery style. To get a taste you can check out one of his MSDN Webcasts: Applying Service-Orientation to Your Development Process.

On a parallel thread, I ran across an interesting article from Redmond Magazine: “Microsoft Does Have a SOA Strategy“. Dana Gardner, who is quoted in the article, blogs on this subject and describes the strategy as ’service-enabled’ and ’sorta-SOA’. Another analyst quoted in the Redmond article describes Microsoft’s strategy around SOA as ’standards-based at the edge’. The article also identifies that Microsoft is focusing more upon empowering individuals and small teams rather than ’selling a big, fat SOA stack’. This is certainly consistent with their strategy in other areas of the enterprise. The reality of, course, is that Redmond will not sit idle while the IBMs, Oracle’s, and SAPs of the world carve up the enterprise marketplace. More infrastructure components are coming from Microsoft in the next iteration of Biztalk and the full realization of .NET 3.0, especially the Workflow Foundation (WF) piece.

One final thread regarding Microsoft’s SOA strategy is an apparent attempt to take the ‘ESB leadership’ that the big Java vendors have managed to secure in the industry and turn it around as a liability. Rather than trying to compete against these established ESB vendors directly, Microsoft is attempting to paint the notion of an ‘enterprise’ bus as short-sighted and internally-focused strategy. The next generation, according to Redmond, is the Internet Service Bus (ISB) which turns the attention outward to the extended-enterprise, consisting of partners, clients, and the information superhighway at large. Whereas traditional ESB solutions focus within the enterprise. The ISB turns the attention to interaction between enterprises. I’m not sure how much of that is real and how much is fluffy rhetoric, but it is an intriguing perspective.

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…