Service Design - Intermediaries
In the most pure and simple service oriented scenario, a single consumer interacts directly with a single 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

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

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

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 |
October 9th, 2008 at 7:48 pm
[…] Kyle Gabhart - Service Design - Intermediaries […]