Now we are at the doorway of ESA. The simple view of composite applications and SOA leaves many questions unanswered about how the reusable parts will be constructed, who will build them, what tools will be used, and what will make them work together. Here are just a few questions that must be answered to derive the full business value from composite applications:
How should the portions of the stack be distributed across this architecture?
How should the portions of the stack talk to each other?
What is the right structure for each portion of the stack?
When should multiple structures for a portion of the stack be supported?
How should the UIs be constructed?
How should the process orchestration take place?
How should development methods change?
Where is the persistence?
How is distributed data managed?
How can complexity be managed?
How can the process of adapting applications be simplified?
How can developers be made more productive?
What is the right division of labor?
Who should solve all of these problems?
The rest of this book is dedicated to answering questions such as these in great detail. To get started, let's look at a few different areas more closely. For example, in a composite application, the data is distributed over many repositories. How can one version of the truth be assembled? How can changes that affect records in many repositories be synchronized?
There are all sorts of different forms of process logic. There is workflow, which happens within an application; there is process orchestration, which happens within a composite application; and there is the logic that is required when a process is handed from one enterprise application to another—let's call this process integration logic. How is all of that logic going to be dealt with? How are the different portions of the stack for process logic, integration logic, application logic, and so on, going to be distributed across the structure? Will all the logic be in the center? Will the enterprise applications have to become smarter? (For the rest of this book, we are going to use the term process orchestration to refer to all of these sorts of process logic.)
How should applications be developed? Are new development methods needed? How can things be simplified? Who is going to do the work of creating the services that are built on top of the enterprise applications? Is there any standard for those?
How will industry standards be incorporated and made useful? How will all interested parties in the architecture communicate and participate in the ongoing design process?
It is quite clear that there are plenty of questions to ask. One, however, is perhaps the most fundamental: who should answer the questions? Each IT department?
SAP, living up to its traditional dedication to solving the whole problem, is not satisfied to just leave these questions to IT departments to solve on their own. One of the most important aspects of ESA is the blueprint it provides for building composite applications based on the principles of SOA with all questions answered and details filled in. As part of its commitment to ESA, SAP is not only filling in the architectural details, but also creating the collection of reusable parts (the Enterprise Services Inventory), a repository for searching through the parts and using them to create programs (the Enterprise Services Repository), and an ecosystem that includes input from partners, customers, and standards bodies in a systematic way (the Enterprise Services Community, or ES-Community).
To simplify the explanation of ESA we have created a basic stack, as shown in Figure 1-10, that serves as a unified model for UIs, processes, and information, with a clear separation of duties for each layer.
Later sections of this book will examine each area of this stack in detail. But to prepare for further learning, here is a quick, top-to-bottom explanation of each layer of the stack that shows how it answers many of the questions previously raised.
UIs in ESA have much more structure than in previous generations of enterprise applications. Most of the time UIs are created through modeling, or by using patterns as building blocks, or both. For example, the UI patterns of work center and control center will be a standard part of ESA applications. Work centers are UI elements designed to take a user through the steps needed to complete a process. Control centers show the status and are the central point of access for all of the work centers that a user may be involved in. Common approaches to managing lists of tasks have also been created. The goal is to reuse configurable components and adjustable patterns to reduce the complexity of building and using UIs for enterprise applications.
Process orchestration is the notion that process logic will be separated from all other kinds of logic. Process orchestration will happen at many different levels. Composite applications will use process orchestration as the coordinator and integrator of a set of process steps available through enterprise services provided by enterprise applications. Service providers such as existing enterprise applications will use workflows for processes within their boundaries and will use layers of process integration logic to accept incoming or send outgoing processes to and from other systems. Individual services may use process orchestration to create composite services. The goal in ESA is to make process orchestration easier to build and modify so that applications can be changed quickly, cheaply, and by a wider group of people than is now possible.
There are two main flavors of process orchestration. Frontend process orchestration is conversational. It is focused on collaboration and interaction with users. A technology called guided procedures can walk a user through a set of steps that may involve many different enterprise applications. Guided procedures are designed to enable you to easily maintain a context for a process by allowing documents to be attached. They are also flexible and allow you to change the process flow for one instance of a process on the fly.
Backend orchestration is about long-running, primarily asynchronous processes. An example of backend process orchestration is the cross-component Business Process Management functionality in the SAP NetWeaver Exchange Infrastructure (SAP NetWeaver XI), which has a high-performance, robust business process engine for using enterprise services to automate complex, long-running processes that are triggered by events, send and receive alerts, and coordinate the activity of many transactions asynchronously.
Enterprise services come in many forms. Usually the term enterprise services refers to services that are being exposed by the enterprise applications or by other service providers to participate in the support of business processes. Reusable utility functionality offered by SAP NetWeaver can also be presented as enterprise services. So can services that specialize in managing a process or engine for special-purpose calculations of taxes.
Although enterprise services are based on web services standards, they are different from plain web services in that enterprise services are created to participate in reusable processes, not necessarily in just the functionality that has been exposed at any level of granularity. Enterprise services live in the Enterprise Services Repository that stores data that describes the services' interfaces, how the services would be used in model-driven development tools, and how the services fit into models that describe business processes.
SAP has both external and internal processes for controlling the growth and design of the Enterprise Services Inventory, the name for the sum total of all enterprise services.
Business objects are the collections of related data and functionality inside a service provider. Business objects also can be units of modeling, a description from a modeling perspective of related functionality. In the purest form of ESA, enterprise services are extensions of business objects. In other words, enterprise services expose the functionality of business objects to the outside world. Business objects also show up inside composite applications, where they consume services and can be the building blocks for services provided to other programs. One of the major challenges of ESA is that enterprise services must be constructed on enterprise applications and other service providers that were not originally designed for ESA. These applications don't have the equivalent of business objects inside them that make it easy to build services. The challenge of building enterprise services on enterprise applications based on the mainframe/client/server stack is that the functionality in the application is not separated into reusable chunks. In attempting to create a reusable enterprise service, one must take care not to have any unwanted side effects.
In ESA, the core assumption of the single database that was so central to the mainframe/client/server architecture is no longer valid. The ESA stack assumes not only a distributed repository, but also certain levels of redundancy. Part of this is handled through aggregation and distribution mechanisms such as SAP NetWeaver Master Data Management (SAP NetWeaver MDM) and SAP NetWeaver Business Intelligence (SAP NetWeaver BI) that create a logically normalized information model on a physically distributed collection of repositories. But the whole solution requires more. Composite applications must have their own robust persistence mechanisms when they store new information that extends systems of record. Distributed database transaction mechanisms that allow many repositories to be updated in a consistent manner are also defined by ESA.
Get Enterprise SOA now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
