The ESA Stack
[Ed. note: SAP NetWeaver is exposing business and IT managers to new concepts — Web services, composite applications, and service-oriented architecture (SOA), to name a few. While we believe that most of you have a general understanding of what these key terms mean, a deeper, more practical definition might be useful. In this and future issues, “The Last Word” in SAP NetWeaver Magazine will provide that more complete explanation. To begin, let’s look at enterprise services architecture (ESA).]
One way to understand ESA is to examine the division of labor as it is represented in the layers of the ESA stack. Each layer has a clearly defined role and together they create a new approach to building enterprise solutions:
User interface: UIs in ESA have more structure than those in previous enterprise applications and are created through modeling, by using patterns as building blocks, or both. In SAP, ESA UIs are based on patterns of work center and control center. For example, work centers take a user through the steps needed to complete a process. Control centers show status and are the central point of access for work centers. ESA also has common approaches to managing lists of tasks. The goal is to reuse configurable components and adjustable patterns to reduce complexity.
Process orchestration: Composite applications, which are based on services provided by other applications, coordinate and integrate enterprise-services process steps using process orchestration. Service providers use workflow for processes within their boundaries, and layers of process-integration logic for other systems’ processes. The goal is to make process orchestration easier to build and modify so a wider group of people can change applications quickly and cheaply. Front-end process orchestration is conversational, focused on user collaboration and interaction. Back-end orchestration is about long-running, primarily asynchronous processes.
Enterprise services: Enterprise applications or other service providers expose some services to support business processes. For example, SAP NetWeaver’s reusable utility functionality is an enterprise service, as are services that manage a process or entities for special-purpose tax calculations. Although enterprise services are based on Web service standards, they are created to support business process automation, not just fine-grained, technical functionality. Enterprise services live in SAP NetWeaver’s Enterprise Services Repository (ESR), which stores data describing the interfaces that allow the services to be used in model-driven development tools. Process component models show how services fit into end-to-end business scenarios. The Enterprise Services Inventory is the sum total of all enterprise services.
Business objects: These are the collections of related data and functionality in a service provider. Business objects are units of related functionality. In pure ESA, enterprise services are extensions of business objects that expose their functionality. Composite applications also contain business objects that both consume services and create the building blocks for services provided to other programs.
Distributed persistence: The “single database” assumption that was central to mainframe-client/server architecture is no longer valid. The ESA stack assumes not only a distributed repository, but also certain levels of redundancy. The aggregation and distribution mechanisms handle part of this persistence, but the whole solution requires more. Composite applications must have robust persistence mechanisms when they store information extending systems of record.
This article was adapted from the book, Enterprise SOA: Designing IT for Business Innovation, by Dan Woods and Thomas Mattern (O’Reilly Media, Inc., April 1, 2006).