Encapsulation of legacy software: A technique for reusing legacy software components Harry M. Sneed
Prellerweg 5, D-82054 Arget, Bavaria, Germany E-mail: Harry.Sneed@T-Online.de
The following paper reviews the possibilities of encapsulating existing legacy software for reuse in new distributed architectures. It suggests wrapping as an alternative strategy to reengineering and redevelopment. It then deﬁnes the levels of granularity at which software can be encapsulated before going on to describe how to construct a wrapper and how to adapt host programs for wrapping. Some wrapping products are discussed and the state of the art summarized. The advantage of wrapping over conventional reengineering is the low cost and even lower risks involved. This is the driving force in the search for improved wrapping technology.
Motivation for encapsulation
Legacy software components can be jobs, transactions, programs, modules or procedures within existing application systems which are more than ﬁve years old. Usually these systems are running on a mainframe and are based on an outdated technology such as hierarchical or networked database systems and transaction-oriented teleprocessing monitors with ﬁxed panels. Although the technology with which they have been implemented is out of fashion, the application systems themselves are performing critical business functions in an acceptable and reliable manner. It took a lot of time and effort to develop these systems and specially to test them. Therefore, it is irrational to discard them completely, just because they do not meet current technical requirements. Typical candidates for encapsulation as business objects are batch jobs, online transactions and user subroutines as depicted below. On the other hand, there is a deﬁnite need to reengineer existing systems in order to satisfy the needs of modern business practices. It is not possible to restructure business processes without restructuring the computer process behind them [Taylor 1995]. If business processes are distributed to ensure more ﬂexibility and to delegate responsibility then the supporting computer systems must also be broken up and distributed. Very often this leads to a new hardware architecture with client and server computers as well as a central host computer. On the software side it leads to a new user interface with a different work ﬂow control and to a distributed relational or object-oriented database system, i.e., the underlying hardware is replaced as well as the software frontend and backend [Brodie and Stonebraker 1995]. © J.C. Baltzer AG, Science Publishers
H.M. Sneed / Encapsulation of legacy software
Figure 1. Legacy software components.
The question which comes up here is whether it is necessary to replace all of the existing software. Some will say yes, if you are going to replace the user interface and the database system, you might as well replace it all. Others will say no, you should keep as much of the existing software as possible and to reuse it in the new environment. The correct answer depends on the quantity, complexity and quality of the existing software as well as on the time and resources of the user. If the user has tight time or budget constraints, he may have no other choice but to reuse the existing programs. On the other hand, if the business logic of the old software is only a small layer of code between the presentation and access logic, then it might as well be replaced together with the presentation and access layers. So there is no cut and dried answer to this question. It is context dependent [Mattison 1994]. In practice, it depends on the ratio of business logic relative to the presentation and access logic. In order to justify the effort involved in reusing the existing programs, their business logic functions must be a signiﬁcant part, i.e., there must be enough business logic available to...