Mike Davis's Weblog A blog of what I'm learning and thinking as I go through my days at Sun.

Consumer Driven Contracts for SOA

I work in Customer Network Services, a group in the Software organization at Sun. The team that I lead is tasked with developing "Common Components and Services" for the rest of our organization. One of the things that we have been struggling with (among many other struggles) is defining common, reusable services that are easily extensible without breaking all of the clients that are using them. Of course, in order to know if you are going to break the clients that are using the service, you first have to know who is using the service and how they are using it. We have a relatively large organization, and although we work closely with each team integrating with our common services, we have quickly lost track of all the ways that teams have integrated with our services. Short of digging through all of the code over the past 2 years, we have no way of finding out either. So, how do we fix this going forward for the new services that we are building? That's what I've been trying to figure out lately.

I was reading an interesting paper today by Ian Robinson titled "Consumer-Driven Contracts: A Service Evolution Pattern" that proposes something so simple, yet is a radical shift to how we develop services within our group now. "The underlying assumption here is that services, by themselves, are of no value to the business; their value is in being consumed. By specifying services closer to where they are being used - by consumers - we aim to exploit business value in a lean, just-in-time fashion." [Robinson]. Makes sense. The idea behind consumer driven contracts for a service oriented architecture is to let the consumer of a service define the contract for the service that the producer publishes. That seems like just basic common sense. But, not only in my current team, but in numerous projects across Sun and in my past, I see the service producer attempting to create this perfectly reusable service by abstracting everyone's requirements into something that isn't capable of evolving without even the most minor modifications breaking everyone. We keep coming up with service versioning strategies that never seem to work as well as we hope, and that is primarily because we are unable to clearly articulate the exact dependencies that are on a service so we are unable to determine what it means to be backward compatible.

In order to get us moving in the right direction, I am proposing that we begin to follow a consumer driven contract approach for our service definitions. As Ian notes in his paper, this won't solve our evolutionary problems, but it will allow us to understand how we can evolve our service. That is one better than we have now. Not only does this allow us to understand the dependencies on our services better, but it also helps us to better focus our services on providing business value. Instead of driving towards the ideal of Reuse Based Software Engineering we should be focusing our efforts on providing tangible value.

We currently have a reusable asset library which documents all of our services and components. I plan to add a section to each service for the consumer driven contract. This will document:

1. the consumers of the service;
2. what functions and elements (the schema use and interface use) that the consumer is using;
3. specific conversational state expected by consumers;
4. and finally policies and quality of service needs of each consumer.

Bibliography

• Robinson, Ian. Martin Fowler's Blog. 12 Jun. 2006. Thought Works. 16 Jun. 2006. http://martinfowler.com/articles/consumerDrivenContracts.html