Section 5.7. The persistence layer

5.7. The persistence layer

Some people who look at the ESA stack are puzzled by the presence of the persistence layer. From one point of view, persistence really should not be visible in the stack because it is handled by enterprise services or business objects. Persistence is not a general-purpose part of the stack, but rather a feature of the underlying technology that helps implement applications. While this perspective has merit, we have chosen to include persistence as a separate layer in order to highlight the differences in how persistence must be managed in ESA.

There are two major challenges related to managing persistence in ESA, and both are related to the fact that data is distributed across a set of service providers.

The first challenge is restoring the single, consistent, unified view of data that was one of the most attractive features of the first generation of enterprise applications. One of the reasons Enterprise Resources Planning (ERP) became so valuable to companies so quickly is that it created a central location for one version of the truth. For small- to medium-sized companies, that is still the case today, but at large companies, that situation did not last long. Soon after the first ERP was implemented, other instances were quickly created. Not long after that, CRM, SCM, and other applications showed up, leading to the current situation of multiple repositories with duplicate and sometimes inconsistent data.

Under ESA, distributed databases are accepted as a fact of life. SAP offers three tools for managing the distributed data and assembling a consistent view of it: SAP NetWeaver Master Data Management, SAP NetWeaver BI, and the forthcoming techniques for distributed transactions. SAP NetWeaver Master Data Management helps create a centralized view of master data as if it were in a single database. SAP NetWeaver Master Data Management also has tools that help identify and correct inconsistent and incorrect data. SAP NetWeaver BI is a full-service data warehouse that can assemble a consistent view of master data or transactional data and offer advanced analytical and reporting capabilities. How both of these tools are used in composite applications is discussed in Chapter 13.

The second challenge is consistently writing data to distributed repositories. In the previous generation of enterprise applications, the transaction mechanisms of the database became the foundation of maintaining a consistent collection of data. Higher-level mechanisms in the applications were built on top of the basic functions of opening a transaction, making series changes, and then committing them or rolling them back. In a world of distributed repositories, this approach will not work. Data consistency must be more actively managed at the application level. If something goes wrong with a series of changes, the application must reverse the changes through compensating transactions. Transaction mechanisms for distributed repositories using services are on the way but are not yet completed.

5.7.1. How will this discussion be continued?

This chapter covered many concepts that are central to understanding ESA, but there is plenty more to cover. If you are interested in more details about these concepts, please see Chapter 12, which explains how the ESA stack is used in composite applications and the development tools used to create them.