Is There a Consensus Web Services Stack?
February 12, 2003
Hegel says somewhere that all great events and personalities in world history reappear in one fashion or another. He forgot to add: the first time as tragedy, the second as farce. -- Karl Marx, The Eighteenth Brumaire of Louis Bonaparte
What Marx said of world history -- that it occurs the first time as tragedy, the second as farce -- is increasingly true of conversations in the XML development community. Conversation among XML developers has grown increasingly ossified. Permanent topics of conversation return -- never, it appears, to be fully repressed -- over and over: the ins and outs of namespaces, the nature of resources and representations, why SOAP is sweetness-and-light or pure evil, the ideal simplifying refactor of XML itself, and so on. And, each time the cycle repeats itself, the positions grow more shrill, more caricatured, and less interesting. It's possible that someone will eventually learn something from all of this; more likely, people give up the hope of learning something and stop paying attention.
The lucky journalist, whose job it is to cover these conversations, has one of two options: either mine the ossified flows of information for the occasional nugget or get things so wrong that the community is roused to fury by sheer (perhaps even intentional) incompetence. In this week's column, I maintain my hopes of steering toward the former option and away from the latter.
A Short Stack or Tall?
The web services "stack" is a semimythical creature, composed in equal parts of technical specification, running code, and marketing campaign. Since the global IT budgetary funk is unlikely to brighten during 2003 (or even 2004), the proliferation of web services specifications and technologies is as much wishful thinking as it is anything else. It is fairly uncontroversial that the core of the web services stack rests on the Internet infrastructure (TCP/IP, HTTP, and, arguably, URIs), followed by the XML layer, the SOAP layer, and the WSDL layer.
Even though the composition of this segment of the web services stack reflects a rough industry consensus, that doesn't mean it necessarily works. Several people have reported interoperability problems in the SOAP-WSDL layers. As Don Box said, "many interop problems are a result of various stacks...trying to mask the existence of XML altogether. That combined with a WSDL specification (1.1) that invented far more than it needed to has made life harder than would otherwise be necessary." In short, even with a rough consensus, interoperation can be messy across different implementations of the web services stack; this is the case, in part, because people still aren't sure whether XML is a data model, just a syntax, or both. And so various groups try to bury XML beneath WSDL layers of, as Don Box said, "goop".
After that, things get even trickier. Where does UDDI go? And, more to the point, what are its chances of success? Does the world really need -- to use Don Box's pithy explanation of UDDI, an "RDF-esque version of LDAP over SOAP"? As Paul Brown put it, "'free love' on the business internet is a long way off". Microsoft, for one, has a rather wild and woolly welter of high-level elements in the web services stack: coordination, inspection, referral, routing, policy, transaction.
What about the various, competing service coordination specifications: BPEL, BTP, WSCI, and on it goes. Again, Paul Brown said it best, "The answer to the question 'Is there a royalty-free specification of web services choreography that legitimately combines and acknowledges the established body of knowledge on long-running transaction models, business process semantics, and cross-domain implementation realities?' is 'No.'"
Another Turn in the Patent Wars
Moving from the ridiculous to the sublimely ridiculous, it was reported that Microsoft has applied for a wide-ranging patent for many of its .NET APIs, including XML. The patent claims that Microsoft has developed "a software architecture for a distributed computing system comprising: an application configured to handle requests submitted by remote devices over a network; and an [API] to present functions used by the application to access network and computing resources of the distributed computing system".
As is often the case in these cases, Microsoft's goal is probably to keep up with IBM, the patent wars being a kind of ghostly analogue of the Cold War's arms race. As for obvious prior art, Rich Salz opined that "[i]t seems pretty obvious that OSF DCE...[is] prior art that invalidate[s]" Microsoft's primary patentable claim. OSF DCE had, in Salz's view, "several APIs that were 'transparently remote'".
While it is certainly important that the existence of prior art be communicated to the USPTO, Microsoft is likely to be aiming this patent at IBM rather than at, say, Mono or the free software community in general. Despite Microsoft recently admitting, in SEC filings, that free software could negatively impact its financial position, the mutually defensive patent struggle with IBM is not to be overlooked.
Dennis Sosnoski put the matter this way: "The open source world looks especially vulnerable to this type of ploy, since there's no single entity that's likely to step up and bear the legal load if companies start making claims against open source programs. On the other side, it's very difficult for a small company to collect on valid patents being violated by large corporation for the same reason".
Free software communities are at risk in principle, which makes it all the more surprising that none of the big companies have used patents offensively against them yet. If that is what actually motivates these patent applications, what is Microsoft, for example, waiting for? Free software developers and users should have learned by now that, jokes about Bill Gates and the devil to the contrary, neither IBM nor Microsoft have any inherent interest in avoiding doing harm to free software.
|
|
|
Also in XML-Deviant |
|
The only reason Microsoft patents are more troublesome now is because Microsoft hasn't bet on free software in the way IBM has done. Thus, it's hard to imagine that IBM would use the patent system as a way to harm free software. Not only because IBM makes serious revenue from its patents (and has since well before anyone thought of free software as an economic threat), which provides a more likely motivation for its unending patent barrage, but IBM has also bet a serious slice of its business on free software, which includes its ability to work with free software developers. It's far more likely that IBM would use its legal resources to defend against patent moves designed to harm free software, since such moves could seriously imperil its own business.
Having set out to find something new to report, I was drawn to two classic topics of discussion in the XML development community, web services and patents. Giving the journalists something new to talk about isn't motivation enough for anyone to break new XML ground, but would it kill ya?