McGovern, J.; Sims, O.; Jain, A.; Little, M.: Enterprise Service Oriented Architectures : Concepts, Challenges, Recommendations. First Edition, Dordrecht: Springer, 2006

According to McGovern et al. three major concepts are the basis of enterprise service-oriented architecture (ESOA):

1. Services using XML-based standards both for specification of the service interfaces and for communication with the services (that’s what they say many refer to as just service-oriented architecture).
2. Service implementation using component-based software engineering (CBSE) architecture for structuring new applications as well as for legacy wrapping, workflow and business-to-business specifications.
3. A service-oriented architectural, procedural and organizational mindset, which can merge web service technology and the CBSE approach into a hughely productive whole.

The use of CBSE for service implementation is intensively discussed especially in chapter 3. Following the authers there has been a shift in the evolution of mature CBSE “from reuse of components as pluggable modules of software technology to business-oriented reuse and business collaboration of business services - the components themselves being the service implementations.” They differentiate levels of utility components, entity components and process components. Entity components are business entities such as invoice or customer, They make use of general low-level utility components and are used by process components. The authors refer to that as “federation”, which basically means the same as that higher-level components choreograph those at lower level.

They identify three reasons why, although many commercial off-the-shelf (COTS) products exist, implementing an ESOA is difficult:

1. COTS products are point solutions, not ESOA solutions, that is there exists no single integrated product.
2. They are general-purpose suitable for many architectural styles, so they are not so high-level as a platform focusing on one architectural style could be.
3. IT development is (typically) project-based, that means there is little funding outside of the project and there is limited reuse of common artifacts across projects.

As the lack of an end-to-end cohesive product is seen as the major inhibitor limiting productivity they ask for an “enterprise productivity platform” (EPP).

In chapter 3 a procedure for designing service components following CBSE principles is proposed.

They start with a definition of business elements derived from resource and process models. There exist Resource Business Elements (RBE), Service Business Elements (SBE) and Delivery Business Elements (DBE). RBEs consist of a set of resources grouped around focus resources which are real and independent. SBEs are a “collection of immediate steps” grouped by RBEs - they will normally map to organizational units. DBEs are a “group of Service and Resource Business Elements that together deliver a business solution to a business problem, and which provides services to requestors”. They can represent a major responsibilty of a department or a larger organizational unit. So whereas RBEs are useless themselves because there is no process, SBEs need RBEs to have resources. The DBE “is the set of assets that delivers value”.

A Service Business Element is later mapped to a Process Business Component, a Resource Business Element to a Entity Business Component and a Delivery Business Element to an Applicaion Component. Using Model Driven Architecture (MDA) terminology this would mean the business elements are part of the computation-independent model (CIM). They are mapped to components which are later refined and describe the platform-independent model (PIM).

The books consists of further chapters, which I won’t introduce in detail, namely “Orchestration”, “Working with registry and UDDI”, “Understanding Enterprise Security”, “SOA Management”, “Transactions” and “Event-Driven Architecture”. It references other books, documents and magazines in case ideas have already discussed somewhere else (which is not self-evident considering many other SOA books), so it can be said to have a rather academic writing style. Graphics, screenshots and code snippets are used to visualize the statements.

Categories: SOA