Legacy System
Annals of Software Engineering 9 (2000) 293–313
293
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 defines 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.
1.
Motivation for encapsulation
Legacy software components can be jobs, transactions, programs, modules or procedures within existing application systems which are more than five 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 fixed 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 definite need to reengineer existing systems in order to satisfy the needs of modern business practices. It is not possible to restructure
293
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 defines 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.
1.
Motivation for encapsulation
Legacy software components can be jobs, transactions, programs, modules or procedures within existing application systems which are more than five 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 fixed 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 definite need to reengineer existing systems in order to satisfy the needs of modern business practices. It is not possible to restructure
References: Aberdeen Group (1995), “Hewlett-Packard’s C++ SoftBench 5.0,” Aberdeen Group Report, Boston, MA. Antares Inc. (1996), “ObjectStar – A Product for Wrapping Legacy Databases,” Antares Alliance Group, Dallas. Brodie, M. and M. Stonebraker (1995), Migrating Legacy Systems, Morgan Kaufman, San Francisco, CA. DeLucia, A., G.A. DiLucca, and A.R. Fasolini (1997), “Migrating Legacy Systems Towards ObjectOriented Platforms,” In Proceedings of IEEE-ICSM-97, Bari, Italy, October, p. 122. Dietrich, W.C. (1989), “Saving a Legacy with Objects,” In Proceedings of OOPSLA-90, Addison-Wesley, Reading, MA. Gamma, E. et al. (1995), Design Patterns, Addison-Wesley, Reading, MA. Gossain, S. (1997), “Accessing Legacy Systems,” In Object Expert, London, March. Graham, I. (1995), Migrating to Object Technology, Addison-Wesley, Workingham, GB. IBM (1997), “A Survey of Object-Oriented Technology on MVS/ESA,” IBM International Technical Support Center Report GG24-2505-00, Poughkeepsie Center, New York. Jacobson, I. and F. Lindstrom (1991), “Reengineering of Old Systems to an Object-oriented Architecture,” In Proceedings of OOPSLA-91, ACM Press, New York. Jacobson, I. (1992), Object-Oriented Software Engineering, Addison-Wesley, Reading, MA. Leeb, G. and S. Molterer (1999), “Developing Reengineering and Reusing Enterprise Software Using a Business Object Approach,” to be presented at TOOLS-99, CBESD Transition Workshop, Santa Clara, July. Mattison, R. (1994), The Object-Oriented Enterprise, McGraw-Hill, New York. Molterer, K. (1999), “Erfahrung mit der Reengineering bestehender Systeme in BMW,” In Proceedings of GI-Workshop on Software Wartung & Reengineering, F. Lehnert and F. Ebert, Eds., GI Arbeitskreis 5, Bad Honnef. Mowbray, T. and R. Zahavi (1994), The Essential CORBA, Wiley, New York. OMG (1998), “Business Object Component Architecture (BOCA),” Proposal – Revision 1.1, OMG Document bom/98-01-07, London. Orfali, R., D. Harkey, and J. Edwards (1996), The Essential Distributed Objects Survival Guide, Wiley, New York. H.M. Sneed / Encapsulation of legacy software 313 Parodi, J. (1996), “Building Wrappers for Legacy Software Applications,” Digital Equipment Corp., Boston. Rugaber, S. and J. White (1998), “Restoring a Legacy – Lessons Learned,” IEEE Software 15, 4, 28. Sneed, H. (1996), “Encapsulating Legacy Software for Reuse in Client/Server Systems,” In Proceedings of WCRE-96, IEEE Press, Monterey, November. Sneed, H. (1997a), “Software Interface Reengineering,” In Proceedings of WCRE-97, IEEE Press, Amsterdam, October. Sneed, H. (1997b), “SoftWrap – ein Tool f¨ r die Kapselung vorhandener Assembler, PLI und COBOL u Programme,” HMD Heft Nr. 194, Stuttgart, Germany. Sneed, H. (1998), Objektorientierte Softwaremigration, Addison-Wesley, Bonn. Souder, T. and S. Mancordis (1999), “Legacy – A Tool for Securely Integrating Legacy Systems into a Distributed Environment,” In Proceedings of IEEE-WCRE-99, Atlanta, October, to appear. Taylor, D. (1995), Business Engineering with Object Technology, Wiley, New York. Verhoef, C., A. Sellink, and H. Sneed (1999), “Restructuring of COBOL/CICS Legacy Systems,” In Proceedings of 3rd European Conference on Software Maintenance and Reengineering, Amsterdam, March, p. 72. Wallner, K. and E. Wallace (1996), “Simulated Evaluation of the Object Management Group’s (OMG) Object Management Architecture (OMA),” ACM SIGPLAN Notices 31, 10, 168. Winsberg, P. (1995), “Legacy Code – Don’t Bag it, Wrap it” Datamation, May. Yourdon, E. (1997), “Distributed Computing,” American Programmer 10, 12.