Monday, October 22, 2007

SOA EDA Conundrum - Loosely coupled and decoupled architectures

There is a common misconception between loosely coupled and decoupled architectures. In fact the misconception is such that people use the two concepts interchangeably.
A loosely coupled architecture is one that is evident in the foundation principles of SOA. Based on the degree of coupling a service consumer may:
  • Directly invoke the service producer by knowing the service URL a-priori
  • Only know about a presence of virtualized service which in turn has the intelligence to route the consumer request to the most pertinent service that may fulfil the request
  • Only know directly about the presence of a registry

In SOA the service consumer and the service producer is loosely coupled but there remains an element of coupling between them the degree of which is based on the chosen architecture.

A decoupled architecture is one in which the emitter of a business event has absolutely no knowledge of the potential receiver(s) of the event and what a receiver may do with the event. This is the principle behind EDA. EDA hence is tailor made for asynchronous communication but that is not to say that a synchronous communication is not possible using EDA.

In fact just like you can use SOA for asynchronous communications between the service consumer and the provider you can also use EDA for synchronous and well-defined, predictable communications between the event source and the recipients.

SOA and EDA can certainly coexist and that too in a very compliementary manner. Using both in a hybrid architecture can realize the real-world business requirements wherein both synchronous and asynchronous communications may possibly be required to realize complex requirements.

It is our responsibility as architects and thought leaders to come up with prescriptive architectures and guidance around how to develop a hybrid architecture based on SOA and EDA principles.