Orchestration

Organizations that already have employed enterprise application integration (EAI) middleware products to automate business processes or to integrate various legacy environments will likely already be familiar with the concept of orchestration. In these systems, a centrally controlled set of workflow logic facilitates interoperability between two or more different applications. A common implementation of orchestration is the hub-and-spoke model that allows multiple external participants to interface with a central orchestration engine.

One of the driving requirements behind the creation of these solutions was to accommodate the merging of large business processes. With orchestration, different processes can be connected without having to redevelop the solutions that originally automated the processes individually. Orchestration bridges this gap by introducing new workflow logic. Further, the use of orchestration can significantly reduce the complexity of solution environments. Workflow logic is abstracted and more easily maintained than when embedded within individual solution components.

The role of orchestration broadens in service-oriented environments. Through the use of extensions that allow for business process logic to be expressed via services, orchestration can represent and express business logic in a standardized, services-based venue. When building service-oriented solutions, this provides an extremely attractive means of housing and controlling the logic representing the process being automated.

Orchestration further leverages the intrinsic interoperability sought by service designs by providing potential integration endpoints into processes. A key aspect to how orchestration is positioned within SOA is the fact that orchestrations themselves exist as services. Therefore, building upon orchestration logic standardizes process representation across an organization, while addressing the goal of enterprise federation and promoting service-orientation.

Figure 6.32. An orchestration controls almost every facet of a complex activity.

A primary industry specification that standardizes orchestration is the Web services Business Process Execution Language (WS-BPEL). This book recognizes WS-BPEL as a key second-generation extension and therefore uses its concepts and terminology as the basis for a number of discussions relating to business process modeling.

Note

WS-BPEL is the most recent name given to this specification, which also is known as BPEL4WS and just BPEL. For an overview of the primary parts of the WS-BPEL language and a discussion of how the name change came about, see Chapter 16.

In Plain English

After successfully washing several cars together, Chuck, Bob, Jim, and I decide to start our own company. We formalize the steps in our car washing process so that we can handle different types of cars with different cleaning requirements.

Our process is therefore affected by the following new requirements:

• We decide to hire extra help during peak hours. This introduces up to two additional members that join our team.
• Because we have no venture capital for this business, we make an arrangement with a local gas station. In exchange for using a portion of their lot for our car washing operation, we agree to help out with the gas pumping duties during their peak hours.

Our simple car washing process now has become significantly more complicated. The process is no longer fixed in that it can change at any given time as a result of various conditions and events.

• When our extra workers arrive, the task allocation of the entire team is altered.
• When gas station personnel need extra help, we are obligated to send one or more of our car washing team members to assist them.

These examples relate to predictable conditions that occur on a daily basis. Our operation is further affected by some constraints:

• If our cash flow falls below a certain amount, we are unable to afford part-time workers.
• If it rains, all work is suspended (also leading to reduced cash flow).

These constraints introduce conditions that are less common, but which we always need to take into consideration. To accommodate these potential situations, we come up with a plan that maps out our expanded process and provides alternative processes for dealing with both common and uncommon conditions.

This plan is essentially a workflow that joins individual steps with processes and sub-processes partitioned by decision points. This elaborate workflow incorporates our original process with the gas station's process and the extended process resulting from the arrival of our part-time workers. This workflow is essentially an orchestration that manages the individual process requirements and related resources, participants, events, business rules, and activities.

 

6.6.1. Business protocols and process definition

The workflow logic that comprises an orchestration can consist of numerous business rules, conditions, and events. Collectively, these parts of an orchestration establish a business protocol that defines how participants can interoperate to achieve the completion of a business task. The details of the workflow logic encapsulated and expressed by an orchestration are contained within a process definition.

6.6.2. Process services and partner services

Identified and described within a process definition are the allowable process participants. First, the process itself is represented as a service, resulting in a process service (which happens to be another one of our service models, as shown in Figure 6.33).

Figure 6.33. A process service coordinating and exposing functionality from three partner services.

Other services allowed to interact with the process service are identified as partner services or partner links. Depending on the workflow logic, the process service can be invoked by an external partner service, or it can invoke other partner services (Figure 6.34).

Figure 6.34. The process service, after first being invoked by a partner service, then invokes another partner service.

 

6.6.3. Basic activities and structured activities

