Migrating from legacy applications

With IT becoming the spine of business processes, many companies are urged to move away from their legacy applications and jump right into the new technologies, to take advantage of the rich GUI capabilities of current desktops, client/server computing and the Web. However, most companies are still tied to their (mainframe) legacy systems, and the cost of (re)development is in general too high.

slide: Three-tier architecture

As phrased by [Legacy], what they need is an unobtrusive method of integrating terminal-based (legacy) software with newer technologies, to provide the existing information and services with some new (GUI and Web-based) clothing.

In slide legacy, it is depicted how such an integration might be achieved with a three-tier architecture employing a terminal emulation or screen-scraping API for encapsulating the legacy objects, and a HTTP server to deliver the functionality to a (thin) Web client. (Information about the Legacy Object Framework can be found at www.yrrid.com .)

The advantage of a three-tier solution is the decoupling of the legacy application from both GUI functionality and (middleware) business logic. The legacy object modeling, which reflects the business logic, is taken care of in a middleware layer, to allow for thin or ignorant clients. In [Legacy], alternative solutions are discussed as well, including CORBA-based three-tier solutions as well as a variety of two-tier architectures with fat clients that carry all the knowledge about the business logic underlying the legacy application themselves. In comparison, three-tier solutions are to be preferred, since they allow for better maintenance. Nevertheless, according to [Legacy], the development effort is significantly higher.

Discussion

At ASZ/GAK, the IT section of a large social security organization in the Netherlands, students of the Vrije Universiteit have been involved in projects aimed at developing a new information infrastructure. There we studied intensively the three tiers and in particular the boundaries between these tiers, notably the GUI/Business Objects boundary and the Business Objects/Database boundary, using Java, CORBA, (D)COM and proprietary middleware. Generalizing, our conclusions thus far are that decoupling is much harder to achieve than we expected. For example, defining transactions using business objects seems to require more knowledge of the database backend than is desirable. Also, it seemed necessary to replicate much of the business logic inherent in the database. And, defining user interaction with business objects in a purely abstract fashion, that is independent of an actual interface technology, proved to be difficult as well.

For an organization such as ASZ/GAK, migration is necessary, simply because the risk of an abrupt transition is too high. This may also explain why the IT staff of ASZ/GAK who were responsible for maintaining the system were at first not too eager to experiment with the new technologies. Our experiments, however, convinced them that there is hope for the future.

[] readme course(s) preface I 1 2 II 3 4 III 5 6 7 IV 8 9 10 V 11 12 afterthought(s) appendix reference(s) example(s) resource(s) _

You may not copy or print any of this material without explicit permission of the author or the publisher. In case of other copyright issues, contact the author.