Requires Free Membership to View
The essence of loose coupling is to allow changes or problems that happen on "one end of the wire" to avoid impacting the other end. That is, changes to or problems with providers or services shouldn't impact consumers – and vice versa. An example is that, if a new version of a service is being rolled out, consumers of the service shouldn't have to be modified, they shouldn't have to be redirected and they shouldn't even experience any downtime – it should be transparent to them. In the reverse direction, if a consumer of a service decides to change the provider they are using (maybe a lower cost service becomes available) this shouldn't require that the consumer application needs to be recoded or even interrupted to do so. Web services management brokers are often used between consumers and providers as an essential element in providing loose coupling.
Once you understand the concept behind loose coupling, it's easy to take it to the opposite extreme and try to use it everywhere. But, loose coupling has its costs, so it's not always appropriate. The best way to decide when you need loose coupling and when you don't is to understand the deployment of your application. Which parts of your application are always intended to deploy together (if one part versions, the others do also – I call this a "unit of deployment")? Contrast this with parts that are intended to be changed and updated independent of one another. For example, different team will typically be on different roll-out schedules (and will thus be in change of different units of deployment). When you understand what the units of deployment are for your application, then you'll know when to use loose coupling (across units of deployment) and when not to use it (within a unit of deployment).
This was first published in March 2005
Join the conversationComment
Share
Comments
Results
Contribute to the conversation