Does XML Need Corba?
By Rachel Chalmers 
September 24, 1999

With the Object Management Group (OMG) and the Organization for the Advancement of Structured Information Standards (OASIS) now each other's greatest fans and working together to integrate XML with Corba, the only question that remains is whether it should be done at all. Spearheaded by Dave Winer, CEO of UserLand Software Inc, one group has come up with a way to use XML to bypass Corba altogether. They call it XML-RPC (for remote procedure calling). In July 1999, Digital Creations Inc made its Zope content management system interoperable with UserLand's Frontier through XML-RPC. Earlier this week, no less a behemoth than Microsoft Corp threw its weight behind the standard. 

Since XML is renowned for its simplicity, human-readability and flexibility, and since Corba, to put it mildly, is not, surely the old standard can now be quietly put to sleep? Actually, no.  XML expert Tim Bray, a co-editor of the World Wide Web Consortium (W3C) XML Specification, says of XML-RPC: "Obviously it is immensely simpler than Corba and obviously for the same reasons, it does less for you. But the fact that it's easy to read and simple to implement might mean it wins anyway." To him, that would be something of a Pyrrhic victory. "With Corba you can set up a persistent connection, send requests back and forth and maintain the transaction state," Bray explains. "With XML-RPC I send you a request, you send me a response and that's it. It's stateless by design." 

The truth is that both could have their place. "What it depends on is the trade-off between how fully-featured a solution you want and how much work you're willing to put in," says Bray. "If you just need to get something simple and straightforward running in a couple of weeks, that might be a job for XML-RPC." OMG's VP of technology Andrew Watson is less sanguine about XML-RPC. "I'm very much in favor of the things XML is trying to achieve and what the XML designers had in mind for XML and this is not one of them," he states. "This is not an idea that's got legs. It really is using XML for something it's not designed for." Like Bray, Watson rests his argument on the fundamental limitations of XML. It doesn't have support for transactions, security, session management or long-term association of client with state at the server end. "This is really what objects are about," he says. He concedes that the idea of using human-readable XML to debug a protocol is appealing, "but I come back to this idea that every problem has a solution that is intuitive, appealing and wrong." 

The answer seems to be to make XML and Corba interoperable, as the OMG and OASIS are now trying to do. "There's a word the computer scientists use to describe something like XML," Watson explains. "That word is idempotent. It means that the effect of doing something more than once is the same as the effect of doing it once." However many times you read your bank balance, for example, the mere act of reading it won't change it. "But it you're doing something like sending a debit instruction or an order, it does matter if you send it more than once," Watson continues. Idempotency is XML's strength and its greatest weakness. If you're shipping information around that's idempotent, XML is perfectly functional (and as a bonus, human-readable). In applications where computers are talking to each other and interactions are not intended to be human-readable, XML is probably not the optimal choice. 

"We very much see them as being complementary technologies," Watson says. "That's why we're keen on integrating them." The new partnership between OASIS and the OMG should mean that application developers will find it easier to carry XML as the payload of Corba interactions. As a result, middle-tier applications that use Corba for the heterogeneous enterprise systems at the back-end and XML as a universal web interface are likely to become more common. "When our vertical groups in the OMG are doing this kind of work, they might well find themselves specifying in Corba for robustness, security and efficiency and referencing DTDs and specs maintained by for the customer interaction parts," Watson concludes. "Our job is to make this kind of thing easy if the membership wants to do it." It seems likely that they will.


reprinted with permission of Computerwire, Inc.,  Copyright 1999 Computerwire