Using XML with Legacy Business Applications: Chapter 1

Reproduced from Michael C. Rawlins's Using XML with Legacy Business Applications by permission of Addison-Wesley. ISBN 0321154940, copyright 2004. All rights reserved. See https://www.awprofessional.com/titles/0321154940 for more information.

Introduction

You know what a “legacy application” is? It’s one that works.—Bill Cafiero

This chapter introduces the approach presented in the book and discusses the business and technical rationales for it. Based on these, the overall features of the approach and the major design decisions are reviewed. The chapter concludes with a description of the primary audiences and suggestions for how to use the book.

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.

What Do We Need in a Solution?

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.
~ What Do We Need in a Solution?

When we ask, “What do we need?” we’re talking about requirements. There are two types of requirements: functional and nonfunctional (the latter are also known as quality requirements or system constraints). The former have to do with what the system is supposed to do. The latter have to do with how it does what it does. Both are important, and both determine the overall approach of this book.

Beyond the overall dictate of solving the problem, two distinct sets of requirements are imposed on the solution by technical end users on the one hand and by application developers on the other. I’ll talk a little later about why I’m dealing with both, but for now if you don’t care about the other group you can just skip the relevant paragraphs.

Functional Requirements

The technical end user who has an application that doesn’t speak XML more than likely needs the solution to do one or more of the following:

Convert an XML-formatted file to a flat file
Convert a flat file to an XML-formatted file Convert an XML-formatted file to a CSV file Convert a CSV file to an XML-formatted file
Convert an EDI-formatted file to an XML-formatted file Convert an XML-formatted file to an EDI-formatted file

A user may want the solution to support other formats, but CSV, flat file, and EDI should handle most cases. For example, an end user may also need to get data out of a database (relational, hierarchical, or otherwise) and put it into an XML format, or go back the other way. Sorry, but these types of problems are a bit beyond our scope. I will, however, give in Chapter 12 an overview of some approaches for doing things like this. When I present the approaches, you’ll understand why problems like this exceed our scope a bit.

The developer who has an application that doesn’t speak XML has some fairly simple requirements:

Enable the application to export data in an XML format Enable the application to import data from an XML format

The word “an” is very important here. I don’t say “a specific XML format”; I say “an” XML format. Why? Because once we have data in an XML format, it is fairly easy to convert it to another XML format. You want to make your life simple? Don’t try to anticipate all the XML formats your users will want. Give them one, and let them convert. I’ll have more to say about this later.

Those are the primary functional requirements. Both groups may have a secondary functional requirement to be able to validate the format of an XML document (which conventionally is referred to as an instance document). When validating an instance document, the format of the document is usually defined in an XML 1.0 Document Type Definition (DTD) or a schema written in the World Wide Web Consortium (W3C) XML Schema language. Both of these define things such as the Element and Attribute names used in the document and the overall structure of the document. The W3C XML Schema language allows documents to be defined in much greater detail than is possible with a DTD. These will both be discussed in Chapter 4.

Validation may need to occur either before the document is read or after it is produced. For going to and from EDI, end users may want to check that the EDIformatted file complies with the relevant standard either before they read it or after they write it. The approach presented in this book satisfies most such requirements.

Some other functional requirements have do with enabling business applications to support the exchange of business data with other organizations electronically. Those requirements are within the scope of this book, and I’ll discuss them in Chapters 12 and 13.

So, we should be pretty clear by now about what we want the solution to do. We now need to figure out how we want it to do it.

~ What Do We Need in a Solution?

When we ask, “What do we need?” we’re talking about requirements. There are two types of requirements: functional and nonfunctional (the latter are also known as quality requirements or system constraints). The former have to do with what the system is supposed to do. The latter have to do with how it does what it does. Both are important, and both determine the overall approach of this book.

Functional Requirements

The technical end user who has an application that doesn’t speak XML more than likely needs the solution to do one or more of the following:

Enable the application to export data in an XML format Enable the application to import data from an XML format

So, we should be pretty clear by now about what we want the solution to do. We now need to figure out how we want it to do it.

Created: March 27, 2003
Revised: January 1, 2004

URL: https://webreference.com/programming/awxml2/

Using XML with Legacy Business Applications: Chapter 1