A Metho dology for Migration of Legacy Applications to Distributed Ob ject Management E. R. Hughes R. S. Hyland S. D. Litvintchouk A. S. Rosenthal A. L. Schafer S. L. Surer The MITRE Corp oration Bedford, MA 01730-142 0 Many organizations wish to con gure and recon g- Abstract ure systems from reusable, replaceable comp onents, Much of today's software development involves each of which provides a sp eci c service. In older reengineering legacy applications, but the bulk of or current systems here called the legacy systems, research and tools address new software develop- application-sp eci c co de is entwined with co de that ment. The Distributed Object Management Integra- implements rather generic services, such as map dis- tion System DOMIS, 1993-96 project investigated play, data replication, or event noti cation. As a re- how legacy applications can be incremental ly modi ed, sult, this generic functionality is unavailable for use or migrated, by using distributed object management by other applications, and must b e duplicated and DOM technology. This paper describes a methodol- maintained separately within each application. We ogy for such migration using DOM technology. use the term \duplicated" lo osely; in extreme cases our metho dology might b e applied to a legacy imple- 1 Intro duction mentation and services which di er in terms of sp eed, 2 Our domain is command and control C systems, accuracy, and p ossibly even b ehavior. However, more consisting of large amounts of legacy software that similar duplicated functionality makes the metho dol- have b ecome very dicult to change and extend. We ogy more attractive. have found that a DOM architecture such as the Com- Our approach to migration is to de ne a set of mon Ob ject Request Broker Architecture CORBA target services, many of whichmay b e encapsula- [3] reduces the cost and risk of reengineering i.e., tions of existing service mo dules, and to reengineer mo difying the source co de of systems within this do- legacy applications to rely on a common implemen- main. tation of these services. This approach alleviates the We b egan byinvestigating coarse-grained DOM en- need to maintain a customized implementation of the capsulation of legacy software, in whichentire ex- service in each system. Migration may o ccur in several ecutable applications are encapsulated as ob jects. phases, each of which encapsulates some functionality Coarsely encapsulated applications can b e accessed as a common service and eliminates some dep endence via DOM relatively indep endent of lo cation, platform, on the legacy services. Services are then invoked us- and programming language. We then reengineered ing a distributed request broker, preferably one that legacy software to employ ner-grained encapsula- conforms to a DOM standard. tion, replacing duplicated functionality with ob ject- By service,we mean a conceptually coherent set oriented invo cations of a reusable common service. of functions, indep endentofany implementation. A We p erformed an exp eriment to reengineer a stand- service interface can b e discussed even if the system alone legacy application, implementing its map display currently contains no software that actually supp orts functionalitybyinvoking a b etter, o -the-shelf, DOM- the interface. An interface is typically sp eci ed in an encapsulated map display service. Coarse-grained en- Interface Description Language IDL; suchaninter- capsulation is relatively easy to apply to a legacy face is reasonably human-readable and can b e com- application, so this pap er concentrates on the more piled into executable co de. challenging migration of existing systems using ner- grained encapsulation. We also describ e our lessons A legacy service is an implemented service within ab out the e ort and risk involved. a legacy system. Frequently a legacy service will have p o orly do cumented dep endencies and back-do or com- 2 Finer-Grained Encapsulation munications. Typically, a legacy service has di erent The purp ose of our metho dology is to migrate a functional b oundaries than the services available to- legacy application to use the target functionality made day.For example, the develop ers of our legacy system available by new services created from b est-of-breed did not consider map display capability as a replace- implementations. The legacy functionality of the ap- able service but rather as an integral part of airspace plication and its asso ciated maintenance costs are con ict detection. eliminated. The metho dology has an obvious exten- Some of the services to b e extracted may b e used sion for migrating multiple legacy applications at once, across the industry, while others may b e sp eci c to the whichmay reduce the total cost of the migrations. 2 C problem domain. When two or more applications Figure 1 illustrates our approach. Here, the strip ed have implemented very similar functionality,itmay boxes represent duplicated functionality, whichisbe- b e advantageous to turn this functionalityinto a com- ing removed from legacy applications A and B and re- mon service. Then, one can make a server function placed with invo cations of a DOM-based service con- f accessible to outside clients by providing a wrapper structed by encapsulating co de from B. This gure function that can b e invoked by a DOM request and assumes that there is not already an established stan- that invokes f. dard service, and that the strip ed mo dule in B is appropriate for reuse as a service. The arrows from 1.1 Structure of this Pap er legacy mo dules to the DOM framework illustrate the We b egin by reviewing DOM technology and the evolution emb o died in our metho dology. The legacy b ene ts it provides for distributed applications. We co de for duplicated functionality in A is retired and then present our metho dology and discuss the steps no longer maintained as part of the migration e ort. involved. Finally,we give some conclusions and fur- 2.1 Our Exp eriments with Finer-Grained ther discussion. Encapsulation 1.2 DOM Technology and Bene ts We p erformed two exp eriments motivated bya We assume that the reader has a working famil- suite of Air Force planning systems, collectively com- iarity with DOM software; intro ductory information prising many millions of lines of co de. In b oth, the can b e found in [3] and [4]. Our DOM software is a goal was to learn ab out migration, not to pro duce an commercial CORBA Ob ject Request Broker ORB, op erational system. The exp eriments attempt to pro- whichwe nd provides the advantages of: vide insight to the managers who plan acquisitions to upgrade these systems, and also to the engineers who platform and language indep endence might carry out the upgrades. The rst exp erimentwas brief, involving the map network lo cation transparency display service from the Airspace Planning System APS. This exp erimentwas terminated b ecause we increased fault tolerance the ability to transpar- concluded that APS was to o large and complex to ently restart services on demand reengineer with our resources, and b ecause map dis- play is not central to APS. reduced development e ort by reusing common The second exp eriment reengineered part of the services Airspace Decon iction System ADS, an application that provides spatial analysis and editing capabilities consistent do cumentation of interfaces to detect and repair con icts b etween air routes. Our goal was to replace the legacy map display functional- ity with brokered invo cations of a map display service. CORBA do es not sp ecify the level of granularity The map display capabilitywas selected b ecause it is for ob jects. Ob jects can b e entire systems, subsys- present in many military systems, improvements were tems, applications, services, real world ob jects planes, desired, it is imp ortant to ADS, and a new map dis- targets, etc., or programming ob jects. This exibil- play service was available to us. ity allows CORBA to b e used to integrate systems, bridging legacy and mo dern, ob ject-oriented software The ADS application currently provides its own im- development paradigms. Ob jects can b e integrated plementation of map display, in which airspace infor- with other ob jects at any level of granularity, includ- mation is overlaid on maps constructed from World ing ob jects that are encapsulations of entire legacy Data Bank I I data using a Graphical Kernel System systems. GKS graphics package. GKS is not a suitable basis ality of the application. In short, we found the migra- Enterprise Portfolio tion depicted in Figure 1 to b e infeasible for duplicated functionality which is closely tied to the user interface, hnologies do not supp ort in- Application A Application B partly b ecause DOM tec tegration of user interfaces. However, our approachis promising for other more limited forms of integration that are supp orted by DOM. A more radical approachmay b e preferable to the e underto ok. We tried to keep the main appli- RETIRE one w cation logic and replace a single service or, by ex- services provide evolve to services to use evolve tension, set of services. An alternativewould b e to start by obtaining a base of services|buying generic endors and encapsulating key parts of Methodology services from v the legacy application. One would then rewrite the legacy system using a mo dern framework e.g., Java- Beans or ActiveX. The following sections p oint out the advantages and risks for our metho dology, which can b e used to determine a go o d approach for a par- ticular migration pro ject.