The Eighty-Twenty Solution

I've been working on a Web Services project for 2 1/2 years now. Early on, we made a couple of key architectural decisions: we were going to use document / literal and we were going to use Xml elements to transmit opaque XML fragments, as opposed to using strings or base64. (Our services make use of a lower level XML API for accessing our mainframe system, which is why we're throwing around XML in SOAP messages). The first decision has been a source of interop problems all along, as a number of SOAP toolkits still don't support doc/lit, and customers tend to see this as our problem and not their toolkit vendor's problem. There's usually a way around that, most of these toolkits have a COM interface, so I recommend something like PocketSOAP to them. This year, management instituted an architectural review, and the latter decision is now being questioned. Specifically, we have a number of people insisting that we're wasting too much time parsing XML into a DOM and that a string encoding would be more efficient. That's a sore point with me, because I feel strongly that we did the right thing: entity encoding or wrapping in CDATA costs parsing time on both sides of the wire, and the wire format is fatter, especially if you use entitiy encoding. It's true that our implementations on both sides of the wire are naive: the XML parameters are parsed into a DOM, even though that's not really necessary. I did benchmark both the string approach and the naive XML Element approach when the decision was made and even though Elements were 10% slower, I decided that we could always optimize. We never did the optimization, and the people doing the review just see the performance hit and reflexively insist on changing the interface contract.

The key issue here is that it's not difficult to put XML on the wire, but the SOAP libraries, specifically the WSDL code generators used to generate the endpoints usually make it difficult to do efficiently. We all know that a DOM is expensive, so why do WSDL generators marshal to a DOM by default? Part of it is that there's a mindset that XML on the wire has to marshalled to objects, and if you're given <xsd:any>, Element is the most convenient object. I've burned a lot of energy trying to get people out of that mindset, but the tools at hand today don't make it easy to make that argument.

Related to today's previous post, I saw Dare responding to a post by Daniel Cazzulino, which generated its own response. Dare concludes that the CLR type system maps well onto XSD, but not the other way round. Daniel responds that "Dare is probably ignoring that most developers are .NET DEVELOPERS, NOT XML theorists and WXS fans".

Now, I'm no Ph.D, and no type theory expert (and I'm not especially fond of WXS, but it seems to me that a lot of developers get confused talking about typing, because they ignore a couple of basic things:

1. A fundametal concept in OO is binding behavior to data.
2. XML is about data, not behavior, i.e. it's syntax, not semantics.

In Daniel's original article, he uses the example of a Person construct that extension types Employee and Customer, arguing that they should map into an abstract Person class, and concrete Employee and Customer subclasses, and can therefore go into an array of Person objects. If all you want to do is hold employees and customers in the same bag, great, the serializer has solved a problem for you. But ask yourself, do Employee and Customer pass the IS-A test? Including behavior? So, are you really passing objects in XML, or is it just data? So maybe the inheritance model works for the data in the objects, but not the behavior? Modeling the real world in types is hard, that's why Ph.Ds like to work on it.

Let's take a favorite example of mine from a domain I'm familiar with. The IATA defines a few thousand codes corresponding to airports, for example JFK or EWR. There's also a semi-official list of codes corresponding to cities, such as NYC. These codes are all 3 uppercase alphabetic characters. So the following definition is useful from a validation standpoint:

<xs:simpleType name="LocationCode">
  <xs:restriction base="xs:string">
      <xs:pattern value="[A-Z]{3}" />
  </xs:restriction>
</xs:simpleType>

So this is a real world example of what Dare's talking about, derivation by restriction is a very useful concept. The real world solution is that in an environment that can't cleanly support those concepts, you discard them and just use strings (that's what XSD would do), or take them out of band (by separation validation logic from the type being marshalled).

Here's the "real world" as I see it: when using XML for data interchange, the programmer at the other end of the wire probably doesn't share your object model. My employer has at least 2 web service customers using Perl, at least one using PowerBuilder, and one using something called MUMPS. But XSD is what we have to provide a data definition, and somehow they make it work. As a real philosopher would put it:

It is a ridiculous demand which England and America make, that you shall speak so that they can understand you. Neither men nor toadstools grow so. As if that were important, and there were not enough to understand you without them. As if Nature could support but one order of understandings...