In this previous post (Why SOA is the Foundation for Innovation – Part I), an explanation was given for why the principle of Loose Coupling in a SOA is fundamental to the promotion and fostering of innovation in a system. In this post, we will discuss fundamental patterns that implement the key principle of Loose Coupling.
Loose Coupling Defined
First off, Coupling can be defined as the relationship between things. If there is a very strong (tight) relationship between two things, then when one thing changes the other thing must change or the system will break. In a complex, tightly coupled system with 100’s or 1000’s of “things”, the effort or cost to change is very high because a change to one thing requires changes to many other things, directly or indirectly, coupled to it – otherwise the entire system will break. Clearly, this paradigm is strongly opposed to ease of change and innovation!
On the other hand, Loose Coupling advocates minimizing the dependencies between things. Additionally, the dependencies that DO exist between things are put under a microscope and micro-managed to prevent the proliferation of future dependencies. Therefore, agility (or the ability to quickly change) is increased due to the reduced impact that a change to one component has on all the other components in a system. This also allows individual things in a system to evolve independently which fosters the spirit of innovation.
Loose Coupling Patterns
Now that we understand that Loose Coupling, a key principle of SOA, is fundamental to fostering innovation, let’s turn to a couple of fundamental SOA design patterns that, if followed, make Loose Coupling “real”. In a SOA, the goal is to promote loose coupling in 2 main areas:
1) Between Services – The provider service is able to perform its functions without any help from other services.
2) Within Services – The interface is decoupled from technology and implementation details and only exposes the functional spirit of the domain.
The following pattern summaries help to realize loose coupling in a SOA:
Transformation – For example, a service which wraps a legacy system, may utilize an intermediary component that performs a data format transformation of CSV (common in legacy environments) to XML, before the legacy processing begins. This transformation component decouples the interface from the implementation. Transformations tend to reduce performance yet they are unavoidable in most environments.
Intermediate Routing – dynamically determines a message path based on factors such as the message contents or service utilization (load balancing). This may be achieved through intermediary agents that read messages and dynamically determines their path, calling the appropriate service. This decouples the connection between services.
Asynchronous Queuing – An intermediary queue receives a service request, message ABC, and forwards them to the provider, when it’s ready. The provider may not be ready because it is already busy processing a previous request. The queue will determine when the provider is ready. Additionally, this enables the consumer to go on processing other requests until the provider has finished processing message ABC (in a request/response message pattern) – all enabled by a queue, decoupling the consumer and provider.
Event-Driven – enables consumers to be automatically notified of provider events. An intermediary event agent manages the consumer subscriptions and provider event notifications, decoupling the communication between services.
These above patterns, commonly found in an Enterprise Service Bus, are some of the more important ones that can be used to realize a loosely coupled SOA that serves as the foundation for innovation!