Gestern fiel mir beim Überfliegen einiger Forenbeiträge plötzlich das Kürzel SOA ins Auge. Man mag denken das ist ja nichts ungewöhnliches wenn man gerade eine Diplomarbeit über serviceorientierte Architekturen schreibt. Was mich etwas irriert hat war, dass ich in einem Thailand-Forum und nicht in einem IT-Forum war. Das manche scheinbar SOA auch als Abkürzung für Südostasien verwenden war mir bis dahin nicht bewusst. Da will man sich also nach einer langen Diplomarbeitsphase endlich mal wieder etwas Auszeit von SOA gönnen und stellt fest, dass man versehentlich nochmal zwei Monate Intensivkurs gebucht hat um SOA hautnah zu erleben. Naja, ich habe meine Entscheidung bisher trotzdem nicht bereut, aber irgendwie hat mich diese Entdeckung nochmal darin bestärkt, dass ich die Reiseberichte wohl größtenteils auf Englisch schreiben werde.

Tags: Backpacking, SOA, Southeast Asia, Thailand
Categories: Getting around
No Comments »

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.

Tags: Book review, Diploma Thesis, ESOA, SOA
Categories: SOA
No Comments »