Dealing with Loose Coupling in a Service-Oriented Architecture

Process-control decisions can also lead to different forms of coupling. Having one central component controlling the whole process logic creates a bottleneck because each involved system must connect with it. Failure of such a central component will stop the whole process.

On the other hand, if you have decentralized or distributed control (where each component does its job and knows which component will continue after) you avoid bottlenecks, and if some systems fail, others can still continue to work. See Section 7.6 for details.

4.2.10  Deployment

Whether you require that system updates be deployed simultaneously, or at different times, is related to coupling. Of course, systems are bound more tightly to each other if it is required that they update synchronously. The more loosely coupled approach of updating at different times, however, leads to a very important drawback: the need for migration, which leads to versioning (see Chapter12).

4.2.11 Versioning

Your versioning policy also has something to do with tight or loose coupling. If a system provides certain data types that are used by a consumer, you’ll have problems when the provider adds new attributes. If the provider introduces a new type version, the consumer will have to upgrade explicitly to this new type; otherwise, the provider will have to support both types. If, on the other hand, the provider just adds the attribute to the existing type, this might cause binary compatibility issues, and require the consumer to recompile its code or use another library.

With a more loosely coupled form of data type versioning, the consumer won’t have to do anything as long as the modifications are backward compatible.

However, as discussed in Section 12.3, achieving loose coupling here can be very complicated. Again, it’s up to you to decide on your policy by discussing the pros and cons.