Is Cohesion Important for SOA?

Posted by Mark Little on Apr 25, 2008

Sections

Architecture & Design,

Enterprise Architecture

Topics

Loose Coupling ,

SOA

Tags

Patterns and Practices ,

Service Design ,

Web services

Back in 2005 while still working for IONA, Steve Vinoski published a paper that talked about Cohesion and Coupling for services. In it he mentions 3 "good" types of cohesion that have been identified over the years:

• Functional Cohesion: when a module does only one thing. They display low coupling and are highly reusable.
• Sequential Cohesion: when a module carries out several tasks that must be ordered.
• Communication Cohesion: when a module carries out multiple operations based on the same input, but which do not have any prescribed ordering requirements.

Then there are 4 forms of "bad" cohesion:

• Procedural Cohesion: similar to Sequential Cohesion, except the data that each of the tasks works on is different. As Steve says: "Such cohesion often results from artificially grouping activities [to reduce coupling]."
• Temporal Cohesion: when a module's tasks are related only by time. "Such modules cause maintenance problems if one task needs to be performed at a different time.|"
• Logical Cohesion: where a module's activities are grouped because they appear to share common implementations.
• Coincidental Cohesion: a module's tasks are related only by the fact they reside in the same module.

As Steve goes on to say:

Just as with coupling, cohesion still matters when applied to distributed objects and services. For example, if  you grouped a bunch of methods in an object only because they had similar implementations, you would be guilty of creating a logically cohesive object.

The paper concludes with:

Given that transitions to “new” computing styles are often accompanied by explicit disapproval of the outgoing style, it’s no surprise that today’s focus on SOA has created a bit of a backlash against distributed objects. What’s unfortunate is that many of the measures of quality for distributed object systems apply equally well to distributed services and SOA, so it’s a shame that some feel compelled to ignore them just to be trendy. But perhaps it doesn’t 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 — for the first time, of course.

Now this may have gone relatively unnoticed for the past few years, until Jim Webber's recent posting on Anemic Service Model. Skipping over the historical discussions about good software engineering practices, Jim says some very similar things to Steve's earlier work:

Some software is highly cohesive in design, but tightly coupled. This means though it may be logically laid out, it's tough to change because of tight interdependencies. That's pretty bad, and unfortunately also common for enterprise applications. Remember that software which really wowed you a few years ago but is much more of a pain to maintain than you'd like? That's because it's tightly coupled.

 

The other kind of bad software is loosely coupled but lacks cohesion. That means that there are few explicit interdependencies between modules, but none of the modules are necessarily authoritative about any particular aspect of the system. This in turn results in a scattergun approach to ongoing system evolution as even minor changes ripple through multiple components or systems. Or SOA as we have come to know it nowadays.

The entry then goes on to discuss how current SOA thinking really goes against this grain:

On the one hand we're inclined, and indeed encouraged by the SOA brigade, to think of this architecture as a good fit for purpose because it is very loosely coupled. Since every component or service is decoupled from every other component or service it should be possible to arrange and re-arrange them in a Lego-style in a myriad of useful ways. Building out "business services" from some more fundamental set of services is how the books tell us to do it. In fact we could even do that quite easily with point-and-client BPM tools, ruling out such overheads as developers and change management along the way. Right?

 

No. In fact absolutely wrong. [...] this is an architectural fantasy that has no place in real world enterprise systems. In fact a service that does not address a business problem has no right being in an SOA.

Now there are quite a few interesting comments on that posting. However, the real debate that this kicked off has been happening elsewhere, particularly with JJ's response:

Well someone who is trying single-handedly to topple SOA with a "Something Else Oriented Architecture" is Jim Webber -the MEST guy. [...] I found his post being completely erroneous. I may be missing something, but Jim is looking at the relationship between Cohesion and Loose Coupling. [...] For me cohesion sounds like a good engineering principle that looks a lot like "Dependency Structure Matrix". [...] The goal of loose coupling is precisely to mitigate cohesion as a good engineering principle. You can't be cohesive in a connected system. You can't be both cohesive and loosely coupled. Even in English, associating the two sounds really bad.

The goal of loose coupling is to make to pieces of code work together even though they may have been written at a different time, using different technologies, with a different security model, ...

