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 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access