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.

AOP: The worst form of Coupling

I have just had the need to look at Aspect-Oriented Programming. The Wikipedia entry on this is very good and covers the benefits and risk well. The following provides a good summary of what AOP is all about:

…an aspect can alter the behavior of the base code (the non-aspect part of a program) by applying advice (additional behavior) at various join points (points in a program) specified in a quantification or query called a pointcut (that detects whether a given join point matches).

This offends my sense of what is good modularized code. AOP is done under the banner of "Separation of Concerns" but instead of separating parts of programming code in simple and visible ways, AOP is coupling it tightly. AOP is coupling code modules in ways a programmer would not expect from viewing the affected code. This is tight coupling of the worst kind. In my earlier posting on coupling I rated types of coupling from 0 to 14 from loosest to tightest. I will call this type coupling "code coupling" and give it 15, the tightest coupling index of all. The coupling is through the code rather than through data passed to the module. Code coupling is not new but I did not expect it to come up as modern programming paradigm.

Another form of code coupling is "inclusion coupling" which is explained well by Milind Shingade

Inclusion coupling is a form of coupling in which one component includes source code of another component. If the included component changes something on which includer depends or adds something that raises the conflict with something in the includer then the includer must change.

I see inclusion coupling as more benign than using AOP but I will still roll it into my "code coupling" category.

Control Coupling (coupling index 12) is pretty tight. This is where you pass a Boolean or control parameter to a procedure and have code in that procedure which checks the value and executes different logic based on that control parameter. This is one way of affecting the executed logic in the procedure but at least you can read the code and have some expectation of what the behaviour is going to be. With AOP an unsuspecting maintenance programmer may not have any idea that the program code is being affected by an "aspect".

Unfortunately I have to grant there may be a place for AOP. Code for auditing, logging, exception handling, security and range of routine work that needs to happen along with the business logic can make it difficult to discern the main thrust of what program code is trying to achieve. There is a big need for control and proper governance of AOP. If it has to be used then only senior developers should implement the Aspects. It only should be used in very limited circumstances. Ideally there should be clear documentation in program modules affected by an Aspect.

This should not be a pervasive programming paradigm. The programming should not be Aspect Oriented at all. Code should normal, good Object Oriented code but if AOP is supported a developer may introduce one or two Aspects to influence this code.

In summary I think AOP may be a horrible necessity in some programs and should be used with extreme caution. AOP has given me another type of coupling to add to my list. I had expected the next entry to my coupling list to be in the looser coupling range. I recently listened to a Podcast from Jim Webber of ThoughtWorks. Jim claims that MEST uses looser coupling than WSDL. I would like to see that. I am hoping to blog on this soon.