The Problem

So, what's the problem? You probably picked up this book (or are browsing this sample chapter on the Web) because the title sounded like it might have something to do with your situation. The Preface probably fleshed out that impression a bit more. By now you probably think you have the book pretty well scoped out, and you may not be that far from the truth. But to save you a bit of time, let me be very specific about the problem (or, more accurately, the problems) that this book addresses.

The primary problem is this: You have one business application that imports and exports data in XML formats, and one that doesn't. You need to make these two applications talk to each other. The XML-enabled application may be yours, or it may belong to someone with whom you (or your application's users) need to exchange data. (Imagine an important customer or government agency sending you a letter that says, "You will receive orders from us in XML format by January 15 or be assessed a $50 penalty for each paper order.") The legacy application is most probably yours. However, the shoe may be on the other foot : Your application speaks XML, but the other guy's application doesn't. He expects you to deal with it. (Imagine an important customer sending you a letter that says, "You will receive orders from us by EDI by January 15 or be assessed a $50 penalty for each paper order.")

There are really two perspectives to this primary problem, and this book addresses both. According to one perspective, the application developer should just fix the stupid application so it can speak XML. From an end user 's viewpoint, this is perfectly reasonable, and I'll deal with the problem from this perspective.

From the other perspective, whoever developed the application can't or won't support XML by the time you need it (which might have been last week). There may be several reasons for this. The vendor of a commercial package may not see sufficient market demand. The vendor may have retired the product or, even worse , gone out of business. If the application was developed in-house, the original developers may be gone, retired , or dead. So, there are quite a few reasons why you might need to come up with a solution on your own. In this book I'll also deal with the problem from this perspective.

That, in about 400 words, sums up the primary problem this book addresses. However, in solving this problem from the perspective of someone who needs to come up with a solution on their own (as opposed to that of the developer who just needs to fix the stupid application), we find that the solution might apply to similar problems. Why is that? Well, if we have a method to go from a legacy flat file to XML and a method to go from XML to a legacy flat file, we have a method to go from a legacy flat file to a different legacy flat file (with XML in between). The same thing holds for other common formats such as comma-separated values ( CSV ) or Electronic Data Interchange ( EDI ). By coming up with a solution to the primary problem, we find that we have a general solution for all sorts of file format conversion problems. That is also what this book is about.

Before we leave the problem definition and start addressing the solution, there are just a couple more points we need to clarify. First, what, exactly, is a legacy application? Aside from Mr. Cafiero's pithy observation, for the purposes of this book we'll refer to a legacy application as any working application that doesn't currently provide native support for XML (that is, the application can't produce XML documents as output and consume XML documents as input).

Second, why use XML with a legacy application? That is a reasonable question, but answering it is beyond the scope of this book. In this book I assume that you have already answered that question for yourself. You're going to use XML and you have figured out why; all you want to know is how . There has been enough good general material written on the benefits of application integration and electronic commerce that I feel there's very little I can add for justification.

In regard to XML in particular, I assume that you have one application that uses XML and a legacy application that doesn't, and that you need to integrate them. To do that you need either to convert between XML and the format required by the legacy application or to build native XML support into the legacy application. You know what you need to do and why you need to do it. This book is intended to help you with how to do it.