Service loose coupling principle

Service loose coupling dictates that this kind of coupling should to be favored so that the service logic is developed exclusively in support of the service contract. However, this requires following the 'contract first' approach as advocated by the standardized service contract principle so that the service logic is coupled to a standardized contract. This way the service contract is not coupled to the logic so the logic could be replaced in future if need be without affecting the service consumers.

This type of coupling exists when the contract is built based on existing logic e.g. through automated tools.[6] This is a negative form of coupling and needs to be avoided as it inhibits the evolution of service contract. This is because the service contract is not designed independently according to the design standards and is dictated by the underlying logic.

When contracts are designed in a manner that they are based on the underlying implementation details e.g. data models used within the underlying database, this results in a negative form of coupling that needs to be avoided. This way, a change in the underlying implementation will require a corresponding change in the service contract. This type of coupling can be reduced with the introduction of a façade component in between the service logic and its implementation as advocated by the Service Façade[7] design pattern.

A contract that exposes proprietary technology elements used by the service logic e.g. a contract based on .NET Remoting technology, forms a negative form of coupling as the service consumers are limited to that particular technology. This greatly hampers the service’s ability to be counted as an interoperable enterprise-resource.

This type of coupling normally exists when the service contract is developed by keeping a particular kind of consumer in mind e.g. services built to enable communication with a business partner or a service that executes a part of the business process logic or is itself the parent controller service in a service composition that executes the business process logic. This is also a negative form of coupling and needs to be avoided. Although in case of agnostic services there is a clear need to reduce this coupling type, however, in case of non-agnostic services e.g. the task services, existence of such coupling is intentional because the service is not required to be particularly reusable and hence could be tightly coupled to a particular consumer for better efficiency.

This is a negative form of coupling that exists because the service consumers access the service directly either via its logic or implementation. This can happen because of number of reasons. For example, the service consumers used to access the current service through streamlined proprietary interfaces long before it actually existed as a service i.e. before the move towards service-orientation. The application of the contract centralization[8] design pattern helps to avoid this kind of coupling.

This is a favorable type of coupling as it helps to evolve the service without impacting its consumers. However, it is quite important to bear in mind that this coupling should only be restricted to the service contract and should not leak into the service architecture. This could happen if all of the negative contract related coupling types are not addressed, consequently the service consumer can easily become coupled to the service implementation, logic or technology.