5.5. The process orchestration layerThe process orchestration layer contains the key mechanisms that create the flexibility that ESA must deliver to succeed. Enterprise services are the reusable building blocks built on top of business objects. Process orchestration is the simpler way that these building blocks are combined to solve problems. The word orchestration has many different meanings in many contexts. Some people prefer the word choreography, which is sometimes used to mean the same thing. Orchestration became associated with SOA in the past few years because of the idea of web services orchestration, which was an attempt to create a language that could be used to combine web services to automate processes. Eventually, different standards efforts championed by different vendors were combined into the Business Process Execution Language (BPEL) standard. When many people speak of orchestration, they are referring to using BPEL to orchestrate the behavior of web services. But this is only one form of process orchestration as we use the term in this book. 5.5.1. What is process orchestration?Since programming began, applications have controlled process flow. That is not what we mean by orchestration. We use the term to mean a form of modeling in which a simple set of abstractions is combined repeatedly to help solve a problem. The job of orchestration is to replace coding in Java and ABAP with modeling so that process orchestration is easier and more flexible, and can be performed by more people. As modeling tools have improved, more people have begun modeling. Process orchestration is one form of modeling. Modeling is also used heavily to create UIs and to manage system landscapes among other applications. For this book, we will expand the notion of orchestration to include not only the high-level orchestration of enterprise services, but also the orchestration of any process using a simplified method, whether it is a guided procedure that is controlling the flow of work through a UI, or a workflow modeling technique in SAP NetWeaver AS. By "simplified method," we mean a mechanism that is much easier to use than Java or ABAP coding but that still has the power to allow a process to be constructed out of building blocks. The building blocks for BPEL are web services; in ESA, they are enterprise services. For guided procedures, the building blocks are callable objects of various sorts, including enterprise services, Adobe Interactive forms, and UI elements such as iViews. For workflow mechanisms in SAP NetWeaver AS, they are Java or ABAP objects. For process components, the building blocks are collections of enterprise services and business objects working together to solve a problem. No matter what the building blocks are, the orchestration layer has a similar job. It must carry out the following tasks:
These tasks take on different forms based on the orchestration being implemented. 5.5.2. Why is process orchestration important in ESA?Without process orchestration, the logic that controls processes must be coded in Java or ABAP. This makes the orchestration process difficult and complex, which shrinks the pool of people who can design and implement processes. Orchestration mechanisms simplify the process of defining an orchestration, usually through some model-driven development technique, which not only allows orchestrations to be created quickly but also allows them to be changed quickly. Process orchestration also serves as a bridge between IT and business and as a form of documentation. Instead of writing a lengthy requirements document, process orchestration mechanisms can allow business analysts to describe, in an executable form, the automation of processes. The processes described through orchestration mechanisms serve as a highly accurate form of documentation, especially when the orchestration mechanism allows annotations to describe services that may be missing and are needed to complete the automation of a process. 5.5.3. What forms of process orchestration will be used in ESA?SAP and many other vendors have been pursuing orchestration and a model-driven definition of business processes for many years. When XML arose as a standard and Enterprise Application Integration (EAI) systems were created, Business Process Management systems allowed orchestration based on reusable XML messages. Workflow modeling has existed for years in both ABAP and Java. What has changed in ESA is that now the building blocks for all levels of orchestration have a common elemententerprise servicesand many different contexts for applying orchestration have been well understood through trial and error. The different forms of process orchestration in ESA include all of the following:
5.5.4. What are the limits of process orchestration?Like any other modeling-oriented technique, process orchestration provides simplicity, but in doing so, it sacrifices some flexibility. While most process orchestration mechanisms provide some flow control mechanism, frequently this is simpler and less powerful than what is possible in ABAP or Java code. Certain orchestration problems will always be too thorny to be represented in one orchestration mechanism or another. The goal of orchestration mechanisms is not to handle every case possible, but to handle most cases in a simpler manner that does the job and lets more people participate, ending development bottlenecks. In most cases when orchestration mechanisms fail, it is possible to create a service that can do the job that is outside the scope of the orchestration mechanism. 5.5.5. How does process component modeling work?Process component modeling is the newest form of orchestration, and it plays such a fundamental role in closing the gap between business and IT that it deserves a longer explanation. The other process orchestration mechanisms are primarily intended to accelerate development, but process component modeling actually spans the space between the high-level abstract descriptions of businesses and processes that use business scenarios and solution maps, and the world of enterprise services, as shown in Figure 5-10. Three levels in process component modeling help bridge this gap:
Figure 5-10. The role of process component modelingFigure 5-11. ESA integration scenario modelingFigure 5-12 shows process component modeling and process component interaction modeling. Process component modeling is so important because it attacks at a fundamental level the lack of structure and abstraction that led to the monolithic enterprise applications of the past. Process component modeling provides a tool that allows much of the structure of business that was never formally defined, to be captured and to be made clear and explicit. This sort of transparency has many different benefits, such as making it easier to identify gaps in end-to-end processes, making existing patterns in processes visible, helping to establish standards for solving the same problems in the same way, allowing flexible design based on reusing existing parts, and supporting outside-in development of new functionality based on modeling. Perhaps the largest benefit of this sort of modeling is its role as a communications tool that makes existing functionality clear to all interested parties and provides a tool for managing the growing complexity of business by breaking it down into smaller, more easily understood pieces. Through process component modeling, the development process becomes much more connected and integrated, and specifications and requirements are communicated through the formal mechanisms of the model rather than through language, which can be less efficient. Figure 5-12. ESA process component modeling and process component interaction modeling |