Service Loose Coupling


SOA Principle 2: Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding evironment


This second SOA principle puts focus on coupling, one of the main enemies to defeat through an SOA strategy. The goal is to achieve low coupling, as low as possible, and we will often talk about decoupling.


Loose Coupling

In its statement promotes, as an objective of the design of service contracts, to achieve a low coupling at two levels:

  • Outside the service, with consumer service systems. That is, when future changes arised in the design of the service, consumer systems should be impacted as little as possible.
  • Internally, where the minimum dependency between the internal components of the service must be maintained: messages, business rules, business processes, possible services of lower granularity that comprise it, its technological implementation, etc.


Specifically, the second part of this principle seems fundamental to me: it establishes the total decoupling between the service and the surrounding environment, which allows the service to decouple the systems that are integrated from each other.


Be careful, because we’re not talking about loose coupling, we’re talking about zero coupling. This is nothing more than the consecration in the SOA principles of one of the basic premises of SOA:

  • in contrast to the traditional system integration approach, where the systems involved have to be known in order to solve this integration, thus being coupled, service orientation breaks this dependency and establishes a boundary between affected systems that must be insurmountable. They are no longer interested in any details of the other system, but only the details of the interface offered by the SOA service in its Service Contract.


Achieving low coupling is a critical factor for the success of an SOA strategy. In this problem lies a large part of the increasing costs in ICT projects with interoperability requirements, and is the main consequence of weak governance in the systems map of an organization.


But the decoupling we have to pursue has several faces.


Technological decoupling.

Apart from the decoupling between the service and its environment, which advocates for the encapsulation of services, there is also the technological decoupling. This means that we must be able to publish any service to any information system, whatever its technology is.


Obviously there are some limitations, but the SOA strategy has to build bridges, facilitate the integration of all participating systems with the least possible impact. And it often happens (more than we think), that existing systems have very old, or very rigid technology, or they simply do not have the ability to migrate to newer technology. For this reason, we need the many adapters that must incorporate the ESB.


But in the design and construction of services we must be aware of this issue, and use open technologies (XML, XSLT, etc.), and avoid designs conditioned by peculiarities too specific to any particular technology.


Decoupling in messaging.

Another factor that directly affects the loose coupling is the use of standards to define messaging.


The main advantage of standards is that they define with universal precision a scheme (kind of template), which serves as an interface that everyone can use, regardless of any technological consideration.


If we do not use the standards, if we fall into the definition of proprietary messaging, we are accepting a certain level of coupling at the messaging level, which must also be avoided.


Transactional decoupling.

Another type of coupling much more subtle and that can not always be avoided is the transactional coupling. With this we refer to the effect that causes the systematic use of the synchrony between extremes.


When a service is defined as synchronous between extremes, such as query-response services, we can be fulfilling all known SOA principles but we will be making our user, the user of our information system, depend on the availability not only of the system he is using, but also the one that must respond to the query at a certain time, and in an acceptable time in terms of performance.


In addition, these cases are still point-to-point integrations, with which we lightened very little the systems map of the organization.


In contrast to this pattern, the use of asynchronous services between extremes should be promoted, and for this, the events orientation (EDA), of which we have spoken several times in this blog, is the correct approach.


This approach often involves a rather radical change of approach in the information systems that provide and consume these services, since the former are accustomed to be consulted, and the latter are accustomed not to include certain information in their data model, and seek it out by means of the corresponding web service.


However, this is actually due to malpractice, perhaps derived from the times when storage was expensive, and redundancy of information was insistently avoided. Nowadays the context is totally different, and the correct thing is that if an information system in your data model needs information of a certain entity, that entity must be included in its model.


When they do not, they must consult it in that other information system that maintains the business relative to that entity, and in this way we fall into the trap of the coupling at transactional level, and also at the data model level, which is even worst.


If, on the other hand, all entities meeting the requirements are included in the data model, it is possible to put a passive subscription architecture to the events related to that entity, so that these events are triggered by the system responsible for the entity’s business, those that send the information to be stored in our data model.


In this way, our system do not depend on the other system, my user has the information available and updated, and the response times are optimal, since the integration occurs unattended.


In short, this second SOA principle focuses on decoupling as a fundamental design goal that must be in the minds of all SOA architects (consultants, analysts, developers, etc.).


It is a critical success factor that directly affects the return on investment of the SOA strategy, since it allows the release of the information systems of the organization to be able to evolve independently, keeping all interoperability needs covered by the layer of encapsulated standard services published in the ESB.


Te puede interesar


Submit a Comment

Your email address will not be published. Required fields are marked *

Follow me on social media

Share This