Service loose coupling principle

Within the service-orientation design paradigm, service loose coupling is a design principle[1] that is applied to the services[2] in order to ensure that the service contract is not tightly coupled to the service consumers and to the underlying service logic and implementation. This results in service contracts that could be freely evolved without affecting either the service consumers or the service implementation.[3]

Purpose

The concept of loose coupling within SOA is directly influenced by the object-oriented design paradigm,[4] whereby the objective is to reduce coupling between classes in order to foster an environment where both the classes, although somehow related to each other, can be changed in a manner that such a change does not break the existing relationship, which is necessary for the working of a software program. The same concept applies within SOA world as well, however, within SOA particular emphasis is on the service contract as the service contract acts as an interface through which service consumers communicate with the service logic and vice versa. Apart from this, SOA strongly advocates development of physically independent service contracts from the service logic (decoupled contract[5] design pattern) in favor of interoperability and technology independence. As the contracts are physically independent, there is a need to not only look into the coupling between service consumers and service contracts but also between service contracts and their underlying logic and implementation. This is where the application of this design principle helps in identifying the various types of couplings that exist (inter service as well as intra service) and how to design the contracts in order to minimize negative coupling types and maximize positive coupling types. A service-oriented solution that consists of services having loosely coupled contracts directly supports the increased vendor diversity options and increased interoperability goals of service-orientation.

Application

The application of the service loose coupling design principle requires delving into the different types of couplings that exist between the service consumer and the service contract as well as the service contract and the service’s implementation. Only by understanding these different types, their impact on the service-orientation can be correctly analyzed.

Coupling types

Logic-to-contract

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.

Contract-to-logic

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.

Contract-to-implementation

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.

Contract-to-technology

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.

Contract-to-functional

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.

Consumer-to-implementation

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.

Consumer-to-contract

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.

Considerations

Designing service contracts that are totally decoupled from their internal and external surroundings would no doubt result in services that are interoperable and scalable but on the other side, this may create contracts that have capabilities which are too generic or the capabilities’ message exchange is too generic which would result in more roundtrips, requiring increased processing resources and time.

Analyzing all of the above different types of coupling requires extra time and efforts and may increase the delivery time of services. Consequently, there is a need to apply this design principle to a meaningful extent as set by the design standards within the individual organization.

References

  1. ↑ Design Principle
  2. ↑ Services
  3. ↑ Michael Poulin.Evolution of principles of Service Orientation: Service Loose Coupling and Abstraction, part 3[Online].Date accessed: 12 April 2010.
  4. ↑ Bernhard Borges,Kerrie Holley,Ali Arsanjani Delving into Service-Oriented Architecture[Online].Date accessed: 12 April 2010.
  5. ↑ Decoupled Contract Pattern
  6. ↑ Tost. et al.Guidelines for Using Web Service Contract Technologies[Online].Date accessed: 12 April 2010.
  7. ↑ Service Façade Pattern
  8. ↑ Contract Centralization Pattern

External links

This article is issued from Wikipedia - version of the 6/10/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.