The notions of cohesion and coupling have been kicked around the software world for decades, and have now gotten a new lease of life under SOA. However, there is a perverse notion of cohesion that has gained some currency in the SOA world, which regards cohesion as somehow equivalent to loose coupling. I originally thought it was the result of the prolific writings of one man who happens to be the CTO of a web service company. Last year, the publishers sent me a review copy of his latest book, so I wrote back and notified them of this error. I also posted a note on my blog on Cohesion and Coupling. But I see he has been replicating the error in several recent Internet articles, so he obviously didn't get the message, or perhaps he just didn't get it. Other bloggers have noticed the same error, including Jef "thinking out loud" Newsom (Feb 2005).
However I've now found something by Phil "Loosely Coupled" Wainewright (March 2003), which attributes a similar notion of cohesion ("light co-ordination between autonomous participants") to the business transaction protocol (BTP) from OASIS.
The relationship between cohesion/coupling and SOA is undoubtedly complex. According to Matt Anderson (Oct 2004, Nov 2004), 'SOA obviously embodies the concept of loose coupling at all levels but SOA actually requires low cohesion to be successful ... Low cohesion is called "coarse-grained".' I think this is a slightly misleading way of saying that coarse-grained services may be expected to have lower levels of cohesion than fine-grained services.
Matt appeals to a 7-level classification of cohesion that crops up in various places including Using Design Cohesion to Visualize, Quantify, and Restructure Software, by Kang & Bieman. Colorado State University, 1996 (pdf). This is essentially to do with internal cohesion., the internal structure of something. This is where we can talk about internal coupling or dependency. There is also a sense of homogeneity - a single internal model. This is the reason why a coherent thing can exhibit doggy behaviours (barking, tail-wagging) or book-keeping behaviours (computing salaries and generating reports) but not both.
(The maverick inventor Arthur Pedrick once took out a patent for a hybrid device that combined the functions of catflap and nuclear fall-out detector. Since patents are supposed to be granted for coherent/compact inventions, it took considerable skill in drafting to get around the normal rules.)
Jef's post (Feb 2005) defines cohesion in terms of integrity, and I think this is broadly correct. But integrity also refers to how something looks from the outside. A service possesses cohesion if it appears consistent, complete and compact from the outside. Other words I use here are Character and Wholeness. (In my 2001 book, I presented Character as complementary to Intelligence in discussing the characteristics of the component-based business.)
Cohesion - however we define it - is important for SOA design. But this calls for business/service models that make some useful notion of cohesion visible. This is one of the reasons why we need a new approach to business modelling for SOA.