=Paper=
{{Paper
|id=None
|storemode=property
|title=Model-Driven Migration of Scientific Legacy Systems to Service-Oriented Architectures
|pdfUrl=https://ceur-ws.org/Vol-708/mdsm2011-oldevik-et-al-11-mig2soa.pdf
|volume=Vol-708
}}
==Model-Driven Migration of Scientific Legacy Systems to Service-Oriented Architectures==
https://ceur-ws.org/Vol-708/mdsm2011-oldevik-et-al-11-mig2soa.pdf
Model-Driven Migration of Scientific Legacy Systems to Service-Oriented
Architectures
Jon Oldevik, Gøran K. Olsen Ute Brönner, Nils Rune Bodsberg
SINTEF Information and Communication Technology SINTEF Materials and Chemistry
Forskningsvn 1, 0373 Oslo, Norway Brattørkaia 17c, 7465 Trondheim, Norway
jon.oldevik | goran.olsen at sintef.no ute.broenner | nilsrune.bodsberg at sintef.no
Abstract—We propose a model-driven and genera- Our conjecture is that model-driven and generative tech-
tive approach to specify and generate web services for niques can provide these means.
migrating scientific legacy systems to service-oriented
platforms. From a model specification of the system II. Motivating Case Study: Oildrift Simulation
migration, we use code generation to generate web
services and automate the legacy integration. We In SINTEF Materials and Chemistry, they have a
use a case study from an existing oil spill analysis commercial legacy product for simulating oil drift, which
application developed in Fortran and C++ to show can help predicting the spreading of oil in case of an
the feasibility of the approach. accidental spill. The system is implemented by a Fortran
Keywords-Model-driven engineering, legacy migra- simulation back-end and a C++ front-end. Now, they
tion, web services want a transition to a service-oriented paradigm to
more easily adapt to new customer needs and more
I. Introduction
flexible business models. Figure 1 illustrates the existing
A large number of existing systems, especially within application.
data and computationally intensive domains, are based
on implementations that are becoming increasingly diffi-
cult to maintain and evolve [1], typically in languages like Simulation
Simulation
Cobol and Fortran. Competent personnel with know- Engine
Engine
(Fortran)
(Fortran)
ledge of these technologies is also becoming a scarce
resource. Modernisation toward a service-oriented archi- Front-end – set up scenario,
tecture may also open for new business opportunities. Visualise results (C++)
In this paper, we investigate a model-driven approach
for migrating legacy systems to service-oriented archi-
Oil
Oil database
database
tectures. Our migration strategy is wrapping of existing Environmental
Data (wind, current, etc)
legacy components. We use the Unified Modelling Lan-
guage (UML) to specify migration models, or wrappers,
Figure 1. Oildrift Prediction – Legacy Application
that are fed to model-driven code generators to generate
a deployable service. This work has been done in the
SiSaS project1 , which has an overall focus of methods The Fortran simulation core is responsible for simu-
and tools for migrating scientific software to service- lating oil drift based on numerical models. It is invoked
oriented architectures. from a presentation layer written in C++. All input is
We define a migration profile in UML that contains file based, and simulation runs in batch mode from some
concepts for integrating with existing legacy, such as minutes to several days. This approach has worked fine
native libraries, executable programs, and databases, as for many years, but there are some apparent challenges
well as for integrating with existing web services. We with respect to interoperability, integration, and scala-
establish a modelling approach – a method – for how bility. The goal is to migrate the application to meet new
to specify services using the migration concepts, as well market needs while coping with these challenges.
as concepts from SoaML [2]. Our modelling comprises III. Our approach
the interfaces and structure of a service, as well as the
We use model-driven engineering techniques to de-
behaviour of different service parts.
velop the oil drift prediction as a service that wraps
Our goal is to create effective and usable means for
the existing simulation engine. UML models are used
migrating legacy systems to service-oriented platforms.
to specify the service interfaces and the details of the
1 SINTEF Software as a Service wrapper architecture. From these models, we generate
XML schemas for the web service, Java interface and part in fulfilling the responsibilities of the legacy system.
class implementations of the web service, the architec- This might be existing shared libraries, executables, Java
ture of the wrapper, and its behavioural implementation. libraries, databases, or web services. Figure 3 specifies
Wrapping of the C++ front-end is out of our scope, since the set of component types that are in the current profile.
this will be re-designed to fit a web-based interaction
paradigm.
We define a UML migration profile to represent se-
mantics of different types of migration features, such
as executables, databases, and native libraries. The code
generators use this semantics to generate the necessary
integration code. Figure 2 illustrates the high-level ap-
proach.
Figure 3. Component types
UML Models
Migration profile SoaML profile
interfaces
Structured
classes behaviour The stereotype «WebService» denotes the wrapping
of an external web service, i.e. a web service client.
Model 2 Text Transformations
«RestfulWebService» denotes the wrapping of a restful
Generated Web Service
Native Executable Web
web service. Its endpoint is an URI that acts as a data
Databases
Share libs components services
source, which is fetched by the wrapper and used locally.
External Data
libraries transformations «exe» denotes the wrapping of an executable program.
«JNI» denotes the wrapping of a native library, such
as a windows shared DLL, using Java Native Interface
(JNI). «external» denotes integration with external Java
Figure 2. Approach Overview
libraries, e.g. provided by a jar file. «db jdbc» denotes
the wrapping of a JDBC database. Operations defined
We use UML interfaces and classes to model the in classes of this type represent database SQL queries.
structural parts of the system. Service interfaces define The profile additionally provides stereotypes for spe-
the behaviour, and classes define the internal structure cific types of operations, such as «asynch» for asyn-
of the services. UML composite structures are used for chronous operations and «RSOp» for restful service
specifying the service de-composition into parts. The operations. Exceptions can be specified explicitly by
service is decomposed by legacy component parts, which classes stereotyped «exception». Throwing and catching
is orchestrated by the service to provide its operations. of exceptions are specified by dependencies stereotyped
The behaviour of the service and its contained legacy «throws» and «catches».
wrapper components is defined by UML activity dia- Behaviour – Activities and Actions: Behaviour is
grams. declared by operations in components. The behaviour
To relate the migration models to the service-oriented of these operations are defined by associated activity
modelling domain, we use some SoaML concepts to diagrams. An activity diagram defines behaviour by
describe services: the stereotype «serviceInterface» is sequences and branches of actions that are mapped to
used to denote a service, i.e. the service that wraps the statements in code generation. Standard (opaque) ac-
legacy systems. The stereotype «MessageType» is used tions contain embedded Java code. CallOperationActions
to specify the data types passed as message input and are used for defining invocations to defined operations
output of the service. of related components. In addition, we define a set of
stereotypes in the migration profile for simplifying the
A. The migration profile action specification:
The migration profile contains a set of stereotypes «return» is used to denote a return from the method
used for adding migration semantics to the UML models. execution with a specific value; «assign» is used to
The main purpose of the migration model is to integrate denote an assignment of a value to a variable; «setState»
existing legacy functionalities and expose them through is used to denote the setting of an internal state variable,
well-defined interfaces. To this end, we use standard specifically used for asynchronous and long running op-
UML models extended with migration semantics from erations; «setReturn» is used to set the return value of
a profile. an asynchronous and long running operation; «param»
The Component Types: The component types rep- is used to define an input parameter to a CallOpera-
resent different sorts of legacy components that take tionAction. It references a previously defined variable;
finally, «valueparam» is used to define a literal value as DLL) is integrated by the GribDataTransformer. The
an input parameter to a CallOperationAction. OilDatabase is a «db jdbc»-component, which provides
oil type information from an SQL database.
B. Modelling the Oildrift Prediction Case
The data types passed in the service interface are
In this section, we exemplify the use of the migration modelled as classes stereotyped using the SoaML stereo-
profile on the oildrift prediction case in terms of struc- type «MessageType». Apart from the stereotype, the
ture and behaviour. data types are specified with standard UML classes with
Service Structure and Interface: The service itself attributes and associations.
is defined by a SoaML «serviceInterface» class, which
Behaviour: Component behaviour is specified for
implements the service interface with a set of exposed
different operations in the migration model. Behaviour
operations (Figure 4). The most interesting of these is
is defined by Activity diagrams that are associated with
the «asynch» operation predictOilDriftAsynch, which
the operations they implement.
provides the main service in the oildrift prediction case.
Figure 5 shows the behaviour of the predictOilDrif-
Since the execution of a simulation may run for hours,
tAsynch operation, which is contained in the Predic-
or even days, the operation is declared as asynchronous.
tOilDriftServiceController. All invocations to the service
The operation will return immediately with only a ses-
PredictOilDriftService is by convention delegated to its
sion id to identify the session.
controller part.
Two additional helper operations are provided for
The example with the asynchronous operation is in-
checking execution status (getStatus) and to retrieve the
teresting, since it also requires handling of the long-
result upon termination (getPredictOilDriftResult).
running external executable. In this case, this is handled
by providing a second activity diagram, which specifies
the behaviour upon termination of the executable.
Figure 4. Predict Oildrift – Service and Wrapper Components
The PredictOilDriftService is a structured class that
contains a set of parts: the PredictOilDriftServiceCon-
troller is the internal orchestration component for the
service. All incoming calls are delegated to the con-
troller, which implements the operations of the service.
The DataTransformer provides operations for trans-
forming input required by the Fortran simulation en-
Figure 5. Predict Oildrift Service Behaviour
gine, and transforming result data after simulation. The
FatesWrapper is an «exe» component, which wraps
The first activity diagram specifies the initial be-
the execution of the Fortran simulation program. The
haviour of the operation, up until the call to the exe-
WeatherServiceIntegrator provides operations for inte-
cutable component.
grating with an external weather data provider. It is
further de-composed by two parts: a «restfulWebSer- The second activity diagram from Figure 5 specifies
vice» called WeatherService and a «JNI»-component the behaviour occurring when the execution of the ex-
called GribDataTransformer. The getWeatherInfo oper- ternal program has terminated. When the final action is
ation gets weather data from a restful web service that executed, the service state (for this particular session id)
provides binary data in the GRIB 2 format. To transform is set to a ready state, and the client can fetch the result
the GRIB-data to the input format used by the sim- of the service.
ulation engine, an external native library (in this case Our approach for behavioural modelling is tied to the
target language, in this case Java, since we in some
2 GRIdded Binary, http://www.wmo.int cases embed small portions of code inside actions. We
could get around this by incorporating a richer set of of code generators for generating services and wrapper
UML actions that can cope with variable declarations, components. We have tested the migration approach on
property references, and object creation. This extension an oildrift prediction system, by modelling and gener-
will be investigated as part of future work. ating the services and wrappers required for integration
with the various legacy components.
C. Code generation At this time, we have not addressed automation of
The purpose of the migration models is to automate legacy data mappings, which is a major concern in legacy
as much as possible the legacy system migration process. modernisation. In the current case study, data mappings
We have developed a set of transformations, or code between binary data formats where written manually. In
generators, to support the transition from models to future work we will investigate appropriate techniques
deployable services. They were implemented with the and tools for specifying data transformations at the
model to text transformation tool MOFScript[3]. model level, and for mapping these to the implemen-
tation level.
IV. Related Work
Acknowledgements
Dorda et al.[4] give a survey of legacy system moderni-
sation approaches. They distinguish between two main The results reported in this paper are from the SiSaS
types of modernisation: white-box and black-box mod- project (SINTEF Software as a Service). SiSaS is an in-
ernisation. White box modernisation requires an under- ternal project within SINTEF that focuses on migration
standing of the internal parts of a system, and involves of scientific legacy scientific software to services.
re-structuring, re-architecting, and re-implementing the References
system. Black-box modernisation is only concerned with
the input/output, i.e. the interfaces, of the legacy sys- [1] F. Zoufaly, “Issues and challenges facing legacy systems,”
Project Management, developer.com, 2002.
tem, and is often based on wrapping. Our approach
can be seen as a model-driven black-box modernisation [2] Object Management Group (OMG), “Service Oriented
technique. However, the migration also has flavours of Architecture Modeling Language (SoaML), FTF Beta 2,”
white-box migration to it, in particular in understanding OMG, Standard ptc/2009-12-09, 2009.
and transforming the legacy data formats.
[3] J. Oldevik, T. Neple, R. Grønmo, J. Aagedal, and
Within the Object Management Group (OMG), the A. Berre, “Toward Standardised Model to Text Trans-
Architecture-Driven Modernization (ADM) task force formations,” in European Conference on Model Driven
[5] is working on standards to support legacy moderni- Architecture - Foundations and Applications (ECMDA).
sation, such as meta-models for knowledge discovery, Nuremberg: Springer, 2005, pp. 239–253.
software visualisation, and refactoring.
[4] S. Comella-Dorda, K. Wallnau, R. C. Seacord,
Razavian and Lago [6] present a SOA migration frame- and J. Robert, “A survey of legacy system
work – (SOA-MF) – wherein they establish an overall modernization approaches,” 2000. [Online]. Available:
process framework for legacy migration, focusing on http://handle.dtic.mil/100.2/ADA377453
recovery and re-engineering, and put it in the context
of migration methods such as SMART [7]. Although our [5] Object Management Group (OMG), “ADM White Pa-
per: Transforming the Enterprise,” OMG, White paper
work has not focused on re-factoring or re-engineering, http://www.omg.org/docs/admtf/07-12-01.pdf, 2008.
the processes targeting legacy discovery and transforma-
tion to new architecture has also been addressed in our [6] M. Razavian and P. Lago, “Understanding SOA migration
work. using a conceptual framework,” Czech Society of Systems
Canfora et al.[8] present an approach for migrating Integration, 2010.
interactive legacy systems to web services based on [7] S. Balasubramaniam, G. A. Lewis, E. J. Morris,
wrapping. They define a model (a state machine) of the S. Simanta, and D. B. Smith, “SMART: Application of a
user interactions, which is the basis for integration with method for migration of legacy systems to SOA environ-
legacy systems through terminal emulation. This process ments,” in Service-Oriented Computing - ICSOC 2008, 6th
is then exposed as a web service. International Conference, Sydney, Australia, December
1-5, 2008. Proceedings, ser. Lecture Notes in Computer
V. Conclusion and Outlook Science, A. Bouguettaya, I. Krüger, and T. Margaria,
Eds., vol. 5364, 2008, pp. 678–690.
We have presented a model-driven approach for legacy
migration to service-oriented architectures, where the [8] G. Canfora, A. R. Fasolino, G. Frattolillo, and P. Tra-
focus is black-box migration by wrapping legacy com- montana, “Migrating interactive legacy systems to web
services,” in CSMR. IEEE Computer Society, 2006, pp.
ponents using model-driven and generative techniques. 24–36.
We have defined a UML profile for migration and a set