COBOL2EJB : A Tool Generating Wrapping Component for CICS COBOL System

Transcription

1 COBOL2EJB : A Tool Generating Wrapping Component for CICS COBOL System Hyo-Taeg Jung, Moon-Soo Lee, Moon-Sub Song, Young-Jong Yang S/WContents Technology Department, ETRI 161 Gajeong-dong, Yuseong-gu, Daejeon, Korea. {htjung, mslee, senus, yjyang}@etri.re.kr ABSTRACT Today many researches about legacy system modernization are done because legacy systems are needed to perform accurate functionalities and to meet new requirements m a changing computing environment such as moving to on-line systems, client/server systems, internet, and e-commerce systems. Moreover as software component technologies as well as software reuse technologies including class libraries, design patterns, and software frameworks are much more developed and pervaded, legacy system modernization has been more important In this paper, we introduce a tool, called COBOL2FJB, supporting sequence of wrapping process as a one way of legacy system modernization COBOL2FJB analyzes CICS COBOL system and generates Enterprise JavaBeans(EJB) components to assist wrapping process. COBOL2EJB consists source code analyzer, visualizer for system understanding, RIB wrapper generator, and component tester. Keywords: legacy system, modernization, RIB component, CICS COBOL, wrapping 1. Introduction Nowadays many commercial and governmental organizations have tried their legacy systems to be able to perform accurate functionalities in new computing environments. According to the changing computing environments, the legacy system has to be continuously evolved. Legacy system evolution is a broad term that covers from adding a field in a database to system re-implementation The legacy system evolution has three categories: maintenance, modernization, and replacement[1]. -1-

2 Legacy system maintenance is an incremental and iterative process. Maintenance does not involve any change of system structure. Its defect is to increase cost with time because out- of-date technologies are difficult and expensive to update. Legacy system replacement is appropriate for the systems of which modernization is not possible or cost effective. Replacement is usually used to the systems that are undocumented, outdated, or not extensible. Its defect is that the new system should be tested and tuned repeatedly and should acquire some stability Legacy system modernization is to give legacy systems some changes such as system restructuring, functional enhancement, or new software attributes. Legacy system modernization can be classified into white- box modernization and black-box modernization White-box modernization requires a reverse engineering to acquire an overall understanding of the legacy system and needs some system or code restructuring. Black-box modernization involves examining the inputs and outputs of the legacy system to gain an understanding of the system interface. However, this is not an easy task Black-box modernization is often based on wrapping. Wrapping means to surround the legacy system with software layers that hide the complexity of the old system and export a modem interface. Legacy system modernization has several techniques such as user interface modernization, data modernization, and functional(logic) modernization[1]. User Interface modernization increases system usability and the most common method is screen scraping. Data modernization technology includes database gateway, XML integration, and database replication Functional(Logic) modernization involves CGI integration, object-oriented wrapping, and component wrapping. When we develop the code migration, the most important thing is to keep the legacy system fully functional at all times. Santiago et al. have introduced system modernization strategy as follows[2]: 1 Minimize development and development cost 2Support an aggressive yet predictable schedule. 3Maintain quality of interim and final products. 4Minimize risk. 5Meet system performance expectations. 6Maintain complexity at a manageable level. Legacy componentization meets some needs for reuse, integration, replacement; enhancement; and separation of concerns[3]. There are some methods for legacy componentization as follows: legacy migration, wrapping with component interfaces, legacy restructuring, legacy enhancement; integration via legacy interfaces, and integration via component interfaces[3]. We have designed and implemented a x~rapping component generating tool, called COBOL2EJB, that analyzes CICS COBOL system, identifies business logic, generates wrapping component; and tests its interface and performance. The overall organization of this paper is as follows. In section 2 we describe overall structure of COBOL2EJB. From section 3 to 6 we represent features of each subsystem. System environments are introduced in section 7. Conclusion and future works are -2-

3 presented in section System Overview COBOL2EJB generates EJB wrapping component by identifying business logic from IBM CICS COBOL system and generating EJB code. It also tests interface and performance of the component and returns test result COBOL2EJB consists source code analyzer, visualizer for system understanding, EJB wrapper generator, and component tester Figure 1 shows the overall structure of it. Figure 1 : Overall Structure of COBOL2EJB The process of generating wrapping component is as follows: First; COBOL2EJB accepts as input source CICS COBOL system including programs, map files, copybooks, and other related things, and analyzes input source. Second, using analyzed information, COBOL2EJB provides several graphs for program understanding. Third, COBOL2FJB identifies business logic, suggests candidate components, and generates EJB code. Finally, COBOL2EJB tests interface and performance of the component and returns test result 3. Source Code Analyzer -3-

