Yesterday, Mark Baker asked Why all the WS Interop problems?.
If you'd have asked me six or seven years ago - when this whole Web services
things was kicking off - how things were likely to go with them, I would have
said - and indeed, have said many times since - that they would fail to see
widespread use on the Internet, as their architecture is only suitable for use
under a single
adminstrator, i.e. behind a firewall. But if you'd asked me if I would have
thought that there'd be this much trouble with
basic interoperability of foundational specifications, I would have said, no, I
wouldn't expect that. I mean, despite the architectural shortcomings, the job of
developing interoperable specifications, while obviously difficult, wouldn't be
any more difficult because of these shortcomings... would it?
In my opinion, the answer to his question is obvious. A few months ago I wrote in my post The
Perils of Premature Standardization: Attention Data and OPML that
I used be the program manager responsible for a number of XML technologies in
the .NET Framework while I was on the XML team at Microsoft. The technology I
spent the most time working with was the XML Schema Definition Language
(XSD). After working with XSD for about three years, I came to the
conclusion that XSD has held back the proliferation and advancement of XML
technologies by about two or three years. The lack of adoption of web services
technologies like SOAP and WSDL on the world wide web is primarily due to the
complexity of XSD.
If you read the three posts that Mark Baker links to about SOAP
interop problems, you'll notice that two of them are about the issues
minOccurs="0" to concepts in traditional object oriented programming languages [specifically C#]. If a value is null does that map to
minOccurs="0"? How do I differentiate the two in a programming language that doesn't have these concepts? How do I represent
xsi:nil in a programming language where primitive types such as integers can't be null?
The main problem with WS-* interop is that vendors decided to treat it
as a distributed object programming technology but based it on a data
typing language (i.e. XSD) which does not map at all well with
traditional object oriented programming languages. On the other hand,
if you look at other XML-Web-Services-as distributed-objects
technology like XML-RPC,
you don't see as many issues. This is because XML-RPC was meant to map
cleanly to traditional object oriented programming languages.
Unfortunately I don't see the situation improving anytime soon unless something drastic is done.