=Paper=
{{Paper
|id=None
|storemode=property
|title=SOAMIG Project: Model-Driven Migration towards
Service-Oriented Architectures
|pdfUrl=https://ceur-ws.org/Vol-708/mdsm2011-erdmenger-et-al-11-soamig.pdf
|volume=Vol-708
}}
==SOAMIG Project: Model-Driven Migration towards
Service-Oriented Architectures==
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