4 COBOL system consists source programs, map files, copybooks, JCLs, and other related elements. Source code analyzer accepts COBOL system as input source, and generates parse tree, abstract syntax tree, and some kinds of tables. Analyzed information by source code analyzer is required for visualizing graphs and generating wrapping component Figure 2 shows the structure of source code analyzer. Figure 2 : Structure of Source Code Analyzer 4. Visualizer for System Understanding Visualizer for system understanding provides several graphs and increases understandability of the input system System flow graph and program reference graph provide information at system level. Call graph, control flow graph, structure chart; and variable reference graph provide information at program level. Source code browser and map pre-viewer browse source code and map file System Flow Graph System flow graph shows flow of logic existed between programs at system level. Its elements are source programs, map files, and transaction IDs. Users get information about not only relations between transactions and programs but also logical transaction flows between them. System flow graph shows on the upside in figure Program Reference Graph Program reference graph represents physical program structure at system level. It is composed of some elements such as map sets, copybooks, flat files, and databases. Program reference graph shows on the downside in figure

5 4.3. Call Graph Call graph describes calling/called relations between paragraphs existed m one program. The elements of call graph can be program and paragraphs. Calling/Called relations shows PERFORM or GOTO statements. Call graph shows on the right in figure 3. Figure 3 : System flow graph, program reference graph, and call graph 4.4. Control How Graph Control flow graph represents flow of statement in one paragraph. Figure in circle is line number, and diamond shape means IF statement Control flow graph shows ontheleftinfigure Structure Chart Structure chat mainly shows relations between paragraph and variables in one paragraph Its elements are programs, paragraphs, and variables. The arrow describes whether a variable is defined or used in a paragraph. Structure chart shows on the upside in figure 4. Figure 4 : Control flow graph, structure chart, and variable reference graph -5-

6 4.6. Variable Reference Graph Variable reference graph shows variable and paragraph that references the variable. It provides information about variable and related paragraphs. Variable reference graph shows on the downside in figure Source Code Browser and Map Pre-viewer Source code browser displays input source code through tree-shaped view Map pre-viewer shows map file that has information for display Source code browser and map pre-viewer show in figure 5. Figure 5 : Source code browser and map pre-viewer -6-

7 5. EJB Wrapper Generator EJB wrapper generator consists business logic identifier, EJB code generator, and component deployer Business Logic Identifier Though many methods and techniques for understanding and identifying business logic have been researched [4][5][6], verification as well as identification process is not easy task. Figure 6 : Sequence of identification process Identification process is as follows: First, business logic identifier classifies variables into three types such as input, output, and external variable. Second, users make decision the type of reusable business logic by assigning weighting value. Third, business logic identifier provides several programs and paragraphs with priority as candidate business logic. Fourth, users select programs and paragraphs. Finally, business logic identifier shows the selected paragraph using call wee, and automatically identifies reusable workflow that will become a wrapping component. In this case, business logic identifier performs impact analysis internally In figure 6 depicts the sequence of identification process. -7-

8 5.2. EJB Code Generator and EJB Deployer Interface of EJB component should be defined to generate FJB code. It can be defined by using information needed for displaying business logic. RIB code generator automatically generates record framework that has code for connecting FiB component with business logic. Users assign remote interface name, some information related with mainframe environment such as (ZTG(CJCS Transaction Gateway)and CICS server, and transaction ID to generate RIB code. Users compile BIB code and deploy it to web application server. 6. Component Tester Component tester performs some tests about interface and performance of RIB component and displays the result The main features are as follows: 1Test case is defined by using Java Reflection technique. 2Test case is generated by using pattern and XML. 3Test client program is automatically generated. 4Performance test uses thread and individual NM techniques. Using versatile graph, component tester provides test results such as minimum, maximum, average response time, and difference between return value and expected value while performing test case. In figure 7 several graphs provided by component tester are depicted Figure 7 : Graphs provided by component tester 7. System Environments -8-

9 EJB component is deployed to the web application server, and interacts legacy COBOL system existed in mainframe through CTG.. Figure 8 depicts system environments. Figure 8 : System Environments Developing and operating environments are as follows: Mainframe: 05/390 v2.7, CICS vl.3 Middleware : Windows 2000NT Server, IBM CTG, IBM WebShere v Conclusion and Future Works COBOL2EJB is a tool supporting sequence of wrapping process as a one way of legacy system modernization This tool makes easy for legacy system to adapt new computing environments without any changes of system by generating wrapping component and to extend functionalities by adding new features to the component. We have a plan to extend business identification technique, to add legacy system restructuring feature, and to strengthen component test functionality. -9-

10 References [1] Santiago Comell-Dorda, Kurt Wallnau, Robert C. Seacord, and John Robert, 'A Survey of Legacy System Modernization Approaches", Technical Note, CMU/SEI 2000-TN-003, Apr [2] Santiago Comell-Dorda, Grace A. Lewis, Pat Place, Dan Plakosh, and Robert C.Seacord, "Incremental Modernization of Legacy Systems", Technical Note, CMU/SEI-2000-TN-006, Jul [3]"Creating Components form Legacy Applications", CBDi Forum Journal, Dec [4] J.Q.Ning et al., "Recovering reusable components from legacy systems by program segmentation", Proc. Reverse Engineering, pp.64-72, [5] H.Huang et al., "Business rule extraction from legacy code", Proc 20 th Computer Software and Application Conference, pp , [6] H.M. Sneed et al., "Extracting business rules from source code", Proc. 4 th Program Comprehension, pp ,