One semester in high school, I joined a show choir. After two months, I decided that I had endured all of the step-chasse, step-ball-change, and “jazz hands” that I could stand! I don’t remember any of it now, but I do remember the importance of choreography and coordination among the various participants. What, pray tell, does this have to do with SOA? I’m glad you asked.

Like a well choreographed dance, successful service oriented solutions clearly define roles, responsibilities, and coordinated interaction. Some call it workflow, others choreography, others orchestration, still others talk in more general terms of coordination. There was a time when I thought all of this was a just a semantic game and there was no real difference. While a part of me still questions whether or not we REALLY need all of these different terms, concepts, and standards for the basic idea of ‘making sure everyone and everything does what she/he/it is supposed to’, I am beginning to appreciate the differences among these various concepts.

Orchestration (Executable Business Process)

As organizations mature in their adoption of SOA, they tend to migrate away from a focus upon individual services and toward a focus upon business processes. Orchestration enables an enterprise to fulfill a business process by pulling together a set of service operation calls along with workflow-style business logic and some process-specific variables to maintain persistent state throughout the process. Principally, this is achieved through Business Process Execution Language (BPEL) and a corresponding process engine. BPEL is championed by the likes of Microsoft, IBM, and Oracle (to name a few) and is maintained and actively developed by OASIS.

Choreography (Multi-party Collaboration)

Moving beyond the internal workings of a given organization’s services and orchestrated business processes, choreography is concerned with facilitating the interactions that occur between enterprises. Choreography relates to describing collaboration interfaces between parties. The dominant standard in this space is the W3C’s Web Service Choreography (WS-CDL), a language designed to describe multi-party contracts.

Coordination (Multi-party Context Sharing)

The term ‘coordination’ within the SOA / WS space is far less well understood than either orchestration or choreography. Much of the literature and vendor documentation out there will describe choreography and coordination as being synonymous. This is not quite accurate. To make matters more confusing, the W3C has a Web Services Coordination group. Their job is to coordinate all of the others groups in the WS domain. So what does ‘coordination’ actually mean in the SOA / WS context? It’s really all about sharing context between WS entities, typically to support the prorogation of transaction semantics. OASIS has done a tremendous amount of work in this area under the Web Services Composite Applications Framework (WS-CAF) umbrella. That framework consists of the Web Service Context (WS-CTX), Web Service Coordination Framework (WS-CF), and Web Services Transaction Management (WS-TXM) standards.

Orchestration vs Choreography vs Coordination

So what’s the story here? Are these various workflow-type concepts and corresponding technology standards truly distinct elements that merit unique treatment, or just an example of over-engineering? Although my heart longs for simplicity and clarity in this arena, I do think that there is some value in breaking these notions apart. This is especially true for enterprises that engage in complex, service oriented B2B interactions (typically financial and insurance companies).

Orchestration expresses organization-specific business logic. The entire flow is owned and governed by the organization, even if the flow requires interaction with third parties. Choreography is more collaborative and peer-to-peer in nature, with no central organizing entity. Coordination is a supporting player that can be used in concert with an orchestration or choreography.

So when do you choose one over the other?

• Use orchestration to automate and service orient individual, executable business processes
• Use choreography to describe contractual service interactions between various parties
• Use coordination to define the hand-off of application and business context between various parties

If you’d like to read more on the subject, I recommend the following:

• “Service Orchestration vs Service Choreography”, by John Reynolds
• “Orchestration vs Choreography”, from The ServerSide.com
• “Choreography vs Orchestration” (Orchestra / Dancer Analogy), by Stefan Tilkov
• “Choreography vs Orchestration” (Traffic Light Analogy), by Paul Downey
• “Orchestration, Choreography, Choreostration”, by Jim Alateras

Any thoughts, questions, or war stories to share regarding orchestration, choreography, or similar concepts in SOA?

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…

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.

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.