I can still remember the first time I met Dr. Charles Goldfarb (the father of XML and one of the creators of SGML). It was early 1998 and the specification had just become public. We were on an XML panel at a conference and were asked what we thought were the strengths of XML. Charles discussed the merits of XML with regard to many document-processing capabilities, as this was a key focus for the creation of SGML/XML. I discussed the merits of XML for messaging and distributed computing.

At the end of that panel Charles and I discussed my background and view of XML, as it was one of the earliest introductions he had to using the technology for those purposes. Consequently, it was also an opportunity to share ideas, work, and become friends with Dr. Goldfarb, for which I am eternally grateful.

To me using XML for messaging and distributed computing was only natural as I had spent hundreds of man-hours building and marshaling code and parsers to handle proprietary client/server applications. It was a novel idea to think about using XML for presentation.

On the whole, technologies such as CORBA, RMI, and SOAP have made it easier for developers to ignore the underlying mechanics of making functionality calls across the network. They can view the remote function as an extension of their local programs with parameters and return codes. These technologies also allow them to ignore the significant body of work that underlies these systems for packaging the data for execution on the remote machine, unpacking it on the receiving side, dispatching the function call inside the implementation, packaging the results for return to the calling application, unpacking the results and handing it back to the calling function.... Phew! If it sounds hard reading it, it's far more complex to implement in a robust, scalable, and reliable manner.

Early distributed applications often relied on proprietary messages on a per-application basis, making it very difficult to have reusable code across projects. In addition, it also meant that each project required a proprietary parser to be written for the messaging scheme in place, and sometimes in differing programming languages if the client and server were not written in the same language.

Creating a utility, independent of the underlying transport or programming languages that generalizes the method in which these underlying messages get written, was a major leap forward for distributed computing. Having this facility generate XML documents provides greater reusability of the data crossing between applications and can also be leveraged for content-based routing and simultaneous viewing of the content.

Another one of my earliest collaborations in the XML field was with Bill la Forge, a coauthor on my book Enterprise Application Integration with XML and Java. Bill and I worked together on his concept for Multiple Document SAX (MDSAX) - a filtering framework that transforms XML documents into multiple document outputs.

Bill and I shared a vision for building applications dynamically through the use of XML documents. It's amazing to see how far concepts like this have come within our industry. Today, XML is used as the primary method of application configuration for Java servlet engines, Enterprise JavaBean deployments, as a replacement for the make facility via ANT, and a whole host of applications that now incorporates some level of XML internally for scripting and/or configuration.

I'm the first to admit that XML is not a panacea and it won't cure cancer, but for the pragmatic programmer, XML offers some simple and fast solutions that previously required a significant effort. Some may say that XML is simply a grammar or a data representation, therefore, how could it do anything? To those people I say, "Have you ever built a large-scale application with five to 10 different parsers in it, each one handling a different data format or messaging protocol?" Those of us who have appreciate the small advantages standardization and XML offer.