Settling into XML

With XML no longer a new technology, most people have a good idea about how it works, and how they like to use it. However, the jury is still out on XML's "killer application" -- the ultimate usage of the data format that seems to justify its creation. As you look at some of the most common usages in this article, you'll quickly see that even experts disagree, and XML can be used -- or not used -- in lots of different applications.

Back to top

XML for configuration data

One of the earliest uses of XML, and still one of the most popular, is using XML as a data format to store configuration data. Almost as soon as XML became popular, programmers began to replace their proprietary configuration files with XML. Properties files, text files with name-value pairs, comma-separated values, proprietary data formats -- all were tossed out in favor of XML documents, complete with tags, elements, attributes, and textual data.

A verbose data format

The most obvious problem with this application of XML is that by definition, XML is a very verbose data format. In other words, it takes a lot of space to say anything in XML. For instance, here's a simple name-value pair file fragment:

firstName=Brett
lastName=McLaughlin
email=brett@newInstance.com

Compare this with essentially the same data in XML:

<?xml version="1.0"?>
<config-data>
 <firstName>Brett</firstName>
 <lastName>McLaughlin</lastName>
 <email>brett@newInstance.com</email>
</config-data>

There are a lot of extra characters introduced for the "convenience" of XML. That means that you traded speed (it always takes less time to read less characters) for the XML technology choice.

XML processing APIs

In addition to the extra characters that it usually takes to represent data in XML as opposed to other text formats, you will need some software to process and read the XML. While you could write an XML parser, you'd almost certainly want to use one of the many XML parsers already available, on a variety of platforms. So you'll probably need to add a library or two to your software's resources, and learn to use those APIs.

While it's never bad to learn new APIs, realize that you probably will replace working code that reads in your existing textual configuration data with new code that you'll have to write yourself, using additional libraries that you'll have to make available in your application. In other words, you're replacing working code with new code and additional dependencies, both at compile-time and run-time (assuming you're working in a compiled language, but you get the idea).

The cost of flexibility

The question then becomes one of cost versus value. The cost of using XML for configuration data is fairly high; I just mentioned verbosity and resource requirements, but there are plenty of other negatives. The major positive -- assuming you realize that being the cool guy that knows how to use XML really isn't much of a positive -- is flexibility. If you already use XML, or have multiple applications, potentially in multiple languages, that all share configuration data, then XML might be a very viable strategy for configuration data.

With that exception, though, what do you really gain by using XML as the format for your configuration data? I think there are a couple of other good reasons, but I'm not telling -- I'd like to hear from you. Check out the Resources section, click on XML and Java technology forum, and let me know. I'm curious to hear what advantages you think XML provides for configuration data.

Back to top

XML for transferring data

Beyond configuration data, XML has become a popular option to send data between components or layers of an application. In this model, different pieces of an application communicate in the "language" of XML. While this is a little more technically challenging than simply using XML for configuration data, it's nearly as popular, and underlies technologies like SOAP, data binding, and Web services.

Intra-application data transfer

One of the most common uses of XML as a data format is to send information between different parts of the same application. This is pretty easy to put into place because the same programmer, or programmer teams, control both the sending and receiving end of the data. Unfortunately, this is also almost certainly the worst use of XML for transferring data.

When you send and receive data in the same application, you add the same overhead as discussed in the section on configuration data to your application: verbosity, larger files, and the need for an XML parser library (at a minimum).Rarely do you actually gain much from using XML, as well. In most cases, a much better solution is to send serialized data or objects native to the programming language that you use. It's usually faster, because it takes less bandwidth to transfer the data, and easier to decode on the receiving end.

Inter-application data transfer

A much better use for XML in this general area is to send data from one application to another using XML as the data transfer format. You have one component, say in your application, that sends data to another component, in a business partner's application. The data is encoded as XML.

This has some real advantages, because you don't have to know the programming language of the other application, or anything about how the data will be used. The same is true in reverse; if you receive the data, you have to know very little about the sending application. In this case, the negative effect of the verbosity of XML is probably outweighed by the flexibility you pick up, and by having to code only to the XML data format, rather than another company's programming specifics or technology choices.

Variation on a theme: Web services

Web services, SOAP, WSDL, and the variety of other buzzwords that are hot right now justify their own coverage. However, the varieties of Web services available are really just a subset of inter-application data transfer. You send (or receive) data from another application's components, provided by some other business or technology provider.

The only substantial difference is that Web services typically require you to use XML. So the choice isn't really whether or not you want to use XML when it comes to Web services; it's whether you want to use Web services at all. And that becomes a much bigger issue: You weigh the value of using the features of the Web services versus the cons of dealing with that provider, the speed of the provider (which has something to do with XML, but is probably also affected by bandwidth, latency, the specific provider, and a host of other factors), and the reputation of the company. In other words, XML becomes a negligible factor, not a controlling one.

Back to top

In conclusion

While most articles present concrete solutions to specific problems, this article is meant to get you thinking. In most potential applications of XML, there's simply no "right" answer. Sometimes XML seems a better choice than alternatives, sometimes it's almost certainly not a good choice, but in many cases, it's just one option among many. Your job is to think critically about the general applications detailed here, and then try and make some application to the specific problems that you run across in your own business and projects.

I also encourage you to jump online and check out the various XML forums (see the Resources section for links), and continue this discussion. I'll hang around the XML and Java technology forum, hoping to spur on interesting conversation and debate. So do some thinking, and then hop on a developerWorks forum and speak up. See you online.

Resources

• Participate in the discussion forum.
  
  
• XML technical library: See the developerWorks XML zone for a wide range of technical articles and tips, tutorials, standards, and IBM Redbooks.
  
  
• IBM trial software: Build your next development project with trial software available for download directly from developerWorks.
  
  

About the author

Brett McLaughlin has worked in computers since the Logo days. (Remember the little triangle?) In recent years, he's become one of the most well-known authors and programmers in the Java and XML communities. He's worked for Nextel Communications, implementing complex enterprise systems; at Lutris Technologies, actually writing application servers; and most recently at O'Reilly Media, Inc., where he continues to write and edit books that matter. Brett's upcoming book, Head Rush Ajax, brings the award-winning and innovative Head First approach to Ajax. His last book, Java 1.5 Tiger: A Developer's Notebook, was the first book available on the newest version of Java technology. And his classic Java and XML remains one of the definitive works on using XML technologies in the Java language.

Rate this article

Comments

Back to top

Table of contents

• Settling into XML
• XML for configuration data
• XML for transferring data
• In conclusion
• Resources
• About the author
• Comments