BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Dependency Principles for SOA

Dependency Principles for SOA

Leia em Português

This item in japanese

Lire ce contenu en français

Last year Ganesh Prasad discussed his thoughts on SOA at QCon. Earlier this year he expanded on some of this in an article about how in his view thinking of SOA as Dependency Oriented Thinking:

SOA is the science of analysing and managing dependencies between systems, and "managing dependencies" means eliminating needless dependencies and formalising legitimate dependencies into readily-understood contracts.

And he has a diagram that helps illustrate this:

As Ganesh states:

At the Business layer, the focus on dependencies forces us to rationalise processes and make them leaner. Business processes need to be traceable back to the organisation's vision (its idea of Utopia), its mission (its strategy to bring about that Utopia) and the broad functions it needs to have in place to execute those strategies (Product Management, Engineering, Marketing, Sales, etc.) [...] At the Application layer, we try to group operations. Note that the Business Layer has already defined the run-time grouping of operations into Processes. At the application layer, we need to group them more statically. Which operations belong together and which do not? That's the dependency question that needs to be asked at this layer. The answer though, is to be found only in the Information layer below, because operations only "belong" together if they share a data model. As it turns out, there are two groups of data models, those on the "outside" and those on the "inside". The data models on the "inside" of any system are also known as "domain data models", and these are never visible to other systems. In contrast, a data model on the "outside" of a system, known as an "interface data model", is always exposed and shared with other systems.

Now recently Ganesh has had a chance to put these ideas into practice and look at real-work use cases in light of this approach. With each scenario that had a failure, Ganesh suggests that the culprit can be traced back to one or more of the dependency principles being violated. As a result, Ganesh believes that an organisation which follows the rules will end up "achieving SOA". Of course we have many other examples over the years of where SOA has failed or succeeded, with corresponding attempts at principles and rules to follow to make SOA successful. The principles that Ganesh outlines can be classified into the four layers on which they operate:

Business Layer: (1) Traceability – Enforce core governance, "ensure that everything that is done makes sense with respect to the organisation's Vision". (2) Minimalism – Challenge assumptions. (3) Domain Insight – Understand the true nature of the business, "re-imagine the business from first principles".

Application Layer: (4) Cohesion and Coupling – "What belongs together should go together, with minimal links between distinct systems". (5) Implementation versus Exposure – "Group operations that share a Domain Data Model and business logic into Products, those that share an Interface Data Model into Services". (6) Variants and Versions – "Identify multiple concurrent flavours of each logical operation, establish a means to support ongoing changes to their logic and interfaces".

Information (Data) Layer: (7) Inside versus Outside – "Distinguish the Interface Data Model from the Domain Data Model". (8) Content versus Context – "Separate the core data elements of the Interface Data Model from its qualifying elements". (9) Abstract versus Concrete – "Create a data type hierarchy for both Content and Context elements".

Technology Layer: (10) Bundling Dependencies – "Avoid introducing fresh dependencies between unrelated components in the process of implementing business logic". (11) Late Binding – "Delay unavoidable dependencies till the last responsible juncture". (12) The Right Tool for the Job – "Implement logic using the most appropriate mechanism".

What do you think of these principles and the concept of Dependency-Oriented Thinking for SOA? Could these have helped a SOA project that you worked on? Would you consider using them today, or would you modify them based upon your own experiences?

Rate this Article

Adoption
Style

BT