Integration of Web with Legacy Systems Through Java Applets and Distributed Objects

Ritu Chadha Bellcore 445 South Street Morristown NJ 07960. chadha@bellcore.com (973) 829-4869

Introduction

In a world where desktop computing is becoming ubiquitous and the World Wide Web is the access technology of choice due to its universal availability, there is a growing need to leverage the benefits of Web access to existing back-end systems while preserving the investment in these legacy systems. The new Web-based applications and services promise more flexible, efficient and cost-effective operations than the legacy systems that are showing signs of age and years of patching and fixing. Although legacy systems are becoming increasingly expensive and time consuming to maintain, these systems cannot be easily ignored because they support mission-critical operations such as billing, service provisioning and service assurance. In the near future, the new Web-based systems will need to co-exist and interwork with the existing legacy systems. This is a very effective strategy for many organizations in the late 1990s and beyond because it leverages the existing investment in legacy systems, takes advantage of new technologies quickly, and minimizes the risks involved in migrating large-scale mission-critical legacy applications.

The purpose of this position paper is to describe the state of the practice in Web and distributed object integration by describing research in this area at Bellcore. We present below the results of an intensive prototyping effort that was conducted in order to assess the suitability of a number of middleware technologies for providing Web access to a wide variety of legacy systems. Our goal was to provide a unified user interface that could transparently access different legacy systems without the user being aware of the types of back-end systems being accessed. We also experimented with scenarios where a single user query results in interaction with multiple legacy systems and consolidated results are presented to the user. The approach allows plug-and- play - i.e. clean interfaces are defined for plugging in any number of legacy systems transparently.

Application: The Healthcare Industry

For this work, it was necessary to choose a simple application that could be deployed on several back-end systems without too much effort, so that the bulk of our development effort could be spent on developing Web access to these different back-end systems. The application that we used is the healthcare industry. Healthcare providers need to access patient data, such as whether patients have insurance coverage, what the status of a particular insurance claim is, and so on. They also need to be able to submit insurance claims to health insurance companies on behalf of their patients. Health insurance companies need to allow healthcare providers access to the data that they need. Since a lot of the data that needs to be made accessible by insurance companies is stored in legacy systems, there is a need for middleware technology that will allow uniform and transparent access to various legacy systems across the Web.

The interface between healthcare providers and insurance companies is provided by an object, called the Payer object. The Payer object represents a single insurance company, or payer. The object interface allows healthcare providers to check the eligibility of patients for insurance coverage, submit insurance claims, and check the status of submitted claims. The object interface is described using CORBA IDL.

System architecture

The architecture of our system is shown in Figure 1. The components of the architecture are described below. Note that the legacy system could be any one of several systems; we describe below the different legacy systems to which we provided access.

Client User Interface Applets

The client GUI interface for the healthcare provider is contained in a set of Java applets. An HTML link in a menu of operations leads the user to the required applet. The user then downloads an applet (by clicking on an HTML link) from a Web server using a Java-enabled browser. The applet contains a CORBA Payer client, implemented using IONA's OrbixWeb 2.0.1, that communicates with a Payer server.

Payer server

This CORBA server, implemented using IONA's OrbixWeb 2.0.1, receives requests from a Payer client, and needs to access legacy data in order to respond to these requests. The legacy system is accessed by the Payer server using technology appropriate for the specific legacy system.

Legacy System

Patient and claims data is stored in some legacy system in the health insurance company's network. The different legacy systems that we used are described below:

MVS mainframe: The back-end system storing insurance information is an MVS mainframe system. We built the Payer object on MVS by storing it in an IMS data store. We then implemented methods in the REXX language to perform the three Payer object operations. In order to invoke these REXX methods, we needed to make use of a screen scraper (Apertus' Enterprise/Access). Thus our Payer server relays requests received from the Payer client to the Enterprise/Access screen-scraping software.

ODBC-enabled database: Insurance data is in an ODBC-enabled database. Functionally, the system consists of a Payer server (the front-end interface) and an ODBC client (the back-end interface). The Payer server receives CORBA calls and makes ODBC calls to an ODBC driver manager to make SQL queries to the database. The only knowledge of the database the Payer server has is the database schema and access requisites (such as login name and password). This means that exactly the same server could be used with a non-legacy incarnation of the same or expanded database, as long as the database schema remains unchanged. This, along with the prohibitively high (for this experiment) cost of a DB2 ODBC driver for MVS, led us to use an Oracle database in place of a true legacy database. jet.connect, a Java ODBC class library from XDB Sys tems, is used to make ODBC calls inside the Payer method implementations. DataDirect ODBC driver manager and Oracle driver for Solaris from Intersolv and an Oracle 7.3 database server have been been used for the remaining components. All of the components are running under Solaris 2.

Transaction Integration: We extended the healthcare example by implementing a scenario where there is a need for a transaction to span across multiple healthcare providers. Say a patient has insurance coverage from two different health insurance companies. When a claim is submitted for this patient, the claim submission needs to be sent to both companies, and should either fail or succeed at both locations. We implemented transaction integraton using IONA's Orbix OTS, an implementation of OMG's Object Transaction Service.

SNMP data: We also provided Web-based access to SNMP management information via CORBA interfaces (note that the Payer object was not used for this as management data is different from application data). Two steps were required for this: first, translate the relevant SNMP MIBs (Management Information Bases) into CORBA IDL. This was done using the X/Open Joint Inter-Domain Management translation algorithm [2]. Second, build a gateway that will convert CORBA method invocations into SNMP PDUs (Protocol Data Units) and vice-versa. We implemented a CORBA-SNMP gateway using IONA's Orbix 2.2MT. This version of Orbix uses an IDL to C++ mapping. The implementation of the CORBA interfaces was done in C++. On the client side, the implementation was done using IONA's OrbixWeb 2.0.1. We also made use of an SNMP toolkit that is available as freeware from CMU [1]. We then built a C++ object wrapper around the CMU toolkit that would hide the details of the SNMP protocol from the developer.

Summary

We provide below some comments on the technologies used in this study:

The CORBA object model provides a powerful way to describe an application and encapsulate the relevant data and methods. Once we developed an IDL description for our application, we had a clear-cut path for plugging in the different legacy systems to which we were interfacing. The common IDL interface shared by all the legacy systems made user access to these systems truly transparent. It also allows plugging in any kind of legacy system; all that is required is implementation of the IDL interface.
The use of Java in this study was mandated by our goal of providing a Web-based user interface to legacy systems. In this work, we needed to download an applet onto the client machine and use it to communicate with the legacy systems. However, the sandbox security model for Java in general prohibits an untrusted applet from opening network connections to any host other than the one from which it was downloaded. We dealt with this restriction by using signed applets. The downloaded applet and its support files are stored in a Java Archive (JAR) file, which is signed with a digital signature of a trusted party. The signature is verified and, if correct, the applet is started by the provider's browser with the security restrictions defined for the applets signed by this signer. The applet is only allowed to open network connections to other hosts. No operations on the local file system of the healthcare provider are permitted. We did run into version incompatibility problems with this approach, as this capability is only implemented in JDK 1.1, which was not supported by Microsoft Internet Explorer at the time our work was done (September 1997). Also, Netscape's object signing tools for our platform (Solaris) were not available. We used the HotJava 1.1 browser, which provided the required support for JDK 1.1.

References

Carnegie-Mellon University, SNMP agent toolkit, ftp.net.cmu.edu://pub/snmp-dist/cmu-snmp2.1.2.tar.Z.
X/Open Group, Inter-Domain Management: Specification Translation, http://www.rdg.opengroup.org/pubs/catalog/p509.htm, 1997.