WS-BPEL breaks down workflow logic into a series of predefined primitive activities. Basic activities (receive, invoke, reply, throw, wait) represent fundamental workflow actions which can be assembled using the logic supplied by structured activities (sequence, switch, while, flow, pick). How these activities can be used to express actual business process logic is explored in Chapter 16.

6.6.4. Sequences, flows, and links

Basic and structured activities can be organized so that the order in which they execute is predefined. A sequence aligns groups of related activities into a list that determines a sequential execution order. Sequences are especially useful when one piece of application logic is dependent on the outcome of another.

Flows also contain groups of related activities, but they introduce different execution requirements. Pieces of application logic can execute concurrently within a flow, meaning that there is not necessarily a requirement for one set of activities to wait before another finishes. However, the flow itself does not finish until all encapsulated activities have completed processing. This ensures a form of synchronization among application logic residing in individual flows.

Links are used to establish formal dependencies between activities that are part of flows. Before an activity fully can complete, it must ensure that any requirements established in outgoing links first are met. Similarly, before any linked activity can begin, requirements contained within any incoming links first must be satisfied. Rules provided by links are also referred to as synchronization dependencies.

6.6.5. Orchestrations and activities

As we defined earlier, an activity is a generic term that can be applied to any logical unit of work completed by a service-oriented solution. The scope of a single orchestration, therefore, can be classified as a complex, and most likely, long-running activity.

6.6.6. Orchestration and coordination

Orchestration, as represented by WS-BPEL, can fully utilize the WS-Coordination context management framework by incorporating the WS-BusinessActivity coordination type. This specification defines coordination protocols designed to support complex, long-running activities.

6.6.7. Orchestration and SOA

Business process logic is at the root of automation solutions. Orchestration provides an automation model where process logic is centralized yet still extensible and composable (Figure 6.35). Through the use of orchestrations, service-oriented solution environments become inherently extensible and adaptive. Orchestrations themselves typically establish a common point of integration for other applications, which makes an implemented orchestration a key integration enabler.

Figure 6.35. Orchestration relating to other parts of SOA.

These qualities lead to increased organizational agility because:

• The workflow logic encapsulated by an orchestration can be modified or extended in a central location.
• Positioning an orchestration centrally can significantly ease the merging of business processes by abstracting the glue that ties the corresponding automation solutions together.
• By establishing potentially large-scale service-oriented integration architectures, orchestration, on a fundamental level, can support the evolution of a diversely federated enterprise.

Orchestration is a key ingredient to achieving a state of federation within an organization that contains various applications based on disparate computing platforms. Advancements in middleware allow orchestration engines themselves to become fully integrated in service-oriented environments.

The concept of service-oriented orchestration fully leverages all of the concepts we've discussed so far in this chapter. For many environments, orchestrations become the heart of SOA.

Case Study

The series of steps we wrapped into a business activity in the previous case study example demonstrated how TLS used the WS-BusinessActivity protocol to add context management and exception handling to a long-running, complex activity. Even though the scope of a business activity can constitute a business process, it does not provide TLS with a standard means of expressing the underlying workflow logic. For that, TLS employs a WS-BPEL orchestration (Figure 6.36).

Figure 6.36. The extended TLS Purchase Order Submission Process managed by an orchestration and involving numerous potential partner organizations.

 

The orchestration establishes comprehensive process logic that encompasses the business activity and extends it even further to govern additional interaction scenarios with multiple vendor services. For example, when one vendor cannot fulfill an order, the next vendor in line is sent the same purchase order. This cycle is repeated until either one vendor can complete the order in its entirety (within certain price limitations) or until all vendors have been queried. In the latter situation, the system simply assesses the best deal on the table by applying a formula that takes into account the price, percentage of order to be filled, and backorder terms.

The orchestration logic manages all aspects of the process, including the involvement of multiple vendor partner services, as well as the business activity that kicks in when a PO is processed.

SUMMARY OF KEY POINTS

• An orchestration expresses a body of business process logic that is typically owned by a single organization.
• An orchestration establishes a business protocol that formally defines a business process definition.
• The workflow logic within an orchestration is broken down into a series of basic and structured activities that can be organized into sequences and flows.
• Orchestration has been called the "heart of SOA," as it establishes a means of centralizing and controlling a great deal of inter and intra-application logic through a standardized service model.