Service Design - Intermediaries

September 26th, 2008 by Kyle Gabhart

In the most pure and simple service oriented scenario, a single consumer interacts directly with a single service provider.

Service Consumer directly calls Service Provider

For more complex situations, intermediaries are used to provide additional capabilities:

  • Security
  • Transactions
  • Routing
  • Data Mapping
  • Interface Mapping
  • Reliability
  • Protocol Translation
  • And etc…

What exactly is an intermediary?

An intermediary is a piece of hardware or software that bridges the gap between a service provider and service consumer to provide one or more value-added capabilities (see bulleted list above). There are three primary options for intermediaries (and a host of variations on these three themes):

  • Service Intermediary - Another service acts as the intermediary, providing required enterprise capabilities
  • Centralized Bus - Service calls are brokered through a common, centralized focal point
  • De-centralized Framework - Enterprise capabilities (security, mapping, etc.) are pushed out to the endpoints

Comparing the three options

As with so many things, there is no clear-cut winner across these three strategies, it all depends upon what you are trying to accomplish.

Option 1: Service Intermediary 

Consumer calls service through an intermediary

Advantages: Extremely lightweight solution.

Disadvantages: Not as robust or flexible as other approaches and requires more testing to verify proper configuration.

Option 2: Centralized Bus

Centralized Bus as an intermediary

Advantages: Offers lots of “out-of-the-box” capabilities that are pre-configured and available for use.  Provides a single point of control and service access management.

Disadvantages: May be over-kill in many situations, offering far more functionality and options that are needed.

Option 3: De-centralized Framework

Decentralized policy framework

Advantages: Provides the greatest flexibility and configurability for managing endpoints and enforcing policies.

Disadvantages: Requires a more disciplined governance process to ensure that each service is managed properly.

Working with intermediaries

Services do not generally need intermediary support except to provide value-added capabilities such as security, transactions, routing, data/interface mapping, guaranteed delivery, protocol translation, etc.  It is important that organizations carefully evaluate their requirements and select architectural strategies that meet their needs.  There are a variety of valid topologies that could be employed, depending upon your requirements, including services as intermediaries, deployment of a centralized bus (either physical or logical), and the utilization of a decentralized, policy-driven framework (“liberate the endpoints”).

Posted in SOA | 1 Comment »