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.