Binding and Coupling

From the Doug Kaye, the man who wrote the book on Loose Coupling

Loose coupling is like pornography. Everyone talks about it, but when challenged, few can tell you what it is. For some, it borders on a religion with the attendant fervor one would expect from the newly converted.

When I say he "wrote the book" I mean that literally. There is probably only one book dedicated to this subject and he wrote it.

• Loosely Coupled: The Missing Pieces of Web Services, Doug Kaye ; RDS Press 2003, ISBN 1881378241

I am not surprised it is possible to write a whole book on this. Firstly it is pivotal to SOA and secondly there are so many different aspects to coupling. Today I will discuss binding and Coupling but my postings on coupling probably will not be able finish until I read this book.

Binding is the time when a logical description of an attribute is tied to its physical value. For instance a service address can be bound when the source code is written, when it is compiled or when it is linked into an executable module. This is called ‘early binding’ or ‘build-time binding’. A service address can also be bound to its physical address when the message is sent, or when it is handled by intermediaries. This is called ‘late binding’ or ‘run-time binding’.

Some formats of payload can also be bound at build-time. For instance java objects (and serialized data objects) are bound at build-time. Therefore a receiver will reject a message containing a serialized java object that is not bound to the same physical representation of the object.

Generally in SOA, loosely coupled services are also considered to have all aspects of their messages bound at run-time. Having an address or payload that is bound at build-time reduces the run-time flexibility of these services.

Binding and coupling could be treated as independent dimensions of the separation between services. A build time dependency on a message is so significant however that I will roll it into the coupling dimension. This is appropriate as coupling is a combination of characteristics and not a single dimension anyway. By rolling build time dependency into our types of coupling it also enables us to keep our definition of a service clean without having to comment on binding between services.

This leaves me with another coupling type ‘Build-Time Coupling’ which I will add to my list of coupling types. It is more tightly coupled than most forms of message coupling. This list has been modified in my posting about Aspect Orient Programming and I intend to republish it again after I have made a couple more revisions.
'Build-Time Coupling’ is still a form of Message Coupling so I still include it as part of a service in SOA. It would generally not be considered good to have these dependencies and we would be justified in excluding build-time dependencies from the definition of a service.

It is good practice to pass version information in messages between services. Therefore a message may contain a version number or a build date so that another service can check it and take appropriate action. If a receiving service detects a change in the version of the sending service then this fact might be logged, or the metadata inspected or the message may be rejected. This is not a build time dependency described above. It is another metadata control. Rather than add ‘version coupling’ to a long list of coupling types I will combine the other coupling types that have similar metadata that control the behaviour of the services into ‘Process Control Coupling'.

I hope to revise my own list of Coupling Types shortly but in the meantime click on this link to look at the list developed by the man who wrote the book on coupling.

Footnote:
I have found and extended forum discussion on Passing Serialized Java Objects vs. Web Services . This features and appropriately named J. Cowboy who is railing against those bullies in management who want him to develop Web Services instead of passing (build-time coupled) serialized java objects around his system.