Remembering the Future

But unfortunately, it gets worse.

I've come to recognize that we're still looking to XSD and WSDL to be a sort of "IDL for interoperability", and the problem is that both Schema and WSDL allow for things to be defined that don't fit our existing programming languages. Facets on schema types, in particular, create a particular brand of Hell for the Schema-to-class automatic translators, and fact is, most tools (xsd.exe and all of the Java-based toolkits I've tried thus far) basically punt on them. Which leads us to a nasty discipline problem all over again: Not only do you have to be disciplined enough to avoid the styles or notions or idioms of a particular programming language into your service, but you have to be disciplined enough to avoid the styles or notions or idioms of the wire-level representation, as well, or the consumers of the message on both sides will find it awkward to work with.

How do we avoid this? At the moment, there's less concern for the latter than the former, but as people start to go with a more "contract-first" approach, we either have to bury the angle brackets behind a subset of what schema can offer (and thereby piss off the angle-brackety crowd), or else we have to just publish mounds of texts and patterns [1] to describe to people what to avoid and when.

Neither one sounds truly appealing, which leaves a third option, one far more radical but infinitely more satisfying: just ratify and stamp with approval the current programming practices, and introduce XML and schema types as first-class citizens into our programming languages.

Dare Obasanjo

It is actually much easier to make an uninteroperable Web service if one starts with the service contract instead of with object oriented code. The reason for this is quite simple and one I've harped on several times in the past; the impedance mismatch between XSD and objects is quite significant. There are several constructs in W3C XML Schema which simply have no counterpart in traditional object oriented languages which cause current XML Web service toolkits to barf when consuming them. For example, the XmlSerializer class in the .NET Framework supports about half the constructs in W3C XML Schema. Most XML Web Service toolkits support a similar number [but different set] of features of W3C XML Schema.

. . .

This isn't theoretical, more than once while I was the program manager for XML Schema technologies in the .NET Framework I had to take conference calls with customers who'd been converted to the 'contract first' religion only to find out that toolkits simply couldn't handle a lot of the constructs they were putting in their schemas.Those conversations were never easy.

. . .

The main thing people fail to realize when they go down the 'contract first' route is that it is quite likely that they have also gone down the 'XML first' route which most of them don't actually want to take. Folks like Tim Ewald don't mind the fact that sometimes going 'contract first' may mean they can't use traditional XML Web Service toolkits but instead have to resort to SAX, DOM and XSLT. However for many XML Web Service developers this is actually a problem instead of a solution.

Ted Neward

As for me, I'm talking about Effective Enterprise Java again, but also some new .NET taks on Indigo and C-Omega, among others. I'm looking forward to both a lot, particularly C-omega, since I think XML and relational integration into the language is the Next Big Thing for programming languages; should draw some interesting comparisons to Groovy.

Topics: Contract First | C-Omega