Internet World: The ABCs of XML

By James C. Luh, Internet

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

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

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.