There’s this ongoing argument in the blogosphere on the issue of the “importance of Cohesion in SOA“. Cohesion and Coupling are two features that should be present in good software. The paradox is that they’re opposite forces and a balance between them has to be made. The ongoing argument is that SOA tends to lean towards loose coupling and therefore cohesion must take a back seat. What both surprises me and keeps me equally disgusted is the fact that SOA practitioners can’t even get a handle on this basic concept.
Steve Vinoski wrote a survey paper in 2005 about Cohesion and Coupling. The paper revisits the concepts of coupling and cohesion that were introduced with structured programming. In other words, pre-object orientation. He concludes in his paper:
Given that transitions to xe2x80x9cnewxe2x80x9d
computing styles are often accompanied
by explicit disapproval of the outgoing
style, itxe2x80x99s no surprise that todayxe2x80x99s
focus on SOA has created a bit of a
backlash against distributed objects.
Whatxe2x80x99s unfortunate is that many of the
measures of quality for distributed
object systems apply equally well to
distributed services and SOA, so itxe2x80x99s a
shame that some feel compelled to
ignore them just to be trendy. But perhaps
it doesnxe2x80x99t matter, because we can
just go back to the days before objects,
dig up measures like coupling and
cohesion, and apply them all over
again xe2x80x94 for the first time, of course.
Reality Check: The world has made a world of progress since the days of Structured Programming and has settled towards Object Orientation. It is therefore imperative that we consult Object Oriented texts to gleam an understanding of what makes for good software. One of the most authoritative books of that time was Bertrand Meyer’s “Object-Oriented Software Construction, 2nd edition“. The book was published back in 2000, weighing in at 4 lbs and 1,296 pages. In this book, Meyer presents five fundamental requirements that a design method worthy of being called “modular” must satisfy:
- Modular Decomposability – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex subproblems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.
- Modular Composability – A method satisfies Modular Composability if it favors the products of software elements which may then be freely combined with each other o produce new systems, possibly in an environment quite different from the one in which they were initially developed.
- Modular Understandability – A method favors Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.
- Modular Continuity – A method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.
- Modular Protection – A method satisfied Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.
Certainly a palatable and succinct list of requirements to guide the makings of good modular software. I certainly like lists like this where each point not only self contained but orthogonal to the other points. Coupling and Cohesion are not the primary goals, rather the goal is to achieve modularity and Coupling and Cohesion are just artifacts of Modularity. Cohension in particular simply boils down to our ability to understand the inner workings of a module. In the context of SOA which concerns itself with inter-module interconnectivity, Cohesion’s intra-module concerns plays very little importance.
However, what’s extremely disturbing is that SOA practitioners seem to be rediscovering tried and true principles of software design. Contrast Bertrand Meyer’s Requirements for Modularity (the 1st edition was circa 1997) with Thomas Erl’s recently published SOA principles (circa 2007):
- Loose Coupling – Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment.
- Abstraction – Service contracts only contain essential information and information about services is limited to what is published in service contracts.
- Reusability – Services contain and express agnostic logic and can be positioned as reusable enterprise resources.
- Autonomy – Services exercise a high level of control over their underlying runtime execution environment.
- Statelessness – Services minimize resource consumption by deferring the management of state information when necessary.
- Discoverability – Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted..
- Composability – Services are effective composition participants, regardless of the size and complexity of the composition.
IMHO, this ia a terrible set of principles because they are overlapping concerns. For instance, how is Composability different from Reusability? To illustrate this overlapping, just perform a rough mapping of these principles to the Meyer’s Moudularity. We thus get
Loose Coupling maps to Decomposability, Protection and Continuity. Abstraction maps to Understandability. Reusability maps to Decomposability, Undestandability and Composability. Autonomy maps to Protection. Finally, Composability maps, to well, Composability. What’s depressing is that in 10 years of innovation (i.e. 1997 to 2007), SOA practitioners have added only Statelessness and Discoverability in to the mix?
To be completely fair, there are other SOA practitioners that do lend some more depth (or meat?) into the SOA discourse. One would expect book authors like Webber and Erl would have a more indepth grasp of the subject, unfortunately that’s not the case.
Don Box may have written the first set1 of Four SOA Design Tenets in 2004:
Tenet 1: Boundaries are Explicit
Tenet 2: Services Are Autonomous
Tenet 3: Services share schema and contract, not class
Tenet 4: Service compatibility is based upon policy
This was extended by Stefan Tilkov in his Ten Principles of SOA :
- Explicit Boundaries*
- Shared Contract and Schema not Class*
- Policy Driven*
- Wire Formats not APIs
- Document Oriented
- Loosely Coupled
- Standards Compliant
- Vendor Independent
With any new computing style, I’m always on the look out as to what differentiates it from a pre-existing style. Tilkov’s principles in my opinion has more meat than Erl’s principles. However, I quest whether Loosely Coupled is a SOA principle or the entire essence of SOA. See, Wire Formats, Document Orientedness and Metadata driven are all a consequence of Loose Coupling. The same can be said of Don Box’s original tenets. Not to be out done, David Orchard has his own SOA principles that goes like this:
- Trade-off Principle: SOA deployment is a trade-off between properties of interest.
- Defined message format Principle: Services have well defined message formats.
- Interface Principle: Services have described interfaces.
- Interface Fidelity Principle: The richness of the interface description relates directly to the amount of coupling.
- Composite Behavior Principle: The actual behavior is the sum of all the behaviors in the software.
- Distributed Principle: Services should be designed for existence in a widely distributed and heterogeneous computing environment.
- Decentralization Principle: Services should be designed and planned for decentralized administration
- WS-* Technique: Services should make appropriate use of Web services specifications such as SOAP
- State Technique: State location and management
- Coarse Grained Technique: Coarse grained interfaces
- Asynchronous Technique: use Asynchrony.
David Orchard’s list shows better balance, of course I do have to question the WS-* inclusion. Now if I could therefore come up with an aggregation of SOA principles that is formulated by extending Meyer’s Modularity principles and adding my definition of Services, it would then look like this:
- Decomposability – A method satisfies Decomposability if it helps in the task of decomposing a software problem into a small number of less complex subproblems, connected by a simple structure, and independent enough to allow further work to proceed independently on each item.
- Composability – A method satisfies Composability if it favors the products of software elements which may then be freely combined with each other and produce new systems, possibly in an environment quite different from the one in which they were initially developed.
- Understandability – A method favors Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.
- Continuity – A method satisfies Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.
- Protection – A method satisfies Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.
- Introspection – A method satisfies Introspection if it yields architectures that support a mechanism that enables the structure of modules and the structure of their communication to be queried and examined at runtime.
- Remoteability – A method satisfies Remoteability if it yields architectures that support a mechanism that enables module communication by other modules that are hosted in separate physical environments.
- Asynchronicity – A method satisfies Asynchronicity if it yields architectures that does not assume an immediate response from a module invocation. In other words, it assumes that latency exists in either the network or the invoked module.
- Document Orientedness – A method satisfies Document Orientedness if it yields architectures where the messages of inter module to module communication are explicitly defined, shared and that there is no implicit state sharing between invocations.
- Standardized Protocol Envelope2 – A method satisfies a Standard Protocol Envelope if it yields an architecture that requires the sharing of a common Envelope message format across all module communications.
- Decentralized Administration – A method satisfies Decentralized Administration if it yields an architecture that does not require a single administrator for all modules.
The ideas of yesteryear continue to be relevant today. What we must do it clearly identify what is truly new rather than regurgitating old practices disguised as new ideas. This new set of SOA principle builds from what exists and extends it to the distributed and decentralized environments. That is, the derivation begins with Meyer’s modularity principles. To that I’ve required support for component model in the Introspection requirement (note: Discoverability follows from this). Then I’ve required distributed computing while applying Deutsch’s fallacies (see: Remoteability, Document Orientedness, Asyncrhonicity and Decentralized Administration).
Now it is important to realize that there’s a vast gulf between a set of principles and how to effectively using it in practice (see: “SOA Salavation“). The primary goal of SOA is to provide more agile IT infrastructure. Even with the above SOA principles laid out, I have difficulty seeing how this helps achieve greater agility. There is a big social engineering aspect that seems to be required to achieve SOA success. Just as Web 1.0 evolved into Web 2.0 via virtue of systems that encourage participation, SOA will need to evolve to SOA 2.0. That is, a SOA architecture that does encourage participation.
Now regarding that all encompassing term of “Loose Coupling“, one could essentially derive many of the above properties from it! To summarize, SOA is all and nothing but Loosely Coupled APIs.
1. My own definition of services was published in 2003.
2. Note that the “Standardized Protocol Envelope” is in contradiction with Peter Deutsch’s “8 Fallacies of Distributed Computing”.