In Chapter 6 we introduced a concept that ties into and actually extends the reach of service-orientation. This concept is orchestration. When incorporated as part of a service-oriented architecture, orchestration assumes the role of the process part we established in the Anatomy of a service-oriented architecture section.
Orchestration is more valuable to us than a standard business process, as it allows us to directly link process logic to service interaction within our workflow logic. This combines business process modeling with service-oriented modeling and design. And, because orchestration languages (such as WS-BPEL) realize workflow management through a process service model, orchestration brings the business process into the service layer, positioning it as a master composition controller.
The orchestration service layer introduces a parent level of abstraction that alleviates the need for other services to manage interaction details required to ensure that service operations are executed in a specific sequence (Figure 9.5). Within the orchestration service layer, process services compose other services that provide specific sets of functions, independent of the business rules and scenario-specific logic required to execute a process instance.
Figure 9.5. The orchestration service layer.
These are the same process services for which we defined the process service model described in Chapter 6. Therefore, all process services are also controller services by their very nature, as they are required to compose other services to execute business process logic. Process services also have the potential of becoming utility services to an extent, if a process, in its entirety, should be considered reusable. In this case, a process service that enables orchestration can itself be orchestrated (making it part of a larger orchestration).
Also worth noting is that, as explained in Chapter 6, the introduction of an orchestration layer typically brings with it the requirement to introduce new middleware into the IT infrastructure. Orchestration servers are by no means a trivial addition and can impose significant expense and complexity.
Neither TLS or RailCo employ process services or a separate orchestration layer. As with many organizations, TLS is interested in orchestration but is uncertain as to the technology that supports it and the impact it would have on their current service architecture. By the time we reach Chapter 16, TLS will have decided to give orchestration a try. As a result, our case study will progress in that chapter to the point where we build a WS-BPEL business process definition for TLS that establishes an official orchestration service layer.
SUMMARY OF KEY POINTS
Part I: SOA and Web Services Fundamentals
The Evolution of SOA
Web Services and Primitive SOA
Part II: SOA and WS-* Extensions
Web Services and Contemporary SOA (Part I: Activity Management and Composition)
Web Services and Contemporary SOA (Part II: Advanced Messaging, Metadata, and Security)
Part III: SOA and Service-Orientation
Principles of Service-Orientation
Part IV: Building SOA (Planning and Analysis)
SOA Delivery Strategies
Service-Oriented Analysis (Part I: Introduction)
Service-Oriented Analysis (Part II: Service Modeling)
Part V: Building SOA (Technology and Design)
Service-Oriented Design (Part I: Introduction)
Service-Oriented Design (Part II: SOA Composition Guidelines)
Service-Oriented Design (Part III: Service Design)
Service-Oriented Design (Part IV: Business Process Design)
Fundamental WS-* Extensions
Appendix A. Case Studies: Conclusion