Service Contract Design Strategies

A key design principle for a Service Oriented Architecture (SOA) is the definition of a service contract. The contract clearly specifies the technical interface a client uses to invoke each service operation, as well as the expected behavior of the service. The contract is independent of the underlying implementation, so users of theservice don’t need to care about implementation details and are shielded from its changes over time. Implementers of the service benefit, too, as they have broad flexibility in determining the implementation strategy, and can fine-tune the implementation over time.

When designing data services, there are two main strategies for service design: contract-first service design and data source-first service design. Contract-first design is very much a top-down design strategy, while data source-first design is bottom-up. In contract-first service design, the technical interface is clearly defined first, using XML Schema to define the information flowing across the interface. The information objects defined by the XML schema, which are the primary subjects of these services, are often custom-designed, but sometimes they are drawn from industry standard schemas. If you work within an industry with a commonly used industry XML schema, chances are good that schema contains many definitions you can reuse for your own data services.

Data source-first design often fits the mental model of a data-oriented developer or architect who is intimately familiar with the physical data sources. In this scenario, the emphasis is more on exposing the data as is, combining data from multiple sources as necessary. The design process here follows a trail of building low level components, then selecting a set of them, and combining them together into a composite which is then exposed as a service. The final technical interface is a composite of many lower level components. The contract is simply derived as a result of the composition work. Some caution is warranted with this approach, as the resulting interface is essentially hard-wired into the back-end systems, making interfaces brittle in the face of change to data sources or client needs. The benefit to this approach is that it leads to extremely quick service implementations, and fits the mental model of many of those charged with implementing data services. Areas of development where many fine-grained services are required will benefit from these approaches.