Choreography and Orchestration

... I thought, described the same concepts. Here is what people are talking about,

Orchestration always represents control from one party's perspective. This distinguishes it from choreography, which is more collaborative and allows each involved party to describe its part in the interaction.

In orchestration, there’s someone — the conductor — who tells everybody in the orchestra what to do and makes sure they all play in sync.

In choreography, every dancer follows a pre-defined plan — everyone independently of the others.

Orchestration defines procedure and Choreography defines protocol.

Orchestration is generally a full-on execution mechanism for recursive composition of services (aka WS-BPEL). Choreography describes the observable behavior that makes up a contract between a set of peers. It doesn’t say how it is to be achieved just what can be observed. Orchestration is much imperative and choreography declarative. They can work hand-in-hand.

What is the relationship between choreography and web services composition? ... A composite service is a system that arranges existing services in a workflow of some sort (or process if you want) and deploys this arrangement as a service of it’s own. The added value of this system therefore is a previously non-existing functional construct. The key point is that the composite service is indeed a composition and not a simple collection of existing services and that within the composition the service invocations must! be coordinated, e.g. through choreography where the control is centralized. So choreography is a mechanism for coordination (control) in a composite service.

What is Web Services Flow Language? WSFL supports two types of composition and choreography: Flow models: describes business processes; Global models: describe overall partner interactions. Flow models - Describe how to choreograph the functionality provided by a collection of Web services to achieve a particular business need Global models - Describe how a set of Web services interact with each other. ... it was mentioned somewhere that WSFL is superseded by BPEL.

WebService composition can be achieved view two patterns - hierarchical and peer-to-peer. Hierarchical interactions are often found in more stable, long-term relationships between partners, while peer-to-peer interactions reflect relationships that are often established dynamically on a per-instance basis...

Are you in SOA world?

Yes, if you understand and speak the terms above. If no, read a very high level document on SOA -
OASIS Reference Model for Service Oriented Architecture V 1.0 - Official Committee Specification approved Aug 2, 2006. (Normative PDF)

This document talks of reference model, reference architectures and concrete architectures and gives their relationship by way of simple examples.

Why does your business need SOA?

Your software have stood the waves of technology change. And if you were not careful it has withered and your architects make a call to improve it bigtime to improve maintenance cost of old software. What worries you is “Let’s change and try a new approach” approach. There is complexity in your software, part of it is inherent in the domain and part of it is the way software is written. Most of the time when complexity grows enough, technologists wish to try a simple overlying approach, only to find out that some complexity cannot be done away with. You SOA thoughts could be started from your IT department or better you business guys. In any case it is good to have an overarching approach.

