I spent half of last week at a conference where I answered the same question many, many times. To paraphrase: Why is it so hard to expose arbitrary object models via Web services? The answer is simply that Web services are not built on an object technology, they are built on XML.

Many people have commented on the relationship between objects and XML. Chris believes that until XML APIs become as easy to use as strongly typed object models, XML will not be widely adopted by developers at large. Don points out that whether you want to map XML to objects is your own affair, the beauty of the Web service world is that what you do behind the closed doors of your process is up to you.

I agree with Don, but I also believe that the real power of Web services will only be realized when people embrace XML as a data representation throughout their systems. Let me give you and example. Suppose you want to write an application that consumes data from four different Web services that do essentially the same thing (it doesn't matter what it is). In some Utopian world, all four of those services would use the same industry-standard XSD data types and WSDL portTypes. However, in reality, this is unlikely. The track record for defining cross-industry (I think that is horizontal, but I always confuse the orientation of markets on the Cartesian Plane ;-) standards for things like customer information is not very good. While it seems like this should be easy - a customer is a customer, right? - there typically turn out to be a lot of differences that can't readily be overcome. Even within a single industry (vertical markets, I believe), it is unlikely that everyone will agree. This is why technologies like BizTalk exist.

So, assuming the four services you are using do NOT use the same XSD and WSDL types, you have to do some work to normalize the information they provide into some common internal representation. Doing this work solely with objects, that is, by traversing the four different object models your Web service toolkit generated for you and building an equivalent object model in your preferred format, will be painful indeed. This is exactly the sort of problem that the XML technology suite is designed to solve. Think XSLT or XML Query.

This does not mean that XML would never be translated to objects, but it does mean that having that as your only XML programming model is quite limiting. Unless you merge the world of objects and the world of XML. .NET's XmlReader and XmlDocument are 2nd-generation implementations of 1st-generation XML APIs. They are really good, but we can do better. Theoretically, there is not reason that we could not create a programming model that presented information as objects without losing its "XML-ness", so that you could use XSLT to map one object model to another. However, we don't have that today, so what should we do? For me, the answer is clear. I'd like to always use objects, but not if the price is giving up on the XML toolset I know and love. The potential of XML-centric processing is too great to be ignored and I am dedicated to exploring it in detail.

Of course, to focus on XML, you have to know how to use it. Optimally, everyone would. At the very least, I believe it is required to get anything practical done in the Web services space. I'm sure some people will roll their eyes at that and wonder if I write all my code in assembler. After all, as many have observed to me, when you use DCOM you don't care about the format of data on the wire. That may be true, but there are not 40 some odd implementations of DCOM hoping to interoperate based solely on SOAP messages and WSDL/XSD descriptions, all of which require XML.

Many have observed that using XML "in the raw" is too difficult - things need to be easier and that's why everything should map to objects. I find this argument ironic. There are legions of developers who are used to programming with Recordsets - is that really so different from DOMs? They are also used to writing ASP(.NET) pages that emit raw HTML - is that really so different from raw XML? Going forward, will turning everything into objects really make developers' jobs easier?

Maybe, maybe not. In the meantime, I'm going the XML way to see how it turns out. I'll talk about it here.