I think this is a great illustration of tailoring solutions to real consumer needs, which is the primary driver behind consumer-driven contracts. As a provider it may not be possible to offer a one-size-fits-all solution that meets the needs of each and every consumer – so specialize on a case-by-case basis, but in each case do “just enough” to meet real as opposed to imagined needs. Or, and this was the first motivation for CDC, if you do have to provide a one-size-fits-all contract, fit the identifiable aggregate needs, and nothing more.

When I started with CDC, it was for me really about creating and maintaining message schemas that matched the aggregate needs of several consumers – that is, a one-size-fits-all schema, but nothing gold-plated, just something with no more and no less than what was needed. We communicated consumer expectations using tests and assertions – XPath, Schematron, and more recently a representation-format-agnostic DSL (ie. expectations in this DSL can be transformed into assertions against XML, JSON, YAML, form-encoded name-value pairs, etc). By having consumer teams give these assertions and tests to provider teams, we helped providers build into their own test suites and continuous integration environments an understanding of how their services were actually being used. If tests were kept up-to-date, teams could then track their schema footprint and identify possibly redundant elements. Where we were able to do this early enough in the service development lifecycle, these programmatic expectations helped drive out a service contract “by example”.

So I guess CDC started out as a way to help the one-size-fits-all mentality do the simplest thing that could possibly work, whilst at the same time providing a basis for evolving a service as new expectations and consumer needs were identified and came online. I’m always on the lookout for practices and techniques that allow us to do just enough today – even in the context of SOA – whilst maintaining a duty of care to the overall lifetime of a system, and this seemed to help.

CDC then, in its original form was quite modest, being concerned mainly with schema and a desire to contain proliferation – ie. not stamp out consumer-specific instances of a message but instead provide a minimally complete single instance. But with experience I’ve learnt there is a case for specializing what a provider has to offer on a consumer-by-consumer basis – and I think this is an equally, if not more, interesting real-world application of the idea. I remember Jesus Rodriguez did something with the WCF LOB adapters along these lines quite some time ago. Your varying the publication rate, message size and transport per consumer is another good case in point. Inside ThoughtWorks, Jim Webber and I did something similar with a client at the beginning of the year. As with your case, it involved BI. Recognizing that BI consumers have quite different needs – and capabilities – from “transactional” consumers, we created a specialized ETL-friendly interface to our service that extended and clarified our business-meaningful service contract in line with a real-world need. As with what you describe, consumer expectations, including quality-of-service expectations, shape the service ecosystem to the problem at hand, rather than compromising the solution by adapting the problem to a narrow, ostensibly consistent but less-than-useful architectural or technical vision.

Hope this is of some help. On a more general note, your blog and articles have been enormously useful in shaping, testing and refining my own approach to delivering on SOA initiatives over the last few years. Over and against a certain 3-layer-application-architecture-blown-out-to-distributed-proportions school of SOA, your writing, together with Bill Poole’s stuff, which I think I probably found through your blog, steers a far more valuable course.

Kind regards

ian