We are often faced these days with having to port an existing application to our company's Web-based intranet. This special focus section deals with some of the problems software developers have faced, and how they have solved them, when porting legacy software to the Web.
This focus section of IEEE Software looks at how Web technology can be applied to ameliorate the problems of legacy software. Legacy software systems, by definition, have been in operation for years. Such systems usually suffer from old age in several respects:
the original developers are no longer with the company;
little or no documentation exists to describe the internal workings of the software;
normal maintenance must continue;
when the underlying hardware changes or when the operating system is upgraded, legacy software must also be adjusted; and
the perennial issue of bug fixes may arise.
As a result, system maintenance can occupy many programmers full time, often leaving no time or money to enhance or totally rewrite the application.
The development of Web technology (browsers, servers, and the like) is having a major impact far beyond the world of Web sites. In particular, flourishing corporate intranets make use of Web technology within the confines of their organizations.
Legacy systems would be more effective if they
could be delivered to people's desks over corporate intranets without concern for hardware platform,
had access to databases distributed across the corporation, and
could be transformed into a modern graphical user interface.
There is likely no silver bullet that will solve this problem or meet this challenge. One often suggested panacea is Java. But building a system in Java is a highly controversial step from several perspectives. Most important is that a Java version necessitates an entire rewrite of the software, and any major development effort has risks associated with it. A Java-based development has the additional disadvantage of dealing with immature software, such as the Java Virtual Machine. So a positive decision to move ahead with a Java rewrite requires serious justification.
The Road to a Web-based System
Based on my experiences at USC, where we have hosted two legacy systems to the Web, I suggest there are three basic steps to follow when migrating a legacy system to a Web client/server environment.
Step 1: Understand the legacy software
The first step is to thoroughly understand the legacy software. This has two facets: understanding what the software does and understanding how it does it. Moving from code to design documentation remains an art, but a necessary first step. If this were easy, legacy systems wouldn't be so problematic. But it is a very hard problem. An entire issue of IEEE Software, Jan. 1995, addressed the many problems inherent in comprehending legacy software.
Step 2: Design the architecture
Next you design the new system architecture. For hosting to the Web, this usually means determining what will be executed on the client side, what will be executed on the server side, and what communication between client and server will occur. Software architecture is an active field of research; you can find pointers to many sources in the architecture special issues in IEEE Software, Nov. 1995, and in IEEE Transactions on Software Engineering, April 1995.
On the client side, the main issue is the user interface. There are two competing alternatives: HTML forms or Java. HTML forms represent a reliable and efficient mechanism for capturing user input, but they provide limited capabilities for creating user interfaces. With Java's Abstract Windowing Toolkit (and more recent alternatives such as a mixture of Microsoft Foundation Classes and Java), you have a much more powerful mechanism for creating the interface you want, but at the expense of performance.
A second major client-side issue is the amount of computation to be performed. This is intimately related to the amount of information to be moved from the server to the client and how long that will take. Strategies such as caching on the client side are quite common.
The main issue on the server side is how to create the application server from the legacy system. Usually you must extract the old user interface code; this can be easy or difficult depending on the original architecture of the software.
Once you've determined the client- and server-side programs, you must decide on the actual communication protocol between them. A handcrafted program will use a socket library and will transfer information between client and server. Even though the client-side program may be started via a Java applet, the connection between the applet and the Web server cannot be maintained, as there is no state information retained. Though mechanisms exist to get around this limitation, they are at best awkward and limited in scope.
Rather than a handcrafted protocol, you may want to use one of several competing protocols for managing distributed objects. Corba's IIOP and Sun's RMI are two such protocols that help automate communication between client and server; see the sidebars " Corba and IIOP
" and " Remote Method Invocation
" for more details.
Step 3: Testing and tuning
Once you've converted the software, traditional issues about its architecture will arise. Performance, reliability, and security will be three of your biggest problems.
The article entitled "A New Way to Query GISs on the Web" by Serena Coetzee and Judith Bishop compares spatial queries for geographic information systems using different approaches: executing native C/C++ GIS APIs locally using the Java Native Interface, and using Remote Method Invocation remotely for distributed-object execution from a Java middleware server. In addition, Coetzee and Bishop create an API similar to JDBC for querying spatial databases (see the " JDBC
" sidebar for more information). The authors show that one key advantage of using RMI over JNI is that RMI can run in a Java applet, thus allowing for spatial querying in the client Web browser. Their statistics support the view that executing GIS queries locally gives superior performance over executing distributed queries via the Web.
Significantly, in the distributed model the authors use JNI with RMI to execute native C/C++ GIS query APIs provided by third-party vendors. By contrast, the authors use JNI with RMI to execute GIS C/C++ APIs at the Java middleware server. Corba allows interoperability among languages and is integrated into Netscape 4.0. Using Corba would eliminate the need for JNI at the server side; the server could handle GIS requests using C/C++ and Corba.
In the article entitled "An OO Database Migrates to the Web," authors Maria A. Cobb, Harold Foley III, Ruth Wilson, and Kevin B. Shaw discuss the development of a Web-based system that lets users view digital mapping data. They used an object-oriented database to store mapping information and Corba to distribute the database objects to Web clients. The stored data includes the Digital Nautical Chart, the World Vector Shoreline Plus, the Vector Smart Map, and the Urban Vector Smart Map. Applets request information from a Smalltalk server, which passes complex objects back and forth. The article details the process by which the system is put together, explaining the architecture, Java client, Corba, Web integration, and testing.
Even though OO databases have been around for many years, industry still does not use them heavily. This article does a good job identifying a database architecture and model in which OO technology can be used. It also discusses integrating an OO database with Corba, which makes objects available in a distributed system over the Web.
Finally, the authors describe the rationale for and implementation of the design decisions they made, and how to integrate these decisions to achieve project goals. Their step-by-step analysis of each component in the architecture is especially helpful.
has taught computer science at the University of Southern California since 1973 and is currently chair of that department. He has also taught at the University of Wisconsin, Cornell University, MIT, and the Technion. His research deals with computer-based systems for supporting software developers. He has served as associate editor of the Communications of the ACM
and associate editor of the Transactions on Mathematical Software
.Horowitz earned his MS and PhD in computer science from the University of Wisconsin, Madison, and his BS in mathematics from Brooklyn College. He is a member of the IEEE Computer Society and the ACM.