Chapter 1. Introduction

1.1.1. Portability

XML is portable. If you've been around Java long, or have ever wandered through Moscone Center at JavaOne, you've heard the mantra of Java: "portable code." Compile Java code, drop those .class or .jar files onto any operating system, and the code runs. All you need is a Java Runtime Environment (JRE) or Java Virtual Machine (JVM), and you're set. This has continually been one of Java's biggest draws, because developers can work on Linux or Windows workstations, develop and test code, and then deploy on Sparcs, E4000s, HP-UX, or anything else you could imagine.

As a result, XML is worth more than a passing look. Because XML is simply text, it can obviously be moved between various platforms. Even more importantly, XML must conform to a specification defined by the World Wide Web Consortium (W3C) at http://www.w3.org. This means that XML is a standard. When you send XML, it conforms to this standard; when some other application receives it, the XML still conforms to that standard. The receiving application can count on that. This is essentially what Java provides: any JVM knows what to expect, and as long as code conforms to those expectations, it will run. By using XML, you get portable data. In fact, recently you may have heard the phrase "portable code, portable data" in reference to the combination of Java and XML. It's a good saying, because it turns out (as not all marketing-type slogans do) to be true.

1.1.2. Interoperability

Second, XML allows interoperability above and beyond what we've ever seen in enterprise applications. Some of you probably think this is just another form of portability, but it's more than that. Remember that XML stands for the Extensible Markup Language. And it is extensibility that is so important in business interoperating. Consider HTML, the hypertext markup language, for example. HTML is a standard. It's all text. So, in those respects, it's just as portable as XML. In fact, clients using different browsers on different operating systems can all view HTML more or less identically. However, HTML is aimed specifically at presentation. You couldn't use HTML to represent a furniture manifest, or a billing invoice. That's because the standard tightly defines the allowed tags, the format, and everything else in HTML. This allows it to remain focused on presentation, which is both an advantage and a disadvantage.

However, XML says very little about the elements and content of a document. Instead, it focuses on the structure of the document; elements must begin and end, each attribute must have a single value, and so on. The content of the document and the elements and attributes used remain up to you. You can develop your own document formatting, content, and custom specifications for representing your data. And this allows interoperability. The various furniture chains can agree upon a certain set of constraints for XML, and then exchange data in those formats; they get all the advantages of XML (like portability), as well as the ability to apply their business knowledge to the data being exchanged to make it meaningful. A billing system can include a customized format appropriate for invoices, broadcast this format, and export and import invoices from other billing systems. XML's extensibility makes it perfect for cross-application operation.

Even more intriguing is the large number of vertical standards[1] being developed. Browse the ebXML project at http://www.ebxml.org and see what's going on. Here, businesses are working together to develop standards built upon XML that allow global electronic commerce. The telecommunications industry has undertaken similar efforts. Soon, vertical markets across the world will have agreed upon standards for exchanging data, all built on XML.

[1]A vertical standard, or vertical market, refers to a standard or market targeting a specific business. Instead of moving horizontally (where common functionality is preferred), the focus is on moving vertically, providing functionality for a specific audience, like shoe manufacturers or guitar makers.

1.1.3. It Doesn't Matter

When all is said and done, XML matters because it doesn't matter. I said this earlier, and I want to say it again, because it's at the root of why XML is so important. Proprietary solutions for data, formats that are binary and must be decoded in certain ways, and other data solutions all matter in the final analysis. They involve communication with other companies, extensive documentation, coding efforts, and reinvention of tools for transmission. XML is so attractive because you don't need any special expertise and can spend your time doing other things. In Chapter 2, "Nuts and Bolts", I describe in 25 or so pages most of what you'll ever need to author XML. It doesn't require documentation, because that documentation is already written. You don't need special encoders or decoders; there are APIs and parsers already written that handle all of this for you. And you don't have to incur risk; XML is now a proven technology, with millions of developers working, fixing, and extending it every day.

XML is important because it becomes such a reliable, unimportant part of your application. Write your constraints, encode your data in XML, and forget about it. Then go on to the important things; the complex business logic and presentation that involves weeks and months of thought and hard work. Meanwhile, XML will happily chug along representing your data with nary a whimper or whine (OK, I'm getting a bit dramatic, but you get the idea).

So if you've been afraid of XML, or even skeptical, jump on board now. It might be the most important decision, with the fewest side effects, that you'll ever make. The rest of this book will get you up and running with APIs, transport protocols, and more odds and ends than you can shake a stick at.