Cohesion and coupling are two fundamental concepts in software development at least since Stevens, Myers and Constantine published their seminal article “Structured Design” in 1974.[1] Since then, however, there has been a great deal of metamorphosis, metastasis and other alterations to the basic definitions depending upon the context and the application.
Stevens, et al. defined coupling as “the measure of the strength of association established by connection of one module to another.” In the context of most current Service Oriented Architecture implementations, this is defined by the association between the services that make up the application itself. Since loose-coupling is often viewed as one of (if not the) fundamental values Service Oriented Architecture (SOA) brings to the enterprise, it is somewhat more well-defined in the SOA context than cohesion.
Applying the principles of high cohesion to SOA is not so readily apparent, but one way to understand it is through its relationship to coupling. Cohesion is usually described through variations of the list originally defined in “Structured Programming” [2] and consist of six or seven levels of increasing cohesion[3] from Coincidental (no significant or discernible relationship between elements in a module) to Functional (elements of a module are grouped together because they all contribute to a single well-defined [and described] task).
In the realm of SOA the same cohesion principles still pertain, but they need to be applied in new ways. There are three different aspects to achieving functional cohesion in an SOA which we suggest should be divided into two categories—“particular” cohesion on the one hand and a “holistic” cohesion on the other. Particular cohesion mirrors the way architects have thought about cohesion for years, while holistic cohesion is more of a reflection of the unique nature of SOAs.
Particular cohesion is an application of the principle of cohesion to services themselves in a manner typical to how it is applied to objects. There are two types of services to which this form of cohesion applies:
- Atomic services
- Atomic services are the single grains in overall granularity of services. They are the smallest, business-oriented service that is required. Such a service might be a GetProductName or GetInventory service.
- This is roughly equivalent to the OO Single Responsibility Principle.
- It also supports the principle of service autonomy.[4]
- Composite services
- A composite service should also do “one thing” even though it may access many other services
- This technically violates the principle of autonomy, but per the definition of functional cohesion in which “occurs when a routine [service] performs one and only one operation,”[5] from a business perspective and SOA perspective a CheckOrder service that utilizes a ProductCatalog service, a Customer service and an OrderRetrieve service is serving a functionally cohesive role.
Holistic cohesion is an animal of different species within the same genus of cohesion. It is an effort to ensure that consumers (applications, other services, etc.) that are communicating with a service maintain cohesion through the vehicle of the message, even though the services themselves are loosely coupled. In order to achieve the goals of reliability, re-usability and understandability, services need to be able to communicate efficiently; improving that efficiency is the purpose of holistic cohesion.
In order to achieve this, the messages themselves must provide the “glue” that makes such cohesion possible. The list below provides examples of how holistic cohesion could be achieved in the context of web services from the least cohesive (1) to the most (3).
- Sending un-typed or generic messages impedes that efficiency and limits cohesion.
- Utilizing messages with explicit internal relationships (i.e. .xml files with internal relationships between data elements defined by an .xsd) improves the cohesion between services without adding additional coupling.
- One of the highest forms of inter-service cohesion is to utilize known business entities described by .wsdl and .xsd with internal relationships between data elements fully described. These entities themselves should be “functionally” cohesive.
The use of business entities ensures that composite services, such as those in the CheckOrder example above, maintain their semantic “sameness,” despite loose-coupling.
[1] W.P Stevens, G.J. Myers, and L. L. Constantine, IBM Systems Journal 13(2): 115-139, 1974.
[2] Along with later works such as Steve McConnell, Code Complete, 2nd Ed. (Redmond: Microsoft Press, 2004), 168-171.
[3] In this context “module” refers to a defined entity such as a class, routine, etc. while “elements” refers to methods, subroutines, etc.
[4] John Evdemon, Principles of Service Design: Service Patterns and Anti-Patterns, (MSDN Solution Architecture Center, 2005) http://msdn.microsoft.com/en-us/library/ms954638.aspx .
[5] McConnell, 168.
