Cohesion, Coupling and SOA

I was prompted to review one of my university texts on program design when I was reading some material on how to develop good software under SOA. The text in question is "Software Engineering: A Practitioners Approach" by Roger Pressman. It gives and excellent account of cohesion and coupling apparently developed earlier by Larry Constantine. I note this is currently presented in Wikipedia (http://en.wikipedia.org/wiki/Cohesion_(computer_science) and http://en.wikipedia.org/wiki/Coupling_(computer_science) ).

Pressman presents a range of cohesion and coupling types and explains this as two linear scales (low coupling good, low cohesion bad). These do not seem to be used in any detail in the SOA literature that I have read which is a shame because knowledge of this concepts is relevant. There is a lot of discussion about loose coupling without much reference to its definition. In Pressman's terminology loose coupling between modules (or services) includes, 'No direct coupling' and 'Data Coupling'. When you get to 'Stamp Coupling' and 'Control Coupling' you are getting into the area of bad coupling which a developer may compromise on if there are good reasons (eg. Performance). 'External', 'Common' and 'Content Coupling' gets into the forbidden zone.

SOA adds 'Message Coupling' to the above list. 'Data Coupling' assumes a procedure call where the location of the recipient is known and the parameters conform to known format. Messages on the other hand do not require this detailed knowledge of the called procedure and therefore are usually lower on the coupling spectrum than 'Data Coupling'. 'Loose Coupling' is a term used often in SOA but it means more than just using messages to communicate between services. The other forms of coupling still can exist. You can pass control information by messages and still have control coupling. You can allow access to common persistent data and still have external coupling. Message orientation does not automatically mean you have loose coupling.

Cohesion is a term that is not seen as often in relation to SOA. Pressman lists different types of reasons that you might bring bits of code into the same module. Some of these are just as valid when you are building a service. The ideal cohesion is where a module implements a single idea 'Functional Cohesion'. The next best cohesion is 'Sequential Cohesion' where steps are included together because they have to follow each other sequentially. Both these forms of cohesion are usually too fine-grained to be implemented as services. Modules that exhibited this level of cohesion would however be good operations within a service.

'Communicational Cohesion' is the developing of modules around a data structure and this equates closely to 'Entity-Centric' services for an SOA. 'Procedural Cohesion' relates code that is included in a module because it belongs to the business process. This is similar to the 'Task-Centric' services for an SOA which are appropriate for business services but usually exhibit less cohesion than entity-centric services in application services. In the more scatter-brained rationales for cohesion we have 'Temporal Cohesion' for code which must be executed in the same span of time, 'Logical Cohesion' for operations that are logically similar and 'Coincidentally Cohesive' where the code is related loosely. These are scatter-brained approaches both in classical development and SOA.

Thomas Erl says that ideally
· Services are reusable
· Services share a formal contract.
· Services are loosely coupled
· Services abstract underlying logic.
· Services are composable
· Services are autonomous
· Services are stateless
· Services are discoverable
On the surface one might consider that the only relationship with this list to the concepts coupling and cohesion is the reference to loose coupling. In fact all the qualities except discoverability can be enhanced with an understanding of coupling and cohesion. Good cohesion and coupling allows services to be more reusable. A formal contract makes the relationship between services explicit and therefore less tightly coupled. If the underlying logic of a service has to be understood to understand the service then this probably means the interaction of the service is not going entirely through well understood messages. Autonomy is another way of expressing cohesion as service has control over its code and is not effected by outside influences. State in a service is a form of control coupling. A stateless service means that control is not being handled outside the service.
The important point here is that we can use some already tried and tested techniques to apply to quality service development. The design literature of SOA would do well to draw more on this legacy rather than use some statements about loose coupling that are left without clear definition. Another point of this discussion is to emphasize that old IT concepts are still valid, which gives aging software developers a warm feeling. We are still trying maximize cohesion and minimize coupling in our services just as we did in our Fortran subroutines.


References

Constantine, Larry and Yourdon, Edward, Structured Design, 1976

Pressman, Roger, Software Engineering: A Practitioners Approach, 1982 McGraw Hill

Erl, Thomas, Service-Oriented Architecture: Concepts, Technology, and Design, 2005 Prentice Hall