SOA is about going away from cohesive systems to enable a wider range of reuse scenarios. Nested cohesive systems do provide a "nested" (library-style) reuse model: the upper layers can reuse the lower layers. Unfortunately, it forces us to create systems in a way that is incompatible with the way information systems should be architected. Cohesion is the problem, loose coupling is the solution. Jim, do you really think that people are trying to "keep stuff together in the same module"?

JJ posits that although cohesion is a well understood software engineering principle, it is not relevant to "modern" SOA:

I find it increasing irritating to see some people constantly aiming at "SOA" with ideas they cooked 5 years ago, when the only thing they are really aiming at is their own misunderstanding of SOA. [Jim is] showing pictures that are antiquated and certainly does not represent SOA in 2008.

And goes on to discuss Steve's original article as well:

... 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.

The debate goes on though. Is cohesion fundamentally opposite to SOA? For instance, do we need to rewrite software engineering books to cover cohesion as it relates to SOA? Surely cohesion itself is not bad, but perhaps there are degrees of cohesion as there are of coupling, and one size does not fit all?

1. Back to top

   Cohesion and Autonomy

   by Stefan Tilkov

   In my view, services have much in common with small applications. They should do one "thing" and do it well. They should induce the least reasonable coupling for their consumers. This is true for both the WS-* style as well as the REST-style variant of services.
   
   This autonomy, IMO, implies cohesion. Coupling and cohesion go together – tie together what belongs together, separate what doesn't.

   Reply

2. Back to top

   Re: Cohesion and Autonomy

   by Mark Little

   One of the things I'm missing from the discussion is how you can have good (and meaningful) service reuse without an associated degree of cohesion.

   Reply

3. Back to top

   Re: Cohesion and Autonomy

   by Udi Dahan

   I've put up my summary and thoughts online as well:
   
   Visual Cobol, Enterprise Processes, and SOA .

   Reply

4. Back to top

   Re: Cohesion and Autonomy

   by Jean-Jacques Dubray

   Mark:

   
   
   

   I think we should define which cohesion we are talking about. I ruled out the kinds of cohesion that is related to autonomy because this is a given. The question, that is more important is when constructing information systems, can we define some degree of cohesion at the composition level? There are two main forms of compositions: an assembly of services performing a unit of work and a composite service, which orchestrate services to perform a new kind of service.
   

   
   

   
   I argue in this latest post that cohesion is an undesirable design principle above the service interface at the assembly level or composite service level. Even for mashups, you will compose extremely different services to achieve higher value. When you compose a map service with a rentals service, who could argue you have any cohesion between the two?
   

   
   

   
   If you go further and look at business processes, again, there is very few cohesion principles that seem to emerge.
   

   
   

   
   If you look at enterprise information models where pretty much every element is somehow related to others (within a few hops), you would be hard pressed again to apply cohesion principles (the good ones or the bad ones) across the relational maze.
   

   
   

   
   I like a lot the cohesion principles that Udi is introducing, at the service container level (services that scale similarly, or that can be invoked natively), at the domain level for defining policies... But these principles go against most of the "good" cohesion principles. Amazon had to break up their "cohesive" (i.e. siloed) architecture, because Service Container cohesion was a lot more important to them than functional cohesion.
   

   
   

   
   I don't see a real functional cohesion emerging in SOA anywhere, and we could easily see that this other "good" cohesion principle: "Communicational cohesion is when a module carries out multiple operations based on the same input or output data."
   

   
   

   
   is totally impractical (an unnecessary in SOA). Sure when you can, do it, but consumers are going to evolve over time. Should we keep the interface static because in a "connected system" not everyone can evolve at the same time?
   

   
   

   
   In SOA this principle probably translates in "shared information element". As long as we share "an address" the map service and the rental service can work together. I could also combine my purchase order service and my map service, why not even correlating "rental addresses" with PO addresses, for certain time of products...
   

   
   

   
   But this type of cohesion does not really tell me how they should be implemented, it does not even tell me how their interface MUST be designed. With modern loose coupling techniques and semantic access (~XPath, OWL, ~CCTS), I can always compose my services into an assembly or composite service.
   

   Reply

5. Back to top

   SOA rediscovering Modularity principles?

   by Carlos Perez

   www.manageability.org/blog/stuff/soa-rediscover...

   Reply

• Older >