You could follow Seagull Software Five Point Plan to SOA (http://www.contactcenterworld.com/view/contact-center-news/SOA-Migration-Must-Be-Driven-By-Business-Needs-And-Not-Technology.asp) :

1. Identify your business pain points and the services you need to offer
2. Forget 'rip & replace'
3. Remember 'wrap & adapt' to service-enable underlying architecture
4. Understand the technology - but don't get bogged down by it
5. Adopt a staged approach to SOA

The first step is to understand business needs. Cutting total cost of ownership is also a business concern. So, it is good for you to find a higher level case for SOA without getting into technological aspects. Next section gives a list of probable causes so that you can think on these lines. Before that we have here some examples of reasons that various industries have.

What are some of the market forces leading your industry toward SOA? (http://www-306.ibm.com/software/solutions/soa/businessleaders.html )

Automotive:	Growing need for multivendor in-vehicle systems/software integrationShift of design and manufacturing among automotive value chains
Banking:	Continued regulatory involvement with added pressure on costs and integration
Electronics:	Disparate systems used in design, development, manufacturing, marketing, and sales
Financial Markets:	Regulatory compliance and automation of trading
Government:	Need to improve oversight, accountability, and compliance
Healthcare:	Increasing pressure to integrate payers, providers, and government agencies
Insurance:	Enhancing customer satisfaction and increasing up-sell/cross-sell opportunities
Retail:	Customize the consumer experience and real-time product availability
Telecom:	Create and connect applications with less development time, expense, and expertise

1.1. Hide organizational boundaries

Collaboration is in and internet is being used to build networks that are far more value adding. The softwares that a business uses have to work with the network partners. And fewer things can cross boundaries, definitely not design guidelines etc. Its difficult to even adhere to interfaces forget platform.

Even inside one company things get complex. If one is building a complex software across multiple teams, one need loose coupling and as less as possible design constraints on architecture. And if you are a company with multiple departments and you have some history, you have a complex situation. Your departments in past have bought different applications so diverse (with totally different architectures, platforms etc.) that they always worked independently with humans acting as integration points. And your departments wish to buy new softwares to enhance the existing functionality. And you start suffering from “How do I make all this work together?” syndrome then SOA can help you a lot.

1.1.1. Across companies

SOA provides you a standard that you can agree and then forget. The toolset in the market will help applications integrate. And you have series of options if you needed visibility into what and how the applications were communicating. SOA perhaps is designed for this kind of scenario.

1.1.2. Intra-company

You can have some sleep at the expense of some performance, which is not really considerable in some applications. This relieves the architect from worrying about yet another architectural concern – will it run together?

1.2. Bridge legacy and new systems

You have this legacy finance system which you wish to integrate with your new online marketing software. The two softwares are similar in only that they are software, rest all is different. The very thought of integrating these raises your hair. You need a new abstraction where you take these two systems a level up, call them as services and them at that higher abstraction you design the integration. All the while being supported by WS integration toolset.

1.3. Bridge current and far future systems

You had an experience like above and you are building a system which you feel that few years down the line will create the same hair raising experience. You wish to be pragmatic and you thing SOA is the abstraction this industry needed and you jump on the bandwagon.

1.4. Design for quality attributes

Some time there are architectural limitations that are put by architects to simplify the architecture. Architects and designers can then focus of other concerns that are of higher importance.

1.4.1. Design of unavailability of sub-systems

By allowing systems to be loosely coupled and lowering the availability of sub-systems, design is eased. One has to expend extra effort in designing highly available systems and this cost could be saved.

1.4.2. Design for ease of adding new sub-system

You have a situation where you are building a piece of a huge system and you either don’t any idea of how many other pieces will come in future or you do not wish to worry about them now. You design the system in min with integratability as a quality attribute.

1.4.3. Paradigm for robust design

Thinking of software as service helps in creating robust systems. With a clear contract – the inputs and outputs of a service and no assumptions on availability of service, the consumer of service can build in robustness instead of falsely assuming availability.

1.4.4. Extreme Rapid Application Development

You have an application team and a business logic team. Your business logic team is concerned with developing assets that your application teams can use to quickly create an application. For example a address validation and correcting functionality was built by business logic team by guessing its need. The application team wishes to use same functionality in multiple applications. And many times application design is dependent on what functionality is present, not only from time to market perspective but the fact that application developers are not aware what can be done now, which was not possible few years back (also called Technology Driven Innovation). You need a component model to manage these assets and SOA is not bad.

1.5. More reading

Service-oriented architecture: A practical guide to measuring return on that investment - http://www-935.ibm.com/services/us/index.wss/ibvstudy/gbs/a1025716?cntxt=a1002583&

Changing the way industries work: The impacts of service-oriented architecture - http://www-935.ibm.com/services/us/index.wss/ibvstudy/gbs/a1025932?cntxt=a1002583&

Blueprint for supply chain visibility: Service-oriented architecture can help drive agility, supplier collaboration and demand-driven replenishment - http://www-935.ibm.com/services/us/index.wss/ibvstudy/gbs/a1028723?cntxt=a1000453&

SaaS, SOA and Cloud Computing - in one breathe

You are a finance manager of small company. You want to give your employees a payroll portal, where they can see breakup of their salary, choose various tax deduction schemes and provide information like bank accounts where salary is to be credited etc.

In earlier era you would buy a software payroll application, buy hardware, hire IT staff to run the application - and all this after very very careful planning. The next version of application comes and you have to plan the migration - safe and non-disruptive. Too much of cost and hassles.

Well, in current era, you would go to a company, say XYZ Payroll and buy a service. The application is hosted, managed and owned by XYZ Payroll. You just get a company setup in it with accounts for all your employees. The data is definited owned by you, but it lives in XYZ Payroll's data center. And you do not pay upfront all the cost, but you pay for subscription - 'Pay as you go' approach. This is SaaS. ASP and onDemand has been precursors of this acronym.

XYZ Payroll doesn't do this just for you, but it has series of clients with same needs. It's software could be multi-tenant or it might host single instances for clients. In either case it benefits from economies of scale, better in former case though.

Now let's say XYZ Payroll doesn't want to invest in hardware and platform management - provisioning systems, managing them etc. So what XYZ Payroll does, it goes to ABC Computing Services and hosts its application there. ABC Computing maintains a huge hardware and has gained lot of expertise in maintaining it. It also provides platform level software services like storage etc. And it gurrantees some availability. What ABC Computing is offering is utility computing, cloud computing, grid computing etc.

What if you were a developer of the application that XYZ Payroll is providing as service? You could design that in traditional way or you could design it in Service-oriented way. That is you build it as a service, using multiple services like say HR&Benefits, Tax etc. This type of Architecture is SOA.

SOA is all about how software is structured and SaaS is all about how software is used.
Bradley F. Shimmin
Principal Analyst of Application Infrastructure, Current Analysis LLC.