Where it came from
During my years in enterprise application integration (EAI) I have identified a number of coupling factors, which influence design decisions in the context of the constraints given in a specific situation. I realized that as an integration architect you have to answer the same questions every time. I'll be illustrating the coupling factors from an angle where one partner (system) communicates with another. Thus, it is kind of systems integration biased, nevertheless, I find myself applying the factors in all kinds of design situations. I feel that they are generally useful, and I hope that they will help you, too.
Loose and strong coupling
There has been written a lot about this, so I'll keep it short like the rest of this post.
- Coupling in this context means to know things of others to be able to communicate with them. Strong coupling means to know more, loose coupling to know less.
- Strong coupling is the easy way. It requires less effort and gets stuff done more quickly at first.
- Decoupling gives partners more space. What another doesn't know, I can easily change.
- Let me be clear (how Obama would say it): Loose coupling (decoupling) is usually more work and more expensive to build. It may require looking beyond the immediate gains of simpler solutions. The payoff may not be visible to everyone.
- Like with all architectural decisions, there is no good and bad unless you include the relevant constraints in your judgement. Forget so-called best practices. There is no best, just more appropriate.
Factor 1: Peer-To-Peer
Real life analogy: I know who you are.In P2P coupling the partners know each other. They know who is comunicating with them. An interface may even be individually tailored for one partner alone. This is very common in systems integration, unless publish-subscribe is used. Most interfaces start out as an individual solution for a first client of a system.
Factor 2: Location
Real life analogy: I know where you live.Location coupling means to reveal an individual address to a partner. P2P coupling does not necessarily reveal an address, yet. A system may send messages, which are specific for a partner, through a middleware without knowing the location. Location coupling inevitably leads to P2P coupling.
Addresses can be defined on different levels of abstraction. For example, An MAC address is lower than an IP address, which is in turn lower than a DNS address. Each higher level introduces some decoupling.
Factor 3: Representation
Real life analogy: I can look through your window.Coupling through representation means to reveal ones inner data structure through an interface. This is so common in Java WS-* implementations for example that it hurts. Just slam a bunch of annotations on your domain classes and presto - your webservice! Representation coupling severely restricts the space for change in a service. This can be totally ok in tightly coupled layers inside a system. Between systems it is a very bad idea.
Factor 4: Integrity
Real life analogy: I can enter through your window and rearrange your furniture.While coupling through representation is the read-only case, coupling through integrity goes one step further. A system is able to directly manipulate internal data structures of another system. This is possible in database integration scenarios where a system writes to foreign or even shared tables. Terrible idea. To allow this coupling, there must be very solid reasons, for example enormous amounts of data to be delivered in short time with no option of transformation of representation. If the data provider screws up the integrity, the affected system may not work anymore. Consider at least a staging or versioning mechanism as a defense line.
Factor 5: Synchronicity
Real life analogy: You are using my time.When a client is required to wait for the completion of its request, it is synchronously coupled. Most systems are coupled synchronously, especially over HTTP, which is synchronous unless special pseudo-asynchronous techniques are used. A messaging middleware infrastructure can establish asynchronous communication. However, this requires totally different strategies in the partner systems. Asynchronous processing is much more complicated. It even affects how a user can interact with a system through the UI.
Factor 6: Distributed Lifecycle
Real life analogy: A kid travels alone and calls mom every hour.When a logical data concept (business data object) is created in one system and then travels across to other systems where it gets manipulated (a copy of it, that is), its lifecylcle is distributed. In many cases all participating systems like to be notified of changes in the lifecycle. This is a very fragile coupling. Distributed state is a delicate problem to solve and should be avoided. It may be an indication for a bad vertical slicing of system responsibility. However, in real life, where systems with overlapping data requirements evolve one after another without replacing each other, it happens quickly.
Where to go from here
Was that all? Of course not. There is plenty more things to consider while designing systems interaction. You may find more fine-grained coupling factors. From my experience though, the six factors I've presented pretty much cover the most important everyday coupling problems.We have also not addressed the other numerous nonfunctional aspects, which coupling is just one part of. I thank you for reading up to here :-)
