Leveraging Loose Coupling Through Mediation Logic

by David A. Chappell

The key ingredient to achieving a flexible SOA is enabling loose coupling between services. Loose coupling between services allows a service, its interfaces, and its data structures to be deployed, modified, or replaced without necessarily affecting all of the other services that communicate or share data with it. Loosely coupled interfaces between services can allow the application logic that resides behind the interface to be changed in accordance with the individual development schedules of the teams that own that business logic.

In SOA that is based on an ESB, this business application logic which is exposed through service interfaces are combined with other intermediary services that help facilitate the communication, data transformation and normalization, intelligent routing between business logic service components. In essence, an ESB provides the mediation logic between business logic assets in a general purpose SOA environment.

A key ingredient of loose-coupling between services is a flexible invocation model. An ESB supports a flexible invocation model which allows the combination of asynchronous event-driven service invocations, and Message Exchange Patterns (MEP) for performing synchronous and asynchronous request-reply service invocations. The communication protocols that transport these invocations are abstractly decoupled from the service definitions themselves. Service invocations in an ESB are built upon MEPs that are configured to use any combination of reliable messaging using point-to-point queuing and publish-and-subscribe delivery modes, Web service invocations via SOAP over HTTP, or other transports such as FTP and email (SMTP).

Another key ingredient of loose coupling is the notion of an abstract process definition that describes the interactions between services in a SOA. When a message arrives “on the bus”, so to speak, it almost never gets assigned directly to a service. Instead, a message which gets placed on the bus gets assigned to an abstract process definition. The process definition, which is orchestrated by the bus fabric, is responsible for dispatching a message to its appropriate service invocations. This allows the degree of flexibility to make changes to the underlying service instances on an individual basis without needing to change all of the associated service endpoints that are involved in the overall process definition. For example, adding stricter validation rules to your services across the board can be done by inserting an intermediary validation service at the beginning of each process definition. This insulates the downstream applications and services from having to retool their own validation logic.

The uniqueness of using an ESB to build such a loosely-coupled SOA is these abstract process definitions, including the MEPs that they control, are configured into the bus, rather than being hardwired into the service endpoints themselves. Furthermore, an integration architect uses a graphical modeling tool to visually describe the orchestration between service invocations. These service orchestrations, which are built upon the configurable message exchange patterns, represent business process definitions that can be readily changed and augmented in order to support the necessary course corrections as your business requirements change.