Clemens has a pretty interesting post (as usual) on his recent XML is the assembly language of Web 2.0 entry. He makes a good point that the WS-* stack has grown so complicated that it's pretty hard for humans to directly grok at the XML level (i.e. at the message level), and I totally agree and been saying the same for a couple of years now.
However, I think Clemens misses the mark here. He argues that XML is hard and complex. Well, I say it isn't, not really. See, WSDL, Policyt, WS-AT, and even WCF config are not XML. They are languages written in (or generators of) XML, but they are not XML. They are hard, XML isn't. XSD is hard, no comment there, but even so, XSD isn't XML either. The thing is: We created this complicated beasts and monsters and had them to be written on XML, but the truth of the matter is that some of these are so complicated, they would've looked complicated regardless of the language used to express them.
All this means that it's the WS-* stack that's screwed up (i.e. it's too complicated for mere mortals to grok). It really doesn't say anything about XML per-se. At least that's my opinion.
Clemens also argues that now everything in the WS-* stack is way too important to miss, and also that it's beyond any solution builder's ability to write correct and interoperable contracts: "Just as there were days that all you needed was assembly and INT21h to
write a DOS program (yikes) or knowledge of "C" alongside stdio.h and
fellows to write anything for everthing, things are changing now in the
same way in Web Services land. Command of XSD and WSDL is no longer
sufficient, all the other stuff is just as important to make things
work.". I'm strongly opposed to this state of things.
For one thing, there is a whole lot of power and things you can do using what I'll now call "Plan Old Web Services (POWS)". And I'm sorry to say, but many people (me included), have built perfectly usable, interoperable and simple solutions using these technologies and hand-crafting our service contracts. Let me be clear on this: Hand-crafting your contracts is not about writing your own XSD/XML (though you can) or whatever. It's about carefully thinking about the messages you are going to exchange, their meaning and structure. Many of us like to write sample XML or XSD alongside to make it easier to visualize, but that's just a tool.
I happen to agree with Clemens that interoperability is hard, but on the current WS stacks I've used, I'd say this was somewhat better as long as you didn't let yourself become too fancy with XSD. The main problems with interoperability I've had using POWS actually comes from datatype representation, and not XSD itself (since as a good boy I restricted myself to a very narrow set of features), and I don't see WCF helping with that at all. I think it is a very good thing that the WCF team decided to severely restrict by default how creative you could get with contract descriptions and what kind of XSD constructs you could use. That said, I think they were a bit overzealous on their work and restricted it a little too much. No Attributes? That alone makes me want to avoid using DataContracts and revert to good old trusty XmlSerializer.
As it turns out, however, now that we finally have fairly interoperable POWS, we come up with something else to spice the mix: The rest of the WS-* stack. If you're using WS-* features, you are in for another, wonderfully new set of interoperability problems, that have nothing at all to do with XML or XSD being complex. You'll meet new and extraordinary animals like incompatible WS-Addressing implementations, multiple and incompatible WS-Security revisions, complex XML canonization rules. Those are real interoperability problems, I've fought them out in the field. And guess what: They are not going to go away magically because you're using WCF. WCF will make things easier with improve implementations (and hopefully standard-compliant ones), but let's face it: The real interoperability problem are the specifications themselves.
Given the state of things, and how the WS platform is slowly, but surely, becoming a place where the human eye is no longer welcome, I can't help but ask myself "are we really any better on it that on a purely binary platform like DCOM?" That would surely be a shame...
