Chapter FIVE. The Structure of ESA

So far, this book has focused on framing the issue and explaining the context for ESA. The explanation has covered the business value and the general outline of how ESA creates value. This chapter dives deeper into the structure of ESA and covers the mechanisms that will be implemented at every level of enterprise software to make enterprise software simpler to adapt and change and to improve reuse across the board.

The challenge of understanding ESA is that, like mathematics, ESA defines a simple set of operators and primitive constructs that you can apply in many ways to a huge number of problems. Simple examples based on simple assumptions get the idea of ESA across. But the operators and building blocks of ESA are so flexible and powerful that almost any general statement has an exception.

For example, do composite applications consume services or can they also be service providers? Well, most of the time, composite applications are service consumers. They use enterprise services from service providers to do their work, and that's that. But there is no barrier that stops a composite application from being a service provider as well and offering services constructed inside of it to other composite applications. It might not happen often; it may be hard to do, but it can be done.

The concept of business objects offers a similar challenge. Business objects are collections of related functionality and data that bring together and encapsulate something that is important that will be reused. Like enterprise services, business objects can keep track of complex relationships, represent entities such as purchase orders or engines for calculating taxes, start or manage processes, or perform utility functions. In much of our discussion, we talk about business objects as living inside service providers. (It is important to note that when an older application is being used to power enterprise services, it may not have business objects clearly defined, and if they are clearly defined, they may not be created to easily allow enterprise services to be created.) When business objects exist in a service provider, enterprise services can be constructed easily, sometimes automatically, based on exposing the service operationsthat is, the function callsof the business objects as services. If business objects do not exist in service providers, enterprise services must be implemented using traditional methods of writing or generating code and using application programming interfaces (APIs).

But business objects show up in composite applications as well, where their job is to encapsulate important functionality. In composite applications, business objects may be frequently created through service composition, the technique of combining many enterprise services to perform a new job or stripping down a complicated enterprise service into just what is needed for the composite. Business objects play a similar role in composites and service providers, but in a different manner with a different emphasis.

The fact that ESA is evolving also complicates the issue. As pointed out in Chapter 1, ESA on SAP R/3 has certain capabilities that are expanded in mySAP releases and will evolve further in the future. What you can do with ESA depends on where you are in this evolution.

This chapter will take a close look at each level of the ESA stack and unmask the personality that lies beneath the technology. Understanding the personalities of the different levels of the ESA stack will enable you to quickly understand ESA and put it to work no matter what the context is.

The purpose of this chapter is to:

• Expand on the explanation of the context of ESA started in Chapter 1

• Explain each level of the ESA stack

• Explain how the levels of the ESA stack work together in composite applications

• Explain how each level of the ESA stack is created

• Explain key technology that supports the ESA stack

While this chapter is intended for technically oriented readers, business-oriented readers will also get a sense of the internal workings of ESA, even if some details seem obscure. The explanations are contained in the following sections:

• "Basics of ESA applications"

• "The ESA stack, layer by layer"

• "The enterprise services layer"

• "The business objects layer"

• "The process orchestration layer"

• "The UI layer"

• "The persistence layer"

One warning to the most technically sophisticated readers: if you expect to find each method of every service explained in this chapter, you will be disappointed. The goal of this chapter is to show the lasting structure of each level of the ESA stack as it has emerged over the last three years of architectural toil. In doing so, we hope to provide the context so that when you are faced with deeply technical literature, you can quickly make sense of it.