Legacy systems are too important for Java developers to ignore, but needn't be a hassle to access. These systems include everything from packaged applications like SAP and Peoplesoft to aging home-grown mainframe systems and external data sources such as EDI. Despite what you may personally think about some of the more elderly of these systems, they play critical roles in many organizations and will continue to for years to come.

In this column, the second of three in the application server series, we'll look at how developers handle legacy systems. Previously we discussed how developers accessed SQL results sets through the application server.

As developers we frequently want to bring a result set from the legacy system to the application server where we make it available for reading and updating. In fact, we may want to integrate any data into the application server as a result set. For instance, Java developers may have to incorporate data from EDI or, more recently, XML, the new, increasingly popular standard for structured data exchange over the Web.

XML (Extensible Markup Language) is particularly interesting. It is a tag-based markup language like HTML except that it can describe not only how data is to be displayed on the Web, intranet or extranet, but what the data actually represents. Once the computer knows what a piece of data represents - phone number, part number or customer name - it can programmatically process the data, store it and display it. XML is referred to as open and extensible because users can define the tags they need. Expect to find more and more legacy data increasingly taking the form of XML pages.

Some application servers handle legacy data through the use of adapters. The adapter acts as middleware, taking a standard call from the client and transforming it into a call to the appropriate legacy system API. It then presents the returning data in a manner that closely resembles a SQL result set, with rows and columns, so that the application server framework can easily work with the data. In addition to making API calls, such as calls to SAP's BAPI interface, adapters also read flat files, interpret EDI and XML uploads, and interface with application integration servers such as Active Software's ActiveWeb.

Application server adapters are relatively new to the market, but I expect they will become quite popular. Some application-server vendors provide them. Also watch for third-party providers to develop adapters for some of the more esoteric legacy applications to run with the more popular application servers.

Without commercial adapters, Java developers have to create their own. Those who have done it generally don't wish to repeat the experience. Creating an adapter requires handcrafting custom, low-level connections to the legacy application, a difficult task that generally produces a mountain of specialized code.

Complicating the task is the need to make the results usable. Once the data is retrieved, it needs to be cached, delivered, displayed, navigated and manipulated. Hand programming these on a data-source by data-source basis can be extremely time consuming and error-prone. In addition, every time the legacy application vendor enhances the application or changes something, the Java programmer must rewrite the adapter. I can think of better ways to have fun.

If you're a Java programmer just trying to knock out an application that requires a connection to a legacy system or packaged application, there is no glory in creating these adapters yourself. Shop around for an application server with built-in adapter support that provides the legacy connections you need and can integrate into your development framework. The application server's ability to incorporate such legacy data into a new Web application can provide tremendous benefits.