Service Oriented Architecture (SOA) - Thought #4 : Orchestration and Choreography

For quite long time, I have heard of people talking about service orchestration and service choreography. Once, during a job interview, I was asked to explain the difference between the two. It seems to me there are confusions between these two terms.

So let’s take a step back to the basics of their definitions. I am copying/pasting the definition from dictionary.com:

Orchestration: (1) to compose or arrange (music) for performance by an orchestra.  (2) to arrange or manipulate, especially by means of clever or thorough planning or maneuvering: to orchestrate a profitable trade agreement.

Choreography: (1) the art of composing ballets and other dances and planning and arranging the movements, steps, and patterns of dancers.  (2) the arrangement or manipulation of actions leading up to an event: the choreography of a surprise birthday party.

Even with the help of dictionary, the real difference between them is quite subtle. My interpretation of the difference is that orchestration is to have a group of participants perform a common activity such as symphony from beginning to end; while choreography is to arrange pieces together to make a thing happen (an event).

Back to the technical world, orchestration is used frequently now to describe assembling, in the SOA arena, services (either atomic or composite) into a business process. This business process can work with other business processes to enable & enhance business capabilities. This is a kind of orchestration. Specifically, the business process service can be controlled and coordinated by a controller service (like a conductor with a symphony if you will). On the other side, choreography is more for peer-to-peer collaborations, such as business to business (B2B) services. It would be interesting to know when and how the term of choreography started to be used as a technical term. One guess from me is the W3C specs of Web Services Choreography Description Language back to year 2004. According to this specs, the web services choreography “is targeted for composing interoperable, peer-to-peer collaborations between any type of Web Service participant regardless of the supporting platform or programming model used by the implementation of the hosting environment”.

Side note: In just one sentence, peer-to-peer referrers to collaboration of servers as oppose to client-to-server .

Service Oriented Architecture (SOA) - Thought #3

One important aspect of a successful SOA effort is to ensure that SOA is governed. The importance of SOA governance is not fully recognized very often until the issues/problems are surfaced. In brief, SOA governance is about people, processes and technology. 

People: SOA aligns the business and IT to work together more flexibly and adaptively. As a result, any SOA project will involve many different parts of an organization, from business domains to IT groups. The side effort of the involvement of this scale is the difficulties resulting in coordination and cooperation. To make SOA a success, organization structure must be shaped to be an enabler. Furthermore, roles and responsibilities must be clearly defined to reduce the risks associated with ambiguity of who is doing what.

Processes: There are two sides of a coin in terms of processes. On one side, a few major processes as an important part of SOA governance framework must be established. For example, SOA governance must have checkpoint process in place to guard SOA activities. On the other side, a set of processes will be followed when services are modeled, assembled, implemented, and deployed. These processes should be governed by governance processes. They are called governed processes.

Technology: Technology and tools can help making governance life easier. For example, registry can facilitate the discovering and publishing services. Repository can store many important metadata associated with services. In addition, tools can be very critical to the success of the implementation of SOA governance.

Service Oriented Architecture (SOA) - Thought #2

What is the value proposition of SOA? It is indeed an old topic, and seems no need to touch it as SOA has already been in the corporate circle for a number of years. However, just very recently I have heard of a few rather confusing arguments, such as SOA is for interoperability, or SOA is for business data management and etc.

From my humble perceptive, I believe there are two major values that SOA can bring us. One is to achieve business & IT agility and flexibility. The intent of SOA is to achieve a better alignment between the business and the IT worlds in a way that makes both more agile. Any company must stay very competitive in the highly demanding market. As a result, companies have to constantly modify/adapt its business model and, consequently, business rules. Historically, an organization IT department/group was always lack of on-demand capabilities to support very dynamical business environment, and was slow to respond the business requirement changes. But now, SOA is promising us that the marriage of business and IT can make business more dynamical and, eventually, more competitive.
 
Another major value of SOA is to provide reuse and sharing of services. IT industry had been widely replying on products and tools. A product is hardly reusable. But services have reuse characteristics. Just taking a simple analogical example, AC unit is a product; it can be installed, but difficult to be re-used by your neighbor (if the unit is installed at your home). However, AC service can be reused anywhere; either you or your neighbor can buy the AC service and use it. Same for SOA, it is to make repeatable business activities as services that can be (re)used widely. In addition, it can be re-arranged easily to meet the different business requirements. To realize SOA, of course, we need to rely on the products and tools where different vendors are trying hard to sell.

(note added on 5/31: there is a good overview article about SOA at http://www.ibm.com/developerworks/library/ws-soa-design1)

Service Oriented Architecture (SOA) - Thought #1

Service oriented architecture is still the topic everywhere in IT. Especially, if you look at any job description of IT architect professions, I bet that you will find this buz word there.

Very recently, I was involved in a discussion with a few techies working for a big insurance company in CA. During the discussion, one of the guys said that SOA is for interoperability. As a courtesy, I didn’t argue with him a lot. However, I was very reserved with his comment.

After the discussion. I felt that I need to put my thought about it straight. Come on, SOA is primarily for business. Business domain knowledge is better to be abstracted as services that can be realized by either atomic or composite service components. The latter are further implemented and automated by IT components / objects. The major purpose of SOA is to make business more automated, flexible and adaptive to changes. 

On the other hand, SOA is not only the Web services (WS) (or SOAP). Web services can be part of implementation of SOA. In other words, implementation of SOA can be achieved with WS/SOAP. I agree with the fact that WS is for the interoperability. But, SOA is not. Just put it simple, if you want to make your whole enterprise SOA architecture interoperable, use ESB (enterprise service bus) or Web service to achieve it.