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.
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.
SUMMARY OF KEY POINTS |
---|
|