3000 words

XML as a Distributed Application Protocol:

The Technology and the Politics

Richard Deadman

It's the latest buzzword in the internet application arena; XML, the open-standards child of SGML that promises to provide platform and language neutral data encapsulation and separate application logic from application data. It's hot. It's powerful. Everyone loves it.

But isn't this exactly what CORBA already provides?

In this article we will explore why XML is so hot, show how XML can be used as a distributed computing protocol, and look at its advantages, disadvantages and appropriate uses. We will also speculate on some of the non-technical forces driving the XML phenomenon.

XML is being touted as the perfect partner for Java. Java supports the development of web-aware, platform-neutral applications while XML is a platform-neutral document description meta-language. And documents are a very old form of persistent information dating back to papyrus texts in the Nile delta. Web-centric, vendor-neutral behaviour and data. Like a web start-up, both technologies have great promise, and maybe greater hype. Small wonder that most of the XML tools that are becoming available are written in Java.

Brief Background

XML, for those just starting to pay attention, is an descendent of structured document markup languages such as Tex, troff and, quite directly, SGML. It consists of two basic parts, an optional structure definition part (Document Type Definition or DTD) and the documents that use this definition to organize their content. Think of HTML where you can add your own tags for a set of related documents to use. This allows the content and structure to be separated. A third facility, the XML Style layer, or XSL, allows presentation styles to be applied to any document of a particular flavour.

What are the advantages? Well, lets take a particular example. Suppose that presently corporate timesheets are created using an HTML editor. This is great in that the creator is free to pick the most appropriate tool on the most appropriate platform for her. As well, anyone can view the timesheets with ubiquitous technology. But how does the corporation collect the information. Humans infer the day/project information by their placement within tables, but this kind of inference is very hard for a computer application to do accurately. However powerful they may be at crunching numbers, computers are not really very smart.

XML offers the computer help. We can define XML tags that state that we are now in a day with a day number attribute, and have embedded tags in that day for each project and number of hours spent on that project. As well, we can now define multiple style-sheets for the XML document that allow payroll and managers to view the same document with different views. The advantages are two-fold: explicit structure for data manipulation and decoupling of the presentation from the data to allow for different views.

Wonderful, you say. Better structured documents than HTML can give us.

Of course, despite many predictions, XML will not cause HTML to disappear. There are just too many instances where the data being captured for presentation does not have enough "structural value" to justify the added cost of developing the DTD and XSL. Think of your average home page on the world of gum collecting. There are many cases where the information value or need for management is not sufficient to justify the cost of creating a structure and presentation layer. For these cases, HTML, with its predefined generic structure and presentation, is the logical choice. Indeed, HTML may become one of a list of predefined XML instances, as it is modified slightly to fit the XML syntax.

The Next Step

But now that we have a platform neutral document markup language, why not use it as the glue between applications. And since we are in web land here, why not use it to describe data that must be shared between distributed applications.

Microsoft has taken this approach in the definition of CDF, an XML-based channel definition format that it released in March of 1997, when PointCast and channels were all the rage. CDF defines channels and software distribution meta-information, such as logos, abstracts and modification dates. The last modification date is, for instance, an attribute string of format "yyyymmmddhhmmss" that indicates in Greenwich Mean Time when the channel was last changed. It is repeated in several elements, since XML does not support element inheritance.

Hold Your Horses

But wait a minute. Let's not pretend that XML invented platform-neutral data serialization. Since the days of DCE, frameworks have been developed for applications to exchange messages and data. The two most common examples of this to Java programmers are CORBA and RMI. They both seamlessly offer ways of moving an object tree to an application on another machine. And in many ways much better than johnny-come-lately XML. Although RMI allows for self-describing object serialization, and is the simplest to use, I will concentrate on CORBA, since RMI, while platform-neutral, requires Java on both ends of the pipe.

It would be a simple matter to define the CDF as a CORBA IDL that supports a reusable date type. In fact, DTD to IDL mapping is much simpler than IDL to DTD mapping, since DTDs only support strings.

Here's the briefest backgrounder on CORBA you're ever likely to read. Basically CORBA is an distributed object framework. It creates local proxy objects for remote objects that your code wishes to talk to. When you send the local proxy object a message, including parameters, the proxy marshals the data to the remote system, calls the same method on the remote object, and returns the result back to you. In-out parameters, remote exceptions, one-way messages, contexts, security frameworks, naming, trader, transaction and other services also exist, of course.

The magic of CORBA is that your client can be a Java applet running on a linux PC sending messages to objects in a Smalltalk application on a Solaris server. And the parameters can be basic types (int, String, float, etc.) or any object whose class has an IDL structure mapping. What is IDL? Just as XML allows for a DTD to share the structure of the tag sets, the Interface Definition Language is the language neutral shared definition of the object types (and remote messages they support). It is what it says it is, a language-neutral interface definition language. Tools are supplied by CORBA vendors (and JavaSoft) that create stubs and skeletons for IDL specifications.

