Bragging Rights on Coupling

I am reading "Enterprise SOA: Service-Oriented Architecture Best Practices" by Krafzig, Banke and Slam and I have come across a section on "Tight Versus Loose Coupling". This is a topic of my recent post" Cohesion, Coupling and SOA.

In my earlier post I described the taxonomy from loose coupling to tight coupling provided in a Pressman textbook
· No direct coupling
· Data Coupling
· Stamp Coupling
· Control Coupling
· External Coupling
· Common Coupling
· Content Coupling

I then added to this Message Coupling which was suggested by Thomas Erl. Now Krafzig et al is suggesting there is more to message coupling than just a single category. The book describes seven dimensions of messaging coupling. The 'coupledness' created by messages will depend on
The physical link (eg. Whether messages are put on a queue or the communication is a point to point communication).

• The communication style (eg. Asynchronous or synchronous)
• The type system (eg. Is the type determined by the called service interface or the message payload)
• The interaction pattern (eg. A service is more loosely coupled if it receives a message, then processes it and then can forget about it such as a stateless service. Tight coupling is required if for example the service uses an internal variable to keep track of the state)
• Control of Process Logic (eg. Additional coupling can be added to impose transactional integrity)
• Service discovery and binding (eg. Are services discovered through UDDI or similar means or are they directly referenced? )
• Platform dependencies (eg. Tighter coupling results if the service must always invoked from the same technical platform).

This threatens to make a mess of the neat one-dimensional coupling spectrum but we must remember that the spectrum of coupling types is only a guide and that it was always possible to have combinations of coupling types. I develop a priority listing below.

What was meant by message coupling in my earlier post was focusing on the asynchronous nature of messages. All the Pressman coupling types assume synchronous procedure calling and this was proposed before the time of distributed computing so they all are fundamentally coupled by the fact the modules were running on the same piece of hardware. Distributed computing warrants its own sort of coupling. The new spectrum might look like (from loose to tight coupling):

0. No direct coupling
1. Services Registry Coupling
2. Message Payload Coupling
3. Queue Coupling
4. Asynchronous Coupling
5. Plane Old Message Coupling
6. Bind-Time Coupling (added from later posting)
7. Process Control Coupling
8. Creation Coupling (added from later posting)
9. Process State Coupling
10. Platform Coupling
11. Distributed Coupling
12. Data Coupling
13. Stamp Coupling
14. Control Coupling
15. External Coupling
16. Common Coupling
17. Code Coupling (added from a later posting)

Rather than use the dimensions of Krafzig et al I have used labels of describing and example of a a coupling category within that dimension. In most cases it is the looser coupling category. This is consistent with the earlier coupling types. Therefore I use 'Queue Coupling' for the 'Physical Link' of Krafzig et al and 'Asynchronous Coupling' is used instead of 'Communication Style'.

I have inserted "Plane Old Message Coupling" in at number 5. In fact all coupling types from 1 to 9 are message coupling. Coupling types 7,8 and 9 increase the coupling between services. Coupling type 1 to 4 loosen the coupling compared to a synchronous message, called using its inteface without the assistance of queuing or a registry.

As discussed in the earlier posting the classic coupling types are still relevant to SOA. If you use a tight coupling type then it does not matter what good things you have to decouple your services there will still be tight coupling.

The numbers in the above list can be used as score. A low score is good loose coupling. For example if you are sending messages with Boolean values that significantly effect the processing in the called services then you have control coupling and you score badly with a 14. It does not matter that you are using asynchronous message and type is based on the message payload. The services are still tightly coupled. Similarly if you send a huge amount of XML and the service only uses a part of this then this is 'Stamp Coupling' and can only score an 13.

Loose coupling in our ideal SOA applications requires our services to be recorded in a registry, to be driven by the message payload, to use queues to communicate, to be asynchronous, to not have overriding process control and to be stateless. These services are platform and hardware independent. The payload should not contain extraneous data, or control values. The operation of the services should not communicate using external methods or use common shared data areas.

If I ever write a software development text I think this would be useful content. Perhaps this can be used as bragging rights however I am not the sort of person to say something like "How many types of coupling do you know, I know 18".

References

Krafzig, Dirk, Banke, Karl and Slama, Dirk, Enterprise SOA: Service-Oriented Architecture Best Practices, Prentice Hall, 2004, Section 3.5

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

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