Article: Ian Robinson on Consumer-driven Contracts

Posted by Stefan Tilkov on Jul 28, 2008

Sections

Architecture & Design,

Enterprise Architecture

Topics

SOA ,

Design ,

Governance

Tags

WSDL ,

policy ,

XML Schema

In a new article, Ian Robinson, a Principal Consultant with ThoughtWorks, discusses how "consumer-driven contracts", in the form of "stories for services" and unit tests exchanged between service development streams, can strengthen the service-oriented development lifecycle. In contrast to contracts defined from the point of view of the provider, consumer-driven contracts result from combining the demands of all known service consumers.

Ian introduces consumer-driven contracts as they relate to provider contracts and consumer contracts:

• Provider contracts - Provider contracts are the kind of service contract with which we are most familiar -think WSDL plus XML Schema plus WS-Policy. Provider contracts are, as the name implies, provider-centric. Providers mandate what they have to offer; each consumer then binds itself to this one-size-fits-alloffering. By adopting a provider contract, a consumercouples itself to the entirety of the provider's functionality, irrespective of how much of this functionalityit really needs.
• Consumer contracts - A consumer contract, on the other hand,is a more exact description of an individual consumer's needs. Consumer contracts represent the specific pieces of provider functionality required by that consumer in the context of a particular interaction. Consumer contracts can be used to annotate an existing provider contract, or they can help discover an as-yet unspecified provider contract.
• Consumer-driven contracts - A consumer-driven contract is a representation of a service provider's obligations to all its current consumers. Consumer-driven contracts are created when each consumercommunicates to the provider its specific expectations. The obligations created on the provider's side establish a consumer-driven contract. As part of adopting a consumer-driven contract, a provider is free to evolve and innovate its service offering just so long as it continues to satisfy its existing obligations

The author then explores how consumer-driven contracts can be used within the phases of the service development lifecycle, ranging from the initial phase through building and operating them.

Ian summarizes:

Consumer-driven contracts support the development and testing of service-oriented systems, and encourage collaboration between all parties responsible for the service lifecycle.

Check out the full article for more.

1. Back to top

   whose contact is more contractible

   by Michael Poulin

   Interesting article, especially in the light of OASIS SOA Reference Architecture -RA(Public Review Draft 1). In particular, SOA RA considers a bit simpler structure: the are 1) Service Descriptions and 2) Service Contracts.
   
   The Service Descriptions are versioned description of the Service offered by the Provider. This document includes all information needed for any Consumer to decide if this Service suitable for him/her, i.e. can satisfy the needs.
   
   Service Contracts are explicit contracts between the Provider and every of its Consumers. The to-be standard allows inclusion of both Provider's and Consumer's policies in to the Service Contract. In general, the Service Contract may contain just a sub-set of the functional, non-functional features of the Service and related sub-set of the policies.
   
   However, after the Service is built, a Consumer can offer just its policies to be added to the Service Contract; the latter is driven and approved/supported only by Provider. If a Consumer does not like the Service Description, it should not use the service. If a Provider is interested in wider Service consumption, it will listen to the Consumer needs. Otherwise, it is an open market - do not like, do not take.
   
   - Michael Poulin

   Reply

2. Back to top

   Great Ideas

   by Colin Jack

   Great stuff, I can definitely see the benefits of such an approach.

   Reply

• Older >