XML First
It is actually much easier to make an uninteroperable Web service if one starts with the service contract instead of with object oriented code. The reason for this is quite simple and one I’ve harped on several times in the past; the impedance mismatch between XSD and objects is quite significant. There are several constructs in W3C XML Schema which simply have no counterpart in traditional object oriented languages which cause current XML Web service toolkits to barf when consuming them.
The problem then, to my mind, seems to be not in the approach, but in the toolkits. And not in the fact that they’re not serializing perfectly, just that serialization in itself is simply a bad idea.
Taking XML out of Web services, or conceptually ignoring it, turns them into a bad version of CORBA or DCOM. This seems to be like combining the disadvantages of both with the most bloated syntax imaginable.
I think it’s important to distinguish two aspects of “XML” that seem to be tangled up in this nest of posts (Ewald, Visoski, Obasanjo, …). There’s XML the data interchange and object serialization format, and there’s XML Schema Definition Language, a “contract” interchange language and tool import/export format.
I’m understanding Dare to be saying that XML as a data interchange format is a fine idea, [I’d add, except maybe for the efficiency issue that is being address in all sorts of creative ways]. It’s the primacy of XSDL that is considerably more problematic, for the reasons Dare mentions in http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=755443c2-19a6-4b45-8e18-879565e74759
So the question is, are real developers better off fitting the XML stuff into the constraints of their programming environment (objects first), or better off adapting their programming tools/skills to the messier realities of XML? (XML first) In the long run, the languages and tools will probably move toward something a middle ground between RESTful POX and “CORBA with angle brackets”, and hopefully the XML specs will evolve or be profiled to be less gratuitously incompatible with programming languages. In the short run, objects first seems a lot more pragmatic and less frustrating for developers who are more interested in getting their work done than breaking new ground.
I don’t think this is a contract (meta) discussion only. XML, or the XML InfoSet, in fact the conceptual model of self-descriptive messages, is what makes WS different from CORBA with angle brackets. The fact that you need a contract when you want to do typed stubs/skeletons doesn’t mean that you shouldn’t have one when you do messaging (although if forced to, I’d drop WSDL much more easily from my toolset than SOAP).
Until the tooling to build WSDL contracts becomes much better than it is today, though, I agree that we have to take a pragmatic road. And that is probably to start with the programming language, generate WSDL from there, and manually tweak it to fit one’s interop requirements. Unless - and that would be my preferred choice - there is an existing XML business vocabulary that can be used …