Composite UI for Service Oriented Systems – Coupling

This blogpost is part of a larger blog post series. Get the overview of the content here.

Coupling is a measure of dependencies. If a component X depends on Y, then there is coupling between them. There are two kinds of coupling: Afferent and Efferent coupling.

Afferent coupling counts the number of dependencies going into a component and therefore can be summarized with the question “who depends on you”. Efferent coupling counts the number of dependencies going out of a component and therefore can be summarized with the question “on who do you depend”. So if X depends on Y then X is efferently coupled to Y and Y is afferently coupled to X.

We learned from that exercise that we need to minimize the afferent and efferent coupling. But zero coupling isn’t really possible.

When we talk about aspects of coupling for systems we can differentiate platform, temporal and spatial coupling.

Platform coupling reduces interoperability. Therefore if you need interoperability and you most certainly will need it sometime you should minimize platform coupling. Examples of platform dependent protocols are Remoting, Enterprise Services and Datasets over Webservices. Also be aware that some of the protocols supported by WCF are platform dependent.

You can use XML / XSD, JSON, Protocol Buffers, HTTP as a standard based transfer protocol, message flow descriptions like WSDL and more.

So if X depends on Y and the processing time of Y directly influences the processing time of X then there is a temporal coupling between X and Y.

Here we see an example of such a temporal coupling.

To actually resolve the temporal coupling we need to separate the inter-service communication in time. This can be achieved by changing the Service B so that it actively publishes customer information updates and the Service A subscribes for those updates.

Great. We solved the temporal coupling aspects by applying publish and subscribe. But now service “A” makes its decisions based on stale data. But this is actually great; the chosen architecture enforces discussions with the customer. Can you live with stale data? How old can it be? What happens if stale data is detected? And if the business tells you that publish and subscribe doesn’t work, then request and response is also not possible because there could also be stale data! Data is always stale as soon as you acquire it. Just live with it!

Spatial coupling is available when a system is directly dependent upon a resource on a physical location.

By introducing logical destinations for example physical destinations behind a load balancer and routing to those logical destinations you reduce the spatial coupling. Physical machines can be taken offline without affecting the system.

So what can we do to address the fallacies of distributed computing and reduce coupling in our system? One answer to that question will be discussed in the next posts.