John Reynolds's Blog

January 2006 Archives

Service Orchestration vs. Service Choreography

Do you know the difference between Web Service Orchestration and Web Service Choreography?

The distinction between WS-Orchestration and WS-Choreography is important to understand, but unfortunately the vocabulary that we are defining for dealing with web services and SOA is... uh... (How shall I put it?)... unhelpful.

One definition that I found for "orchestration" on the web is the following:

"Orchestration or arrangement is the study and practice of arranging music for an orchestra or musical ensemble. In practical terms it consists of deciding which instruments should play which notes in a piece of music."

A similar search for the definition of "choreography" returned the following:

Choreography is: "the arrangement and movement of performers onstage; though the term cutomarily applies to dancers, it is also used to denote the orchestrated movement of actors, especially in stage combat"

Based on these definitions, Orchestration is about music and Choreograhy is about dance... but for some odd reason this doesn't help me grok the distinction between WS-Orchestration and WS-Choreography.

The real distinction lies not in the dictionary, but in the differences between the Business Process Execution Language (WS-BPEL) and the Web Services Choreography Description Language (WS-CDL).

Orchestration == Executeable Process

Web Service Orchestration relates to the execution of specific business processes. WS-BPEL is a language for defining processes that can be executed on an orchestration engine.

Choreography == Multi-party Collaboration

Web Service Choreography relates to describing externally observable interactions between web services. WS-CDL is a language for describing multi-party contracts and is somewhat like an extension of WSDL: WSDL describes web services interfaces, WS-CDL describes collaborations between web services.

Ah, if only the "C" in WS-CDL was for "Collaboration" instead of for "Choreography"... life may have been a little simpler ;-)

SOA/ESB Level Set

	This figure shows the basis of an application developed using SOA principles and an ESB. Specific services are plugged into the bus, making them available to any application.
The service bus is responsible for routing messages to and from each service, eliminating the problems associated with "point-to-point" programming. Many ESBs are built on top of reliable messaging technologies. Messages are often XML based, but some ESBs allow for multiple protocols and formats. Applications are composed by developing driver programs that orchestrate the available services. Languages such as BPEL are tailored for writing these "driver" programs. Any number of "driver" programs can be written to utilize the services on the bus.
	If the application requires a user interface it is generally bolted on to the driver program.
Any user interface technology can be used; Rich Interfaces using Swing, Browser Interfaces using JSF and/or AJAX.
	If the application requires an external interface to the world beyond the service bus, those interfaces are also generally bolted on to the driver program.
Although it is certainly possible to expose all of the services to the outside world, that is usually not desirable. Generally only "composite services" that represent a service offered to a business partner will be exposed. Before exposing any service to the outside world, security issues must be addressed.
	Legacy programs are added to the mix by creating custom “service adaptors” between the legacy code and the service bus.
The success of integrating any legacy asset into the mix is related to the difficulty of crafting an adaptor (a.k.a. connector) for that asset. If the adaptor is fairly straight-forward, successful integration is more likely. If the adaptor is convoluted, only minimal success is likely. Although reuse of legacy assets is touted as a major SOA selling point, in reality many legacy assets will require refactoring to be of much use. The real payoff is adopting a style of programming that will make new services much easier to reuse later.
	The services that are plugged into the bus should be loosely coupled. Invoking one service should ideally have no side effect on other services. Care must be taken if the services directly access a shared database.
If services share records in a common database, they are coupled in a manor that may not be obvious to the author of the driver program. "Hidden" coupling in an underlying database can be a real problem. When possible, services should be stateless and operate only on the documents that are passed to them.
	To avoid hidden database coupling, some vendors recommend plugging a data service into the service bus.
The primary concern with the data access service approach is the performance issue associated with accessing all data through the bus. The use of data access services has let to several related ideas, such as using Service Data Objects to pass working data between services.

Please let me know what else you think I should add...

What do programmers really need to know?

"...there's nothing hard enough about Java to really weed out the programmers without the part of the brain that does pointers or recursion..."

"But beyond the prima-facie importance of pointers and recursion, their real value is that building big systems requires the kind of mental flexibility you get from learning about them, and the mental aptitude you need to avoid being weeded out of the courses in which they are taught. Pointers and recursion require a certain ability to reason, to think in abstractions, and, most importantly, to view a problem at several levels of abstraction simultaneously. And thus, the ability to understand pointers and recursion is directly correlated with the ability to be a great programmer."

There's a lot of lousy software "out there".

A lot of software "out there" is great, but it contains pervasive security flaws.

A lot of software "out there" is great, but it is way too expensive to maintain.

• Flaw in Microsoft's Windows Meta File Vulnerability in Graphics Rendering Engine Could Allow Remote Code Execution announced December 28th, 2005
• Microsoft Internet Explorer PNG Image Rendering Buffer Overflow Vulnerability released June 16, 2005.
• Firefox and Mozilla IDN buffer overflow security issue disclosed on September 8th, 2005.
• Annual software maintenance cost in USA has been estimated to be more than $70 billion.
• The Cyber Security Bulletin 2005 Summary lists 5,198 reported security vulnerabilities last year.

Maybe mastering a "hard" programming language isn't much of a factor after all.

What do programmers really need to know in order to produce exceptional software?

I agree with Joel that the abilility to "to view a problem at several levels of abstraction simultaneously" is very important... But...

I think that really exceptional programmers have the ability to focus on concrete requirements. Programs are written to solve concrete problems. Abstractions have a way of taking on a life of their own, and that can lead to software that is hard to maintain when a "concrete" requirement changes.

I'll admit that it is a stretch, but even "buffer overflow" problems can be characterized a symptom of misunderstanding a basic concrete requirement (the program should gracefully handle unexpected input).

In some instances, the overhead associated with bounds checking allocated memory is unacceptable, but it is hard to see how a browser would need performance optimized to such a level.

One way to keep focused on the concrete requirements is to test compliance with those requirements all throughout the development life cycle. If you start with a test plan, you'll focus on passing the test.

The great programmer may be the guy who is most adept at writing the "right" test plan (You don't want to waste time passing meaningless tests).

Maybe teaching Test Driven Development is as important as teaching pointers and recursion?

What do you think programmers need to know?

Continue Reading...

This work is licensed under a Creative Commons License.