email article
	printer friendly
	more resources

The Ins and Outs of Orchestration
Learn how orchestration provides an open standards-based approach for connecting Web services.
by David S. Linthicum

With the proliferation of Web services, you need a common process integration layer between them to create business solutions. Orchestration can help you. Orchestration, simply put, provides an open standards-based approach for connecting Web services to create high-level business processes. Clearly, orchestration is important to enterprise architects, especially those tasked with defining and building SOAs within their organization or trading community. So it's important that architects understand the ins and outs of this technology: how it fits, where it fits, and how to leverage it.

Like much of today's Web services technology and standards, orchestration is based on more traditional technology. Over the years, the industry came up with a number of terms to define how systems can interact to form business processes. These first-generation concepts included workflow, document management, and business process management (BPM).

Early BPM systems enabled a business to build a top-down process design model that could be bound to back-end systems, such as legacy and ERP, and automated the processes between these back ends. These typically information-oriented BPM systems controlled logic, sequencing, exception handling, and like activity to monitor and manipulate simple information flows between enterprise source and target systems.

Similarly, orchestration takes into account the concept of services as well as information bound to those services, and provides standard logical operators for defining how orchestrations are carried out. Moreover, orchestrations are built to become composite applications unto themselves, reusable as services by other composites or within other orchestrations.

Orchestrations might span a few internal systems, systems between organizations, or both. Moreover, orchestrations are long-running, multistep transactions, almost always controlled by one business party. They are also loosely coupled and asynchronous in nature (see Figure 1).

Orchestration must provide dynamic, flexible, and adaptable mechanisms to meet the changing needs of the domain. You accomplish this through the separation of process logic and the back-end services that you employ. The loosely coupled nature of orchestration is key because there are no requirements for all services to be up and running at the same time in order for orchestrations to run. This trait is also essential for long-running transactions. Also, as services change over time, you typically don't need to alter the orchestration layer to accommodate the changes if they are architected properly.

So you can consider orchestration another complete layer over and above more traditional application integration approaches, including information- and service-oriented integration. Orchestration encapsulates these integration points, binding them together to form higher-level processes and composite services. This makes orchestration a bit different than traditional application integration approaches in these ways:

• A single instance of orchestration typically spans many instance of service- and information-oriented points of integration, perhaps many integration domains and even organizations.
• Orchestrations are usually driven from a single party; they are not always collaborative in nature.
• Orchestrations can become services available for other services or orchestrations.
• Traditional application integration typically means the exchange of information between two or more systems without much visibility into internal processes and services. In contrast, orchestration defines a meta-application that has visibility into many encapsulated application services (Web services) as well as application information that can be bound to those services.
• Orchestration is independent of the source and target systems. You can change the orchestration without having to change the source or target systems.
• Traditional application integration is typically a tactical solution, motivated by the requirement for two or more applications to communicate. Orchestration is strategic, leveraging business rules to determine how systems should interact and better leverage the business value from each system through a common abstract business model.

A few standards have emerged in support of orchestration, including BPEL, WSCI, and BPML. I’ll discuss all of these, focusing mostly on BPEL due to its momentum in the marketplace.