Loose coupling
From AMWA
Loose coupling describes an approach where integration interfaces are developed with minimal assumptions between the sending/receiving parties, thus reducing the risk that a change in one application/module will force a change in another application/module.
The Loose coupling concept has multiple dimensions, for example:
- Platform - Choice of service hardware, operating system, or implementation language should not constrain choices for service consumer.
- Time - When participants are loosely coupled in time, they don't have to be up and running at the same time to communicate. This requires some way of buffering/queuing in between them, although the approach taken for this is irrelevant. When one participant sends a message to the other one, it doesn't rely on an immediate answer to continue processing.
- Location - If participants query for the address of other participants they intend to communicate with, the location can change without having to reprogram, reconfigure, or even restart the communication partners. This implies some sort of lookup process using a directory or address that stores service endpoint addresses. (See Service Discovery and Service Registry).
- Version - Participants can depend on a specific version of a service interface or be resilient to change (to a certain degree). The more exact the version match has to be the less loosely coupled the participants.
- State – To increase loose coupling, the result of an interaction should not implicitly depend on previous interactions between the same participants. In other words, the interaction should be stateless instead of stateful: any state relevant to the interaction should be explicitly exposed as part of the interaction itself.
