SOAMIG Project: Model-Driven Software Migration towards Service-Oriented Architectures A. Winter, C. Zillmann A. Herget, W. Teppe, M. Theurer OFFIS Oldenburg Amadeus Germany Institute for Information Technology {aherget, wteppe, mtheurer}@de.amadeus.com {zillmann, winter}@offis.de U. Erdmenger, U. Kaiser, D. Uhlig, A. Fuhr, T. Horn, V. Riediger Y. Zimmermann Institute for Software Technology (IST) pro et con GmbH University of Koblenz-Landau {uwe.erdmenger, uwe.kaiser, denis.uhlig, {afuhr, horn, riediger}@uni-koblenz.de yvonne.zimmermann}@proetcon.de Abstract—The SOAMIG project aims at developing a gen- During the SOAMIG project, two industrial case studies eral migration process for model-driven migrations towards were selected: the LCOBOL case study deals with a Service-Oriented Architectures. This paper highlights the language migration from a transaction driven COBOL model-driven tools developed during the SOAMIG project for two case studies: A language migration from a COBOL system to Java Web Services, while the ASPL case study is transactional server to Java web services, and a second study about an architecture migration from a Java fat client into on an architecture migration from a monolithic Java fat a Java SOA. This short-paper presents the tools developed client to a SOA-based JavaEE web application. during the SOAMIG project. I. M OTIVATION II. LCOBOL: L ANGUAGE M IGRATION Today, companies are facing a growing competition in The LCOBOL case study is conducted by pro et con, their markets. Competitors are forced to achieve higher one of the industrial partners. The main challenge in this flexibility and faster time-to-market in order to survive. case study is to yield a very high degree of automation Often, so-called legacy software developed in the compa- for a language migration from COBOL to Java. Also, nies can not keep up with this highly dynamic environment the resulting Java code has to be understandable and and therefore slows down innovation. maintainable. Figure 1 shows the set-up of the tool chain. For this reason, companies are looking for flexible Every COBOL source file is parsed into a fine-grained software concepts supporting fast adaptability to business abstract syntax graph by the COBOL front-end CobolFE. changes. A promising approach to achieve the required CobolFE can handle various COBOL dialects. The main flexibility are Service-Oriented Architectures (SOAs). translation to Java is done by the model-to-model trans- SOAs encapsulate functionality in coarse-grained, loosely- formation Cobol2Java. This tool takes the COBOL coupled and reusable units, called services. model as input. The actual transformation is defined by Adopting SOAs, companies do not want to throw away many sophisticated rules defining a semantics-preserving their existing systems because much money and knowl- transformation into a Java model. Project specific rules, edge has been put into them. Instead of reimplementing e.g., on how to transform specific transaction monitor the service functionality from scratch, companies are striv- calls, amend the language translation. The transformations ing to reuse their legacy software as much as possible. are implemented in C++. Finally, Java source code is Transferring existing code into a new technology without generated by JGen and JFormat. JGen takes a model changing functionality is called software migration. of a Java translation unit as input and creates syntactically The SOAMIG project, partially funded by the German correct, but only roughly formatted output. JFormat Ministry of Education and Research (BMBF)1 , brings is a stand-alone, scriptable Java source code formatter together both: transition into SOA by migrating the legacy based on the Eclipse JDT formatter and is individually code. The overall goals are i) to define a reference process configurable to various formatting conventions. [1], ii) to achieve a high degree of automatic code migra- tion, and iii) to support the migration process by analysis III. R AIL C LIENT: A RCHITECTURE M IGRATION and transformation tools. In the RailClient case study, an architecture migration In this project, two universities and two companies have from a monolithic Java system into a SOA-based web been involved: the Universities of Oldenburg (OFFIS) and application is investigated by all four project partners. Koblenz-Landau (IST) supplying reengineering knowl- Figure 2 outlines the tools developed in this part of the edge and model-driven tools, pro et con, supplying long- SOAMIG project. Amadeus Germany provided the busi- time expertise in industrial migration projects, language ness case and the subject system, an order management analysis, and migration tools development, and Amadeus and booking system for train tickets. OFFIS contributed Germany, providing one of the industrial legacy systems to the definition and realization of the target architecture. and know-how in migration of large-scaled systems. The SOAMIG repository forms a common core of the 1 Grant no. 01IS09017A-D. See http://www.soamig.de for further in- tool-chain. In this repository, artifacts used during migra- formation. tion are stored as models. The main part of the repository Translator chain CobolFE Cobol2Java JGen JFormat Cobol Cobol Cobol model model Java Java model model Java Java Cobol Code Code Code Code Transformation Transformation rules rules Figure 1. Tool set-up for the LCOBOL case study Monolithic legacy system Extractor tools DSL Java, Java, Cobol, Cobol, UML UML JavaFE DSL parsers and and DSL DSL Metamodels Metamodels State Message Business parsers Java Java Message Business code code machines repository repository processes processes Transformation Analysis tools tools SOAMIG FGM Code generation tools Extractor Dynamic JFormat JGen SOAMIG Analysis GReTL Repository Toolset Isolated Isolated Java Java model model service service code code DataModel GReQL Generator Figure 2. Tool set-up for the RailClient case study is based on the TGraph technology developed by IST. mentioned JGen and JFormat tools. The generated Java TGraphs are a versatile data structure formally defined by code requires manual rework. It contains human readable grUML (graph UML). The TGraph technology is generic as well as machine processable annotations to link to the and can represent arbitrary artifacts. In SOAMIG, the relevant legacy sources. tools are integrated by an XML-based exchange format IV. C ONCLUSION for metamodels and models. To ease initial program understanding and redocumen- Summarizing, a set of powerful model-driven tools tation, the explorative tool FGM (Flow Graph Manipulator) and technologies has been developed to support various by pro et con was used. This partner also provided tasks during the migration process. Most of the tools are JavaFE, an extractor from Java source to fine-grained independent of the concrete legacy system and are reusable abstract syntax graphs stored in the repository. Not only as-is, others have to be configured or have even been source code, but also various other parts of the legacy built from scratch. The SOAMIG repository technology system, such as automatons controlling GUI behavior, is largely generic, enabling integration of additional meta- message descriptions, and redocumented business pro- models and traceability to the already existing parts. cesses are combined into one comprehensive model. Links Every migration project requires adaption and special- between these parts are established by static and dy- ization of process, repository, and tools to the specific namic analysis. Static analysis is covered by JavaFE and needs of the legacy and target systems, the organizational GReQL (Graph Repository Query Language). Dynamic requirements, and other factors. While the complete mi- analysis of certain test cases covering the selected business gration of the case study systems is out of scope of the processes is used to detect relevant portions of the source project, the model-driven tools have proven to be appli- code, and to mark service candidates [2]. cable in real-world scenarios. Transfer to other business Among the transformation tools in this case study is cases and different migration tasks is an opportunity to GReTL (Graph Repository Transformation Language), a further evolution of the SOAMIG process and technology. general-purpose transformation language that allows to R EFERENCES define and execute arbitrary graph transformations. A sys- [1] U. Erdmenger, A. Fuhr, A. Herget, T. Horn, U. Kaiser, tem specific DataModelGenerator combines message V. Riediger, W. Teppe, M. Theurer, D. Uhlig, A. Winter, descriptions and dynamic traces to compile service specific C. Zillmann, and Y. Zimmermann, “The SOAMIG Process data structures for the target architecture. Model in Industrial Applications,” in Proceedings of the The SoamigExtractor tool provides a graphical 15th European Conference on Software Maintenance and interactive user interface to enable model transformations. Reengineering, T. Mens, Y. Kanellopoulos, and A. Winter, Eds. Los Alamitos: IEEE Computer, 2011, pp. 339–342. Examples are incorporating dynamic traces, pruning gen- eralization hierarchies, selection and completion (slicing) [2] A. Fuhr, T. Horn, and V. Riediger, “Dynamic Analysis for of multi-class Java models based on execution traces, es- Model Integration (Extended Abstract),” Softwaretechnik- tablishment of traceability links between source and target Trends, vol. 30, no. 2, pp. 70–71, 2010. models, and export of translation unit models to the above