, University of Southern California
Pages: pp. 18-21
Abstract—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:
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
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.
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.
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.
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.
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.
The Common Object Request Broker Architecture is a specification for creating, distributing, and managing distributed program objects across a network. Corba was developed by a consortium called the Object Management Group, which currently includes over 500 member companies. Both ISO and X/Open have sanctioned Corba as the standard architecture for distributed objects. Corba 2.0 is the latest version.
The object request broker is an essential concept in Corba. Given a network of clients and servers on different computers, ORB support means that a client program, which is treated as an object, can request services from a server program or from another object without having to understand where the server is in the network or what the interface to the server program actually is. As with all client/server programs, ORBs assume there is a server that waits for a request, receives it, and responds.
The interface they use, the General Inter-ORB Protocol (GIOP), is implemented across several layers of the Open Systems Interconnect protocol. The most important mapping of GIOP is IIOP, an object-oriented protocol that enables distributed programs written in different programming languages to communicate over the Internet using the Transmission Control Protocol. Besides TCP, other possible transport layers include IBM's Systems Network Architecture and Novell's IPX, and implementations for all of these exist.
When a client makes a request to a server in the network, it must have an address for the server, a URL for example. In Corba this address is known as the Interoperable Object Reference, or IOR. Using IIOP, part of the address is based on the server's port number and Internet Protocol (IP) address. In the client's computer, a table can be created to map IORs to easier-to-use proxy names. The GIOP lets the program connect with an IOR and then send requests to it. When appropriate, servers send replies. A common data representation provides a way to encode and decode data so that it can be exchanged in a standard way.
A competing vision of distributed objects and their intercommunication comes from Microsoft in its Distributed Component Object Model (DCOM). Figure A shows the major elements of Microsoft and Sun JavaSoft solutions for distributed objects.ADistributed object solutions: Sun's Java versus Microsoft's DCOM.
Related Corba and IIOP Web sites include
Related articles and white papers on interoperability are available from the TU Distributed Systems Group at http://research.iphil.net/Corba/sp-interop.html.
To download the Corba 2.0/IIOP Specification, go to http://www.omg.org/corba/c2indx.htm.
Remote Method Invocation, developed by Sun Microsystems' JavaSoft division, lets programmers create distributed Java-to-Java applications in which the methods of remote Java objects are invoked from other Java virtual machines, possibly on different hosts. A Java program can call a remote object once it obtains a reference to that object, either by looking it up in the naming service provided by RMI or by receiving the reference as an argument or return value. A client can call a remote object in a server, and that server can also be a client of other remote objects. Using object serialization, RMI can marshal and unmarshal parameters. It supports true object-oriented polymorphism.
RMI Web sites include
JDBC (Java Database Connectivity) is an application program interface specification for connecting Java programs to databases. Such APIs let you encode access request statements in Structured Query Language that are then passed to the program managing the database. It returns the results through a similar interface. JDBC is similar to Microsoft's Open Database Connectivity (ODBC) and, with an additional program, the two can be connected.
There are two interface levels to JDBC. In addition to the main one, there is also an API from a JDBC manager that in turn communicates with individual database product drivers. These drivers are supplied by the vendor or third parties. A JDBC network driver runs in a network environment.
When accessing a remote database through a network, JDBC takes advantage of the Internet's file-addressing scheme, and a file name looks much like a Web page address.
JDBC specifies a set of object-oriented programming classes for the programmer to use in building SQL requests. An additional set of classes describes the JDBC driver API. The most common SQL data types, such as date and time, are mapped to Java data types. The API provides for implementation-specific support for transactional requests and the ability to commit or roll back to the beginning of a transaction.
Sun Microsystems' JDBC Database Access API, with pointers to a FAQ and free software, is at http://java.sun.com/products/jdbc/.