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.