Internet World: The ABCs of XMLMar 12, 2000, 16:26 (0 Talkback[s])
(Other stories by James C. Luh)
By James C. Luh, Internet World
You can scarcely attend an industry conference or read a product brochure these days without hearing about XML. Still, while many recognize XML's potential for turbocharging business integration and data exchange, technologists and business customers are just beginning to understand what the buzzwords mean, and where XML can and can't be used. One area of great excitement-but not a great deal of agreement-is distributed computing over XML. An XML-based middleware protocol could let applications access distributed objects across the Web, or serve as an integration layer linking applications based on competing technologies, such as Microsoft's COM (Component Object Model) or the Object Management Group's CORBA (Common Object Request Broker Architecture).
XML's suitability for inter-application communication derives from its flexibility. XML, the World Wide Web Consortium's eXtensible Markup Language, provides a versatile framework for creating specialized HTML-like languages that can be used for applications other than Web pages. XML "vocabularies" allow data to be precisely marked so a computer can read and identify specific data in a document and interpret their significance. That means, for example, that disparate computer systems can exchange and process XML-formatted purchase orders and invoices with little intervention by humans.
Computers don't need to communicate in whole documents. Developers can use XML for distributed computing by using XML to encode smaller units of complex data along with instructions on what to do with the data.
The proposal that's attracted the most attention is the Simple Object Access Protocol (SOAP), whose authors include Don Box of DevelopMentor, Dave Winer of Userland Software, and several Microsoft representatives. SOAP's authors have submitted the protocol to the Internet Engineering Task Force (IETF) as an Internet-Draft.
SOAP defines a protocol that lets applications communicate using HTTP and XML. It's designed to support multiple platforms, languages, and object models, and to be easy to implement quickly. XML isn't tied to any one platform, so SOAP can be used as a lingua franca to link differently architected systems, be they CORBA applications running on Unix machines, COM applications on Windows, or Perl scripts running on an aging Mac SE/30.
SOAP surely has proven easy to implement. Some SOAP code is already available for Perl, COM, and Java, and several CORBA vendors have promised support in the future. Yet support for SOAP is far from universal. Some are wary that Microsoft is backing SOAP as part of a hidden strategy to dominate the market. John Montgomery, a product manager in Microsoft's developer group, says the fears are unwarranted, and that many outside Microsoft's stable of close partners have participated in SOAP.
Apart from its corporate backing, there are technical concerns about SOAP and similar proposals. Some of the greatest advantages of SOAP and its cousins can also be seen as flaws. For one, SOAP works over HTTP, the protocol used most widely for making Web page requests. That means SOAP traffic is compatible with much of today's existing Web infrastructure. Critics claim, though, that this amounts to disguising distributed computing calls as ordinary Web-request traffic.
Many are concerned that HTTP is less than ideal for carrying RPC (Remote Procedure Call) traffic, says Rob Weltman of Netscape (speaking as an individual, not for the company). There are also security issues raised by routing such traffic over port 80, the port usually designated for Web traffic.
SOAP's basis in XML means developers can get SOAP applications off the ground quickly by reusing existing text-processing and XML code. Yet some maintain that encoding data in a text-based format wastes more processing power and bandwidth than binary inter-application protocols. In defense, Montgomery points out that much of the data one would pass over a SOAP link is text data that must be processed somewhere along the line anyway.
All of the disagreements about XML-based RPC tie into a more fundamental problem, according to Michael Condry, director of Internet and embedded standards at Sun Microsystems. Condry believes some XML technologists have put the cart before the horse, attempting to define a protocol before clearly defining the applications where XML-based RPC is the best solution.
Still, Condry believes there is a role for an XML-based RPC protocol. A preliminary discussion scheduled for IETF's March meeting could lead to the creation of a working group to develop a standard.
Others are even less enthusiastic about using XML on the protocol level.
"We see XML as a great way of packaging data," says Richard Soley, chairman and CEO of the Object Management Group, which promotes CORBA. The OMG has done some work to enable CORBA applications to use XML data, but Soley has reservations about using XML in the actual communication protocol. He maintains it's smarter to pass XML data over binary protocols such as OMG's Internet Inter-Orb Protocol (IIOP).
Nevertheless, Soley admits that many of OMG's customers have expressed interest in XML-based RPC. If that interest persists, OMG will not be considering whether to get involved, but how.
"If customers want it, that's what we'll do," Soley says.