Issues with "Contract First" Design

  • Article

Dare has a very good perspective on all things XML. In this recent post he points out that Contract-First design is not without its pitfalls, stemming from the "impedance mismatch" between XML and Objects. Who can disagree? But there are good mitigation strategies, to avoid the pitfalls. For example, follow the guidelines for designing interoperable XML Schema. If I had to sum it up succintly, it would be:

  1. Don't get too fancy. Stick to the basics. Don't get carried away with the over-elaborate bells and whistles of XML Schema. derivations, restrictions, even enumerations may not be supported by the object-to-XML binding magic for all your chosen target platforms. 
  2. Test early and often. Walk before you run. Don't assume all your schema will work before testing the various cases. For example, the xsd:date works for both Java and .NET. But a Java app can serialize a nil Date, while in .NET the xsd:date maps to System.DateTime, which is a value type. So, either you must take care to not send nil dates from Java, or you must take care in .NET to handle this case specially. 

If you already have a complex XML schema and want to design a service around it, rely on adapters or bridges to connect.

Stay practical and you'll make progress. Yes, we need to do more to help shrink the pitfalls, but even today you can get things done.