CORBA is not perfect for all applications. Although free ORBs are available, to get the services or support required often involves the licencing of both developers and deployed applications, with all the licence key management overhead and costs that involves. And unlike Java's RMI, automatic behaviour marshaling is not supported. That is, if the IDL says a object of type User is being sent across the wire, and you send an instance of Student (subclass of User) into the remote method, the object will morph into a User at the remote end, probably with incorrect behaviour for some methods. Not that XML handles this any better. What XML does handle better, however, is:

Large volumes of data. Most XML parsers support the SAX interface that allows the document to be streamed in and processed without a full object model being built in memory. Obviously there are times when this is absolutely necessary.
Persistent management of text trees. An XML document is simply a stream of bytes and so can be stored in a file for later retrieval, using the correct version of the DTD. CORBA only exposes object trees, and while these can also be serialized to data files, they are brittle in that changes to class definitions can cause deserialization errors. Java does not allow for class versioning in the way that DTDs may be versioned.
Manual intervention. Let's not forget the different routes that have converged here. XML is a child of the human-readable text mark-up evolution. CORBA emerged from DCE as a way to extend computer processing between machines. If all else fails, an XML stream can be visually inspected and parsed by a human.

XML can be thought of as the text processors answer to data management. It is designed to encode the human-oriented documents that still drive many business processes. CORBA was designed by programmers to handle distributed system interactions and, as such, suffers from the complexities that go along with lower-level programming issues. In a way, XML can be seen as a revenge on programmers for developing a data distribution system that was too abstract and difficult to program.

Feature Checklist

The following is a checklist of capabilities of both XML and CORBA. I've also included RMI for completeness. By determining your needs, you can use this checklist to help determine the most appropriate technology for distributing data among your application. This is not intended to be a complete checklist of all distributed system needs or capabilities. Caveat Emptor.

Capability	Description	XML	CORBA	RMI	Winner (excluding RMI)
Platform independent	Can the client and server be on almost any OS and hardware	yes	yes	yes	tie
Language independent	Is the application language hidden from the remote system	yes	yes	no (only supports Java)	tie
Separate content from presentation	Is the content structure separated from the content and the content separate from how it is displayed	yes	yes	yes	tie
Presentation language	How is data presented to the user?	XSL, or hand-crafted code	hand-crafted code	hand-crafted code	XML
Handle human readable text	Can the document be viewed and edited with low-tech tools?	yes	no	no	XML
Handle non-string data types	Is there native for integers, floating point numbers, booleans, etc.	no (each DTD may define its own mapping to string-based representation, but there is no validation or parsing support or reuse. Note: Currently work is underway add this to XML through the Document Content Definition proposal)	string, short, int, float, double, boolean, byte, char, enums, structs (limited OO support), union	all serializable objects	CORBA
Huge data set management	Can the data be larger than the allowable application memory?	yes	no (although with CORBA, data is usually only retrieved on an as-need basis as part of a remote conversation)	no (see CORBA note)	XML
Schema versioning	Can an application handle two data streams that were created using different versions of the schema definition	yes	no	no	XML
Distribution Support	remote messaging lookup facilities security transactions etc.	none (simple messaging can be achieved by parsing transmitted XML documents)	full	partial (naming, remote method invocation, mobile code security) EJB, JTS, JNDI, etc. offer most CORBA services	CORBA
Distribution transparency	How aware of the distribution technology must the application be	Not transparent. The application must manually send XML documents into any CORBA call or remote socket. XML parser must be called for parsing and building XML document.	Fairly transparent. Once the remote connection is set up, objects may be transmitted by passing them as parameters to remote message calls. Remote exceptions must be handled.	Like CORBA, but in-out data passing is not supported.	CORBA
Object-Oriented	Can the data structure have behaviour associated with it?	no	Partial. IDL to Java generator creates mobile classes without behaviour.	yes	CORBA
Inheritance and re-use	Is inheritance supported? Can I extend one node with more-specific additional entities?	no	no (remote objects can inherit, but not marshaled objects)	yes	tie
Handle cyclic references	If node A refers to node B, can node B refer to node A	no	no	yes	tie
Handle shared references	Can node B and C both refer to node A	yes, using entities. Data sets are flat trees.	no. Shared subtrees end up as multiple subtrees.	yes	XML
Handle lazy pointers	Can data refer to other data that is not available or is to be retrieved later?	Yes. An XML document will still parse with missing entities. The XLL language provides external links much like HTML links.	No. (May be approximated with some sort of value-holder mechanism)	No . (See CORBA)	XML
Integration with application object model	Does the technology allow the application object model to be used as-is.	no. XML parsers generally support DOM or SAX based object models. Use of application object model requires mapping functions or adapter layers.	somewhat (the IDL to java generator creates structure classes that must then be used)	full (any application object which is serializable, can be passed as a remote parameter or returned as a return value)	CORBA
Handling of dynamic data formats	Can the application read a new structure it was not written for and manipulate it	yes	no	yes	XML
Technology overhead	What is the client overhead of adding the technology?	Most parsers are 200 to 400K	Most CORBA systems require 200 to 400K. In Java 2 the basic CORBA classes are included	Part of core from JDK 1.1 on. Need extra packages to support transactions, etc.	tie

Politics

So, if XML has certain benefits but also certain drawbacks for building distributed systems, why, you may ask, is there so much pressure currently to apply it to all problem domains. Part of this phenomenon stems from our natural inclination to try to see how far we can push any new "cool" technology. But this is only part of the explanation.

Take Microsoft for example. It is always dangerous to speculate too much in the political arena. Note, however, that Microsoft has made XML one of its linchpins in its drive to web-based open systems support. Of course there are rumblings that Microsoft is trying to put its own proprietary spin on the technology, but let's give Bill and company the benefit of the doubt.

CORBA has never been endorsed by Microsoft. They were early members of the OMG long before the web was hot. But they always sat on the fence about supporting CORBA and finally decided that it competed too directly with their DCOM (now called simply COM) object model plans. DCOM was the distributed extension of COM, which itself was an evolution of OLE, a technology for allowing windows applications to interact with each other. Some say that Microsoft wants to control the desktop environment and saw DCOM as a way to extend its desktop presence to a whole network, thereby mandating its operating systems as the required defacto standard. They couldn't support CORBA too directly without sabotaging their DCOM message.

Assuming that this analysis is true, what happened next? Well the web came out of nowhere and threw Microsoft's plans for Blackbird, its proprietary Information Superhighway technology, into disarray. For several months Microsoft appeared to be reacting like IBM at the beginning of the PC revolution. Finally, they ate some crow, or maybe blackbird, and embraced the web.

But, some say, the web is antithetical to Microsoft's philosophy of controlling the technology behind its products. In the web world, open is good, vendor-neutral is good, OS and language independence is good. So, while ActiveX morphed and limped out of OCX's, Java became ubiquitous. Open source and Gnu public licences became the flavour du jour. Finally, the thesis goes, Microsoft needed to get in the open game when it came to web-based data standards. The W3C was not going to accept submissions for a channel definition format based on DCOM. But publishing it as a CORBA IDL would be treasonous to its DCOM technology.

Enter XML to save the day. It's an open, vendor-neutral, OS independent standard spearheaded by the W3C. And it doesn't give the image of betraying DCOM. In fact, paradoxically, it is precisely XML's inability to specify a remote messaging interface (the core of both CORBA and DCOM) that make it an acceptable remote data format to Microsoft.

Or so the thesis goes. I have no knowledge of Microsoft's decision-making process and so all of this is, obviously, speculation. Flame shields up.

More Politics

This is not the whole picture. Sun seems to add support for every new buzzword to Java as soon as it appears. It has taken a couple of years for them to resolve the apparent splintering they did to the CORBA camp with the release of RMI. Now they are pushing a Java XML standard extension and talking of using XML to make enterprise java beans more portable.. Of course, as we saw earlier, there are valid domains for XML, and XML and Java have hit it off from the beginning. For class-version robust specification of persistent data, such as Enterprise Java Beans configuration, XML is a good choice. So Sun's work may not be as contradictory as it may first appear.

IBM, as well, has come out with a lot of XML support and components. This appears, however, to be more of a support for OS-neutral standards than a push to extend XML into the distributed messaging market. With so many of its own operating systems to support, as well as a stodgy image to update, IBM has a lot at stake in supporting both Java and XML.

Even the OMG has had to support XML, with some obvious reservations. But with the OMG that is probably more of an effort to appear open to new technologies and directions than any belief that it may be a good replacement for the core CORBA technology. Better to say "XML has its uses, and here's how it can fit with CORBA," than to put your hands over your ears and chant "I can't hear you."

Wrapping Up

XML is cool and, as Marshall McLuhan noted, cool is hot. It offers a simplified, web-friendly data mark-up language that provides domain-specific tagging and promises to make the web of documents on the net easier to manage, search and navigate. As a distributed data format, it has its advantages, but also many disadvantages when compared to the other web-centric distributed data standard: CORBA. It handles huge data-sets of human-readable text data with lazily-followed pointers exceptionally well. It does not provide a distributed messaging framework, nor support machine-readable non-text data. The reason for its push into the distributed computing arena comes from both a desire among geeks to push new technologies as far as they will go as well as political desire by some organizations to support open standards without threatening their own technologies.

There are many application arenas where XML provides huge advantages, especially in document management and stream-based data manipulation. Other applications may not benefits as much from XML as they would to other open web technologies better suited to their needs. Hopefully this article will help architects and designers get a better understanding on when it is and is not appropriate to use XML as part of the system architecture.