A METHOD FOR INTEGRATING LEGACY SYSTEMS WITHIN DISTRIBUTED OBJECT ARCHITECTURE

Transcription

1 A METHOD FOR INTEGRATING LEGACY SYSTEMS WITHIN DISTRIBUTED OBJECT ARCHITECTURE Matjaz B. Juric, Ivan Rozman, Marjan Hericko Institute of Informatics, University of Maribor, Faculty of Electrical Engineering, Computer and Information Science, Smetanova 17, SI-2000 Maribor, Slovenia, Key words: Abstract: distributed object architectures, legacy integration, CORBA The ability of a new technology to reuse legacy systems is very important for its economic success. This paper presents a method for integrating legacy systems within distributed object architectures. The necessary steps required for integration are defined. It is explained how to define object interfaces. A detailed overview of how to implement the wrappers is given. The paper also answers the question which distributed object model is most suitable for legacy integration. Therefore a decision model is defined and the evaluation results are presented. 1. OVERVIEW Distributed object technology is important for building new-generation information systems. It extends object technology with the power of client/server architecture. From the technological viewpoint the distributed object technology provides a very strong foundation for modern information systems [3, 15]. When looking at a technology from the economic viewpoint, the success of it is determined by the extent of its adoption in the companies. Only here will the potential economic rewards justify the investment and risk. However, if the technology requires rewriting legacy applications, the investment will be too great and the economic benefits too far downstream for most companies to proceed. Therefore it is very important for the distributed object technology to provide ways to reuse the legacy assets. method is outlined in Figure 1. There are eight general steps required. The main focus of this paper will be on steps six, seven and eight. Investigating Scenarios (1) Doing the Use Cases (2) Defining the Analysis Model (3) Defining the Interfaces (6) Obtaining the Design Model (5) Implementing Wrappers (8) Analyzing Existing Applications (4) Choosing the Technology (7) 2. GOAL The main goal of this paper is to present a method for integrating legacy systems within distributed object architecture. The proposed Figure 1: The general outline of the method The steps one, two, three, four and five have been discussed in pervious papers [5, 6, 7]. Especially steps one, two, three and five are

2 2 covered by many authors. Some of them are [1, 2, 4, 12, 13, 16]. In this paper we will focus on the definition of the interfaces (step six), on choosing the right technology (step seven) and on the actual implementation of the wrappers (step eight). The article is organized as follows. In section 3 we give a definition of legacy systems. In section 4 we describe the legacy integration and how to define the interfaces. In section 5 we discuss the three most important distributed object architectures and in section 6 we present a decision model for choosing the appropriate architecture. In this section we also present evaluation results. In section 7 we present the detailed method for implementing object wrappers. The most important contributions of this paper are: S Praxis proven method for integrating legacy systems within distributed object architecture. S Precisely defined method for implementing object wrappers using distributed object architecture. S A decision model for choosing the appropriate architecture. S An evaluation of the most important distributed object architectures and CORBA implementations. 3. LEGACY SYSTEMS The term legacy system in this paper points to any system that, regardless of age or architecture, conforms to the following conditions: S has existing code, S is useful today, S is in use today, S the architecture of the system is not distributed and object oriented. Accordant to this definition there are two big sets of legacy systems: S traditional mostly mainframe based systems and S systems written in modern languages (C, C++, Smalltalk, etc.), PC-based systems, client/server systems and personal productivity tools. The majority of legacy systems were designed to support the needs of individual functional business domains, not those of the entire enterprise. Such systems have a limited focus and are unable to grow or to evolve easily. Large amounts of data is also residing in legacy databases. Another huge problem is the unavailability of source code for many legacy systems, which has been lost or destroyed, mostly accidentally. 4. LEGACY INTEGRATION The objective of legacy integration is to take advantage of a legacy system s information and code when developing enterprise architectures. Legacy systems must be able to cooperate with other legacy and newly developed systems. Repartioning legacy systems into domains able to cooperate among themselves requires: S understanding the semantics contents S and usage patterns of the systems and implementing abstract interfaces that make the semantic contents and usage patterns available in other domains. The problem that makes it difficult to reuse legacy systems in distributed object environment is that legacy applications do not look like distributed objects. And so the challenge becomes encapsulating applications to collectively implement reusable»virtual distributed objects,«where operations of an object type might be implemented by different applications (Figure 2). To encapsulate legacy applications, focus needs to be on the design of object interfaces, rather than on applications. Integration with wrapping makes legacy systems look like distributed objects. Clients can use legacy systems as any other distributed object. Client does not care and does not have to care whether the object it uses is wrapped legacy application or a new generation system. Integration is also useful for decomposing and decoupling large legacy systems into separate components. Each component can have

3 3 its own wrapper assuming that the system s architecture supports it. This allows reusing and upgrading each component independent of others. Dividing legacy systems into components permits conquering them incrementally. Enterprise Network with Object Request Broker New Generation System Integrated Legacy System Figure 2: Integrating legacy systems 5. DISTRIBUTED OBJECT ARCHITECTURES The most important distributed object architectures today are: S OMG CORBA (Object Management Group Common Object Request Broker Architecture), S Microsoft DCOM (Distributed Component Object Model) and S Java RMI (Remote Method Invocation). All architectures share the same basic concepts [11, 14], although they differ in details. It is important to understand, that CORBA is not a product. It is a specification which is used by several software vendors to deliver their CORBA-compliant products. Different CORBA implementations are Iona Orbix, Inprise Visibroker, BEA ObjectBroker, Expersoft PowerBroker etc. Microsoft DCOM and Java RMI on the other hand are functional products. New Generation System In order to enable legacy integration the most important criteria for a distributed object architecture is support for different operating systems and different programming languages. In Table 1 the operating systems availability for these three architectures is shown. Because CORBA is implemented by different vendors it supports practically all important platforms. The interoperability between different implementations of CORBA is guaranteed. CORBA Windows (all versions), Mac, Solaris, SunOS, SGI, HPUX, OS/2, SCO, Irix, Digital Unix, AIX, VMS, VxWorks, QNX, MVS, OS/400, psos, Cray, Linux 1 DCOM Windows NT 4, NT 5 (alias 2000 announced), 95, 98 Java RMI All with JVM (Java Virtual Machine) support Table 1: Operating system support In Table 2 support for different programming languages is listed. CORBA C, C++, Java, COBOL, Smalltalk, Ada 2, PLI (announced) DCOM native support for C, C++, Java; other languages and tools through OLE Automation Java RMI Java 3 Table 2: Programming language support 1 Only the most important platforms are listed. Support for several other less known operating systems is available, too. 2 Listed are only languages for which the support is standardised. Several other languages including Objective C, Perl, Delphi, Eiffel, Common Lisp, Scheme, etc. are supported [10]. 3 Java provides limited support for C++ through JNI (Java Native Interface), which is rather difficult to manage and not supported by all JVMs.

4 4 6. EVALUATION 6.1 Criteria To be able to evaluate different architectures for their suitability for legacy integration we have designed a decision model that includes the following criteria: c 1 c 2 c 3 c 4 c 5 c 6 c 7 c 8 c 9 Criteria Number of operating systems supported Number of programming languages supported Maturity Language independent wire protocol The ability to launch servants automatically Persistent object references Dynamic server implementations Ease of learning Ease of development Scale actual number actual number presence on the market in years 1 = yes, 0 = no 1 = yes, 0 = no 1 = yes, 0 = no 1 = yes, 0 = no note between 0 and 1 note between 0 and 1 Table 3: Criteria for distributed object architecture evaluation Number of operating systems supported is one of the most important criteria. Only an architecture which supports a large number of them can be successful in integrating diverse applications. Number of programming languages is important because as we will see it is more effective if the integrated legacy system s language is directly supported by the distributed object architecture. Maturity is an often underestimated category which can tell about reliability. Language independent wire protocol assures that the selected distributed object architecture will be able to become the major infrastructure and could be used as a back-bone. The ability to launch servants automatically has an impact on system resources [9]. It is important especially when some systems are rarely used. In this context we can not avoid the persistent object references which can simplify the binding process and eliminate the naming services overhead [8]. Dynamic server implementations are very useful when building changeable or universal servers [10]. The ease of learning assessment contains information about the clarity of the object model, the documentation and complexity. The assessment is based on a research published in [6, 7]. Ease of development contains information about the additional steps necessary to allow distribution and development tools support. The assessment is based on a research published in [6, 7]. 6.2 Utility Function We have defined the following utility function: X L L M L = + $ M 1 L M L= L= $ L N N= 1 X = PD[ M= Z ( X ) M $ where the symbols are: S u maximum utility S u j utility of alternative j S c i criteria i as specified in Table 3 S A j alternative j S w i weight of criterion i S N total number of alternatives The result u has an interval of [0, 1]. From the utility function it can be seen that all criteria Z

5 5 are within interval [0, 1]. The first three are normalized during the calculation. 6.3 Results The utility function is very general and can be easily modified to cover specific needs. We have evaluated the three important distributed object architectures and the results are presented in Table 4. c w CORBA DCOM Java RMI c ,0 4,0 16,0 c ,0 3,0 1,0 c ,0 3,0 2,0 c 4 8 1,0 0,0 0,0 c 5 5 1,0 0,0 0,0 c 6 3 1,0 1,0 0,0 c 7 3 1,0 0,0 0,0 c 8 7 0,6 0,3 0,9 c ,7 0,7 1,0 u j 0,67 0,25 0,31 Table 4: Evaluation matrix and results From the Table 4 we can see that u = 0,67 by j = 1. The architecture with the highest assessment is CORBA. We have already mentioned that there are different implementations of CORBA architecture. The same decision model can be used for selecting the most appropriate implementation. In Table 5 a comparison between Iona Orbix, Inprise Visibroker, BEA Objectbroker and Expersoft Powerbroker is presented. Weights (w j ) are the same as in Table 3. It can be seen that best suited for legacy integration is Iona Orbix. c BEA Iona Inprise Expersft c 1 8,0 4 18,0 5 8,0 6 6,0 7 4 Solaris, HP-UX, AIX, DEC, NT, W95/98, VMS, MVS 5 Solaris, HP-UX, SGI, AIX, DEC, NT, W95/98, W3.1, OS/2, Mac, MVS, VMS, QNX, LynxOS, Unixware, Ultrix, SunOS, Sinix 6 SunOS, Solaris, HP-UX, AIX, DEC, SGI, NT, W95/98 7 Solaris, HP-UX, AIX, DEC, NT, W95/98 c 2 3,0 8 5,0 9 4,0 10 3,0 11 c 3 8,0 5,0 6,0 3,0 c 4 1,0 1,0 1,0 1,0 c 5 1,0 1,0 1,0 1,0 c 6 1,0 1,0 1,0 1,0 c 7 1,0 1,0 1,0 1,0 c 8 0,9 0,9 1,0 0,9 c 9 0,7 0,7 1,0 0,8 u j 0,49 0,54 0,52 0,44 Table 5: Comparison of CORBA implementations in terms of legacy integration 7. WRAPPING METHOD We have defined a wrapping method for bridging the application architecture s abstract interface and legacy systems. On one side, the wrapper presents systems with an abstract interface. On the other side, the wrapper communicates with legacy systems using their existing facilities (Figure 3). Object wrappers and their abstract interfaces present a system view that is implementation independent. Keeping the abstract interface constant keeps other systems from being aware of changes and eliminates the need for modifying these other systems. Client objects are unable to determine how server objects are implemented. The original legacy systems are often constructed from low level statements that have nothing to do with the business and its processes. Object wrappers raise the level of abstraction to the level of business objects. Wrappers encapsulate the details of which systems contribute to satisfying requests and the methods by which they are satisfied. All accesses, including direct and indirect accesses to state variables, are performed through interface methods. CORBA and its Interface 8 C, C++, Java 9 C++, Smalltalk, Ada, Java, COBOL 10 C++, Smalltalk, Java, COBOL (announced at the time of writing) 11 C++, Smalltalk, Java

6 6 Definition Language (IDL) allows encapsulating systems that hide differences in programming languages, systems locations, operating systems, algorithms and data structures. /HJDF\ 6\VWHP Figure 3: Object wrapper Figure 4 shows the required steps for implementing an object wrapper. Before the first step can be done, the exact functionally of the legacy systems must be understood and functions being wrapped should be identified. It is expected that a design model exists. Making interface definitions without good understanding of legacy application is impossible. The interface should: S support all features of the legacy system, S be at a high level of abstraction, S fit into the information architecture of S Connection Code the enterprise, be designed with the future in mind, that means it should be good enough to satisfy future requests when reengineering of the application is done. It is important to understand that all communication between the wrapped legacy system and the outer world goes through the interface. The clients depend on the interface and not on the implementation. Therefore it is easy to change the implementation but not the interface. It is important to know that interface can be easily extended but existing methods and attributes can not be changed. If they are changed, all the systems which use this interface must be updated. In first step the defined interfaces are implemented in Interface Definition Language. IDL is used for definition of interfaces only. It Interface Object Request Broker is not an implementation language, which is why it can be learned in only a fraction of time usually needed to learn a new programming language. When IDL interfaces are defined and implemented, they have to be mapped into a specific programming language. Mapping is done with the IDL compiler for a specific language. The compiler creates all the code needed for an application to connect to the object request broker, to register and expose their functionality, and to receive requests and send results. This code is called skeleton code and is needed on the server side. IDL compiler also generates stub code, which is used by clients for connection with the server application. Stub and skeleton code can be generated in different programming languages, according to the needs. In the next step the functionality of the interface methods is implemented. It is necessary to bind interface methods to the corresponding functions and procedures. It depends from the structure and the programming language of legacy application if this connection can be done easy. If the structure of the application is similar to the interface being connected to, only a small amount of code is needed for interconnection. Otherwise it may be necessary to call several functions and procedures of the legacy application and possibly make some operations with the results before they are suitable. In both cases the type conversion has to be done. CORBA uses certain specific data types and it should be studied carefully how CORBA types map into the native language types and which must be converted. The conversion is not problematic, because methods exist for all types that differ. Conversion methods are included as a part of every CORBA product. Greater problems arise if mapping of IDL into the language in which the legacy application is developed, is not supported. Then a way how to connect a supported programming language (C++ for example) with the language of the legacy application should be found. In most cases this can be accomplished more or

7 7 Implementation of the interfaces in IDL,V VRXUFH FRGH DYDOLDEOH" Choosing an implementation language for wrapper <(6 'RHV PDSSLQJ,'/! SURJUDPPLQJ ODQJXDJH H[LVW" <(6 &KRRVLQJ DQ LPSOHPHQWDWLRQ ODQJXDJH IRU ZUDSSHU Mapping IDL -> programming language 0DSSLQJ,'/! SURJUDPPLQJ ODQJXDJH,PSOHPHQWLQJ WKH FRPPXQLFDWLRQ EHWZHHQ ZUDSSHU DQG OHJDF\ DSSOLFDWLRQ IRU H[DPSOH ZLWK OLQNLQJ RI REMHFW ILOHV 0DSSLQJ,'/! OHJDF\ SURJUDPPLQJ ODQJXDJH &RQQHFWLRQ RI LQWHUIDFH PHWKRGV ZLWK OHJDF\ FRGH 7\SHV FRQYHUVLRQ &RQQHFWLRQ FRGH Implementing the communication between wrapper and legacy application through API, screen or direct data access &RPSLOLQJ WHVWLQJ XVLQJ WKH ZUDSSHU Figure 4: Implementing object wrappers less painful by linking object files produced by each compiler. For several legacy applications source code has been lost or destroyed over the years. When no source code is available, there are several possibilities: we can access legacy files and databases directly. In such case great attention has to be paid on data integrity. If the legacy system has a reasonably robust API, we can use it to perform most functions. If even this is not possible, we can use screen scraping. Typing can be simulated to add and to request

8 8 information from legacy systems. A single object wrapper can use multiple screens and even multiple systems to provide its services. When all the problems have been mastered, the code has to be compiled and tested. The whole process is graphically presented in figure REENGINEERING Over time the functionality of the legacy applications can be progressively reversed into the corresponding distributed objects until the original code is redundant. Selected components can be reengineered step by step as business needs dictate and when resources are available. This approach reduces cost, enhances maintainability, increases performance, and increases congruency between the system s model and the information architecture. When the legacy systems are encapsulated with interfaces, parts of the systems can be reimplemented without the need to change other new or legacy systems. Changes to individual components do not affect other components. 9. CONCLUSION Legacy systems are important for current business operations and represent assets that businesses can not afford to write off. In this paper a method for integrating legacy systems within distributed object architectures has been presented. Several topics were discussed, among them how to define object interfaces, how to choose the appropriate distributed object architecture and implementation and how to implement object wrappers. In the article a wrapping method is defined, a decision model for selecting a distributed object model is presented and evaluation results are listed. Therefore the article contributes to the general understanding of legacy integration, gives a solid basis for making a decision about the underlying distributed object architecture and presents a praxis proven wrapping method. REFERENCES [1] Booch Grady, Object Oriented Analysis and Design with Applications, The Benjamin/Cummings Publishing Company, 1994 [2] Donald E. Rimel Jr., Ronald C. Aronica,»Leveraging Legacy Assets«, First Class, Dec 1996, OMG [3] Guttman M., Matthews J. R. (1995),»The Object Technology Revolution«, John Wiley & Sons, Inc., USA [4] Jacobson Ivar, The Object Advantage - Business Process Reengineering with Object Technology, Addison Wesley Publishing Company, 1994 [5] Juric B. Matjaz, Zivkovic Ales, Rozman Ivan, Are Distributed Objects Fast Enough, JavaREPORT, SIGS Publications, May 1998 [6] Juric M. B., Hericko M., Rozman I. (1997),»CORBA - objektni model porazdeljenega procesiranja«, Uporabna informatika, jan/feb/mar 1997 [7] Juric Matjaz Branko, Hericko Marjan, Rozman Ivan: Legacy systems in distributed object architecture, CASSAM - Computer aided software support and maintenance / 5th International conference on retechnologies for information systems, December 1997 [8] Object Management Group, Common Facilities Architecture, Revision 4.0, November 1995 [9] Object Management Group, CORBAservices: Common Object Services Specification, Revised Edition, July 1997 [10] Object Management Group, The Common Object Request Broker: Architecture and Specification, Revision 2.2, February 1998 [11] Orfali R., Harkey D., Edwards J.,»Intergalactic Client/Server Computing«, Byte, Apr 1995, McGraw- Hill Inc. [12] Rational Software Corp., Rational Objectory Process 4.1, September 1997 [13] Rumbaugh James, Object Oriented Modeling and Design, Prentice Hall, 1991 [14] Soley R. M., Ph.D. (1995),»Object Management Architecture Guide«, OMG, John Wiley & Sons, Inc., Revision 3.0, Third Edition [15] Vinoski Steve, CORBA: Integrating Diverse Applications Within Distributed Heterogeneous Environments, IEEE Communications Magazine, Vol. 14, No. 2, February, 1997 [16] Wilke George, Object-Oriented Software Engineering. The professional Developer s Guide, Addison-Wesley Publishing Company, 1993