Dare on problems with mainstream Web services

"Can XML Web Services Move Beyond the Twin Burdens of XSD and WSDL?" "There is no Substitute for Good Documentation"

Dare discusses how "XML Web Services and how the technologies have been handicapped by the complexities of the W3C's XML Schema Definition Language (XSD) and Microsoft & IBM's Web Service Definition Language (WSDL)." Yes, some of us have been complaining about this for years. Dare has always helped point out where his experience corroborates or counters some of our warnings. His perspective is extremely valuable because he has thousands of customers that he just needs to find a way to make happy. From that perspective, it looks gloomier than ever for mainstream Web services.

These are definitely interesting times for XML Web Services. The complexity of the technologies that form the foundations of SOA is now pretty much acknowledged across the industry. At the same time more and more people are taking the idea of building web services using REST very seriously. I suspect that there might be an opportunity here for Microsoft to miss the boat if we aren't careful.

Well, at least MS has one prominent voice trying to prevent that, but it still has several other prominent voices lubricated with Web services kool-aid, one of which commented on Dare's posting (although I'm not sure I can make out just what he was saying). In another comment, Dave Megginson, always a good one to listen to, said:

I'm still puzzled that so many people missed the simplest lesson of XML's success: we did away with mandatory DTDs, and suddenly everyone was excited about using markup. Perhaps the WS-* people could apply the same idea to WSDL, XSD, and friends.

Dare quotes from Tim Ewald:

In many cases, developers start using POX over HTTP to build systems. When people want to re-purpose those services, its hard because they don't have a lot of information about what message formats and exchange patterns they support. In many cases there is no documentation for that, other than the code and, in that sense, those systems are closed. XSD and WSDL help open them up by providing metadata about what those services do. In some cases that metadata is also useful for finding services that do interesting things. For many of our customers, that is the reason they are migrating from existing POX over HTTP systems to SOAP-based Web services.

I'm surprised at the idea that many of anyone's customers have existing Plain ol' XML (POX) over HTTP systems, and very suspicious of the claim that people who did have one in place and working are looking to spend a lot of resources migrating to SOAP/WSDL. Dare responds:

...I wouldn't consider an XSD or WSDL file as being sufficient documentation [for either internal or external web services]. They are definitely better than nothing but they are a far cry from providing enough metadata for users of a service to determine how to properly interact with a service especially when dealing with operations that have to be performed in a series of steps (e.g. uploading a photo or enclosure to a user's home directory then attaching it to a subsequent blog entry).

Right, although no one should take this as excuse for why we have the WS description stack from hell: "business process", "business activity", "coordination", "experience", "choreography", "policy framework", "eventing" (we should find whoever came up with that ghastly usage, and put them on the gibbet), etc. Cue Sean McGrath on WS- YouGottaBekiddingMe (and people say CORBA was complex). This is all hard stuff, but there is also a lot of hair-splitting and redundancy between the mountain of WS specs, and the REST crowd can easily come up with simpler and fewer description languages if they aren't overcome by politics and bloated committees as the WS space has been. Dare again, with the crux:

If your organization is having problems with poorly documented internal services then the answer is to document them NOT to rely on WSDL & XSD files as documentation.

Nuff said.

[Uche Ogbuji]

via Copia