Creating Interfaces to Legacy Systems

We have now covered some of the common problems with supporting and interfacing legacy systems in an enterprise. Because of the wide variety of legacy systems, no single solution can make them all work with newer technology. Some systems provide native functionalities for third-party access, while others support only proprietary features and functionality. Because of this variety, interfacing with legacy systems can be extremely challenging, but it can be done.

An Example Scenario

IBM created CICS Web gateways that allow you to create CGI scripts to make calls into CICS directly, which can greatly simplify the task of interfacing to legacy systems. IBM is one example of a company adding enhancements to its legacy products. These are often products that would have become extinct if not for the enhancements, which have potentially saved their customers millions by allowing them to postpone migrations.

You can interface with legacy systems using five common approaches. They are generalized to represent areas that developers and managers can focus on when trying to utilize old systems for new work. They are

• Data-level
• Process-level
• API-level
• UI-level
• Middleware

Let's take a closer look at each of these approaches.

Data-Level Interfacing

The first type of interfacing focuses on accessing legacy databases or files directly at the data level, bypassing most, if not all, of the functionality present in the surrounding application.

If your data is stored in SQL databases you can access them directly using appropriate SQL queries. Some RDBM systems, such as older versions of Novell Btrieve, provide non-SQL, but nonetheless fairly complete, API access to their databases. Other systems provide proprietary data storage mechanisms and often have data import and export functionalities designed specifically for interfacing. Communications with these systems are performed through the exchange of files of a specific format. These usually involve some form of delimited text files.

Some vendors, such as Oracle and Microsoft, provide native XML-based access to data stored in their databases. For example, back in Chapter 4 we discussed some of the built-in features provided by Microsoft SQL Server 2000 and Oracle 9i for exposing and updating relational data as XML. This appears to be the next-generation method for enabling integration.

The main problem with data-level interfacing is that it increases data coupling between applications, thereby increasing your maintenance burden. You might also not be able to access important data validation and other critical business rules that are inherent in the application but not in the method of accessing the information. Finally cost can also be a limiting factor, especially if you need to employ a middleware product.

Process-Level Interfacing

Solutions written for some mainframe environments, especially those written in COBOL, were developed as a series of separately executable programs. Interfacing with these systems usually requires preparing the invocation environment, calling the required program(s), and fetching and processing the returned data. While this formula for process-level interfacing provides a common method of getting to the data, it can be overwhelming when trying to extract only simple information.

CICS, which is a good example of this method, provides an External Call Interface (ECI) to allow non-CICS clients to invoke and control programs under CICS. ECI includes support for CICS security and transactions and, unlike RPC environments, ECI does not require stubs and the use of an Interface Definition Language (IDL) compiler and is therefore easy to use.

Here is an example of how process-level interfacing works with CICS. To run a CICS program using ECI, you must supply CICS with all the relevant information for the invocation, such as the name of the program to invoke and a username and password. You pass data to the CICS programs via a block of data called the COMMAREA block. When the invoked CICS program finishes it places the results in the COMMAREA block.

API-Level Interfacing

Another type of interfacing with legacy systems is to provide an API to access the functionality of an application. Many packages, such as SAP and PeopleSoft, include C/C++ or even COM-based APIs for accessing their systems. However, APIs might be limited in scope, preventing access to the functionalities you need. They might, for example, behave in a fashion you do not expect, such as not being thread-safe.

If your team has the required skill sets, these APIs can provide a powerful means of interfacing to the legacy systems. However, these APIs might be limited in scope, preventing you from accessing the functionalities you need. They might also not behave in the fashion you require, such as (for example, not being thread-safe).

User Interface-Level Interfacing

Accessing legacy applications through UIs, a process called screen scraping, refers to the interaction with the legacy software performed by using simulated user keystrokes and entered data by processing captured screen outputs. This technique is most often used with old "green" terminal-based systems and is one of the last methods a person might use to integrate with a system.

Recently this technique has been used by Web-based aggregation sites for presenting financial data or other types of information. These sites build their contents by combining data extracted from parsing HTML pages retrieved from other Web sites.

Middleware

Some mainframe vendors and third-party companies provide solutions that allow applications to access data through middleware products. These products sit between your new and legacy systems, hiding the complex details of legacy interfacing from you.

Different middleware products can vary greatly in functionality. Some products simply provide a mechanism for data to get from place to place, such as RPC, messaging systems, and distributed object systems. More sophisticated middleware offerings, however, can help manage application logic and resources. The most robust tools directly support significant application functionalities such as credit card transactions for e-commerce. By employing sophisticated caching and asynchronous data-transfer technologies, these high-end products can also provide scalable access to your legacy data. IBM's DB2 WWW Connection and the Sybase Enterprise CONNECT middleware family of products are some examples.

If support for your particular legacy system is available, using the right middleware product can greatly simplify the task of legacy integration. The major downside is that these products, especially the high-end ones, are not cheap. They also require extra hardware resources and administrative care that adds to the cost. You will have to decide whether using a middleware product is cost effective for your particular integration needs.