04/20/08 :: [SOA] Loose Coupling and Cohesion  [permalink]


Quite hilarious (and symptomatic), I advise Jim to catch up with modern SOA concepts, technologies and principles and he advises me to read antiquated software engineering books, or articles from Steve Vinoski.

Jim, if all you wanted to tell us is that autonomy requires some degree of cohesion, well you did not need a blog post for that. I was trying to interpret your blog post in the context of an assembly of services performing a unit of work and wondering how cohesive could an assembly of services be?

Again, if you take a modern view of SOA (say post 2005) you really wonder how an assembly (a module for me) can exhibit some degree of cohesion. Even a service within an assembly (a component in SCA terms) is likely to fail "cohesion" litmus tests.

Let's review Steve Vinoski's article.

Functional cohesion occurs when a module does only one thing: take a look at Resource Lifecycle Services, what does "one thing" means. Is your recommendation really that services do only one thing at a time?

Communication Cohesion is when a module carries out multiple operations based on the same input or output data: ok. why not, some services might be designed that way but this is not the case for the vast majority of them. I would argue that this is not even very important in SOA: XML helps you not having the need to establish Communication Cohesion.

Sequential Cohesion is when a module carries out several tasks and the input of one tasks feed to the other. What's the big deal about that one? This is true in a pre-XML civilization. With XML you don't care as much to achieve this level of cohesion.

Logical Cohesion is a condition in which a module's activities are grouped together because they appear to be able to share common implementations: that's a bit closer to SOA but again, have you ever considered that when a Service Interface is implemented by a BPEL definition, all the operations are tied together in the same implementation? unlike OO you don't have necessarily a one-to-one relationship between operation and implementation.

Jim in case you have not noticed, SOA is unfamiliar, it is time to rewrite the books. Concepts like XML extensibility, semantic access (XPath), or forward compatibility precisely alleviate the need to be cohesive. Whatever the principles you learned in school, they most likely don't apply any longer in an Inter-Action Oriented, Asynchronous Peer-to-Peer programming model.

So for me cohesion is not a design principle you can apply at the assembly level and even at the operation level. XML is the technology that allowed us to break from cohesive software engineering (CSE). CSE has been developed for bronze age programming languages. We are in 2008 today, things have evolved a tiny bit. 

I stand by what I have said, a cohesion requirement creates absolutely unnecessary constraints on the design of service interfaces and implementations that actually reduce the degree of reuse of a given service and its capacity to participate in different assemblies. Maybe it is time to become familiar with modern loose coupling concepts that include: bi-directional interfaces, assemblies, orchestration languages, extensible and semantically accessible data structures. Ancient programming techniques have been designed precisely because you did not have these concepts within your programming model.

Every thing you say in your post, from applying cohesion principles to SOA, "a process is a service" or "look at MVC if you don't get it", to "Business people should become IT architects" does not make any sense and are likely to fail anyone trying to build a Service Oriented Architecture.