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”).

The structure of data for your service operations is very important.  This is the primary way that information is transmitted within a service oriented environment.  Moreover, the data model that you use for services will largely dictate service compatibility, interface flexibility, and to some degree will determine the extent of interoperability challenges that you will have as your service catalog expands.

One effective technique for defining the schema for services that I have seen is something I describe as a composite schema. There is a rather large assumption that many service designers make, which is that the schema definition for a service must be atomic.  That is to say that you either define the entire schema inside the service interface file, or define the entire schema in a separate file.  This is fine for the first few services, but what happens if you are six or nine months into service orienting your enterprise and a key aspect of your data model changes (perhaps the ‘customer’ element or ‘product’ element)? You’ll have to go and update the schema for each and every service that uses these elements.  The alternative, is to wrestle with each service design team and get them to agree to a single schema that everyone uses (which becomes bulky and unwieldy).  The answer to all of this, is a composite schema.

A composite schema is one that draws its definition from more than one schema file.  Thus a service interface has some of its data elements defined within one schema and some defined within another (some choose to have a single schema per service interface and simply have that single schema file reference several other schema definition files).  This allows service definitions to be reused and common elements to be defined only once.  When changes inevitably need to be made, this keeps the maintenance overhead to a minimum.

So what should the design of this composite schema look like?  There are several possibilities, but a common approach is as follows:

• Core Data — This schema defines common elements that are consistent across the board within your enterprise.
• Division / Line of Business Data — The next layer tends to focus upon some major segmentation such as industry or business division, etc.
• Product or Service Line – Data structures that are common across a product line or service category are defined in this schema.
• Service Data — Unique elements that are specific to the service are defined here.

Obviously, you could define as many or as few categories of schema as you like.  The goal here would be to minimize how much of a service’s data elements are defined as service-specific data types.  The ideal, would be for 80% or more of the data used within your service interfaces to draw from common, reusable schemas.

Composite schema are by no means revolutionary.  This is a capability that has existed for years.  The problem, of course, is that there is a tendency to craft solutions in a traditional, silo-oriented fashion.  Service orientation drives us to think more about exposing and consuming services across business units, in the broadest possibly context.  It also drives us to compose solutions from existing assets before creating new assets.  All of this leads to a need to work smarter, not harder, and look for opportunities to reduce maintenance costs and more effectively utilize resources.  Composite schemas represent one such technique.