Service-Orientation with .NET : Service Loose Coupling

This principle is primarily concerned with design-time dependencies, with a particular focus on the technical service contract. Coupling considerations apply, regardless of service implementation medium.

When applying the Service Loose Coupling  principle to a service architecture, we need to understand the different kinds of coupling (good and bad) that can exist.

• logic-to-contract coupling– This refers to the coupling of the internal service logic to the service contract. It is generally considered a positive form of coupling that preserves the service contract’s independence from the underlying service implementation.

• contract-to-logic coupling– The opposite of logic-to-contract coupling is contract-to-logic coupling. When the service contract is dependent on the underlying service logic, it results in an architecture contrary to the goals of the Service Loose Coupling principle because changes to the logic can impact the service contract and, consequently, service consumers that have formed dependencies on the service contract.

• contract-to-technology coupling– Similar to contract-to-logic coupling, this negative coupling type results from forcing service consumers to bind to a platform-specific technology protocol in order to invoke a service. For example, expecting consumers to send a serialized DataSet object to a WCF service or returning such an object to the consumer will introduce this kind of coupling.

• contract-to-implementation coupling– This type of negative coupling results from directly expressing characteristics of the underlying service implementation (the physical data models of databases or APIs of legacy software, for example) within the service contract.

• contract-to-functional coupling– This negative coupling type can sneak into a service when generic logic is designed with a particular business process or pre-built consumer in mind. As a result, the service contract can become dependent on the underlying functionality.

• consumer-to-implementation coupling– This form of negative coupling occurs when the Contract Centralization pattern is not consistently applied. Allowing consumer programs to bypass a published technical contract in order to directly access underlying resources was also a common side-effect of point-to-point integration architectures.

• consumer-to-contract coupling– A positive coupling type that results from service consumers having limited access to the service contract. Consumer-to-contract coupling is the desired result of Contract Centralization .

Note how all described coupling types revolve around how the service contract is defined and architecturally positioned (Figure 1).

Figure 1. This diagram (originally from the SOA Principles of Service Design book) illustrates how consumer-to-contract coupling alone can be insufficient when the service contract is negatively coupled to other parts of the service implementation