|We propose a model-driven and generative approach to specify and generate web services for migrating scienti c legacy systems to service-oriented platforms. From a model speci cation of the system migration, we use code generation to generate web services and automate the legacy integration. We use a case study from an existing oil spill analysis application developed in Fortran and C++ to show the feasibility of the approach.
A large number of existing systems, especially within
data and computationally intensive domains, are based
on implementations that are becoming increasingly di
cult to maintain and evolve [
In this paper, we investigate a model-driven approach for migrating legacy systems to service-oriented architectures. Our migration strategy is wrapping of existing legacy components. We use the Uni ed Modelling Language (UML) to specify migration models, or wrappers, 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 and tools for migrating scienti c software to serviceoriented architectures.
We de ne a migration pro le in UML that contains
concepts for integrating with existing legacy, such as
native libraries, executable programs, and databases, as
well as for integrating with existing web services. We
establish a modelling approach { a method { for how
to specify services using the migration concepts, as well
as concepts from SoaML [
Our goal is to create e ective and usable means for migrating legacy systems to service-oriented platforms. Our conjecture is that model-driven and generative techniques can provide these means.
In SINTEF Materials and Chemistry, they have a commercial legacy product for simulating oil drift, which can help predicting the spreading of oil in case of an accidental spill. The system is implemented by a Fortran simulation back-end and a C++ front-end. Now, they want a transition to a service-oriented paradigm to more easily adapt to new customer needs and more exible business models. Figure 1 illustrates the existing application.
Front-end – set up scenario, Visualise results (C++)
OOililddaattaabbaassee
SSimimuulalattioionn
EEnnggininee ((FFoorrttrraann)) Environmental
Data (wind, current, etc)
The Fortran simulation core is responsible for simulating oil drift based on numerical models. It is invoked from a presentation layer written in C++. All input is le based, and simulation runs in batch mode from some minutes to several days. This approach has worked ne for many years, but there are some apparent challenges with respect to interoperability, integration, and scalability. The goal is to migrate the application to meet new market needs while coping with these challenges.
We use model-driven engineering techniques to develop the oil drift prediction as a service that wraps the existing simulation engine. UML models are used to specify the service interfaces and the details of the wrapper architecture. From these models, we generate XML schemas for the web service, Java interface and class implementations of the web service, the architecture of the wrapper, and its behavioural implementation. Wrapping of the C++ front-end is out of our scope, since this will be re-designed to t a web-based interaction paradigm.
We de ne a UML migration pro le to represent semantics of di erent 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 approach.
Migrationprofile interfaces
USMctrluaLcstsMuersoeddels SoaMbeLhparvoiofiluer Model 2 Text Transformations
Generated Web Service Databases ShNaarteivleibs cEoxmepcountaebnlets seWrveicbes
Elibxrtaerrineasl transfDoarmtaations
We use UML interfaces and classes to model the structural parts of the system. Service interfaces de ne the behaviour, and classes de ne the internal structure of the services. UML composite structures are used for specifying the service de-composition into parts. The service is decomposed by legacy component parts, which is orchestrated by the service to provide its operations. The behaviour of the service and its contained legacy wrapper components is de ned by UML activity diagrams.
To relate the migration models to the service-oriented modelling domain, we use some SoaML concepts to describe services: the stereotype «serviceInterface» is used to denote a service, i.e. the service that wraps the legacy systems. The stereotype «MessageType» is used to specify the data types passed as message input and output of the service.
The migration pro le contains a set of stereotypes used for adding migration semantics to the UML models. The main purpose of the migration model is to integrate existing legacy functionalities and expose them through well-de ned interfaces. To this end, we use standard UML models extended with migration semantics from a pro le.
The Component Types: The component types represent di erent sorts of legacy components that take part in ful lling the responsibilities of the legacy system. This might be existing shared libraries, executables, Java libraries, databases, or web services. Figure 3 speci es the set of component types that are in the current pro le.
The stereotype «WebService» denotes the wrapping of an external web service, i.e. a web service client. «RestfulWebService» denotes the wrapping of a restful web service. Its endpoint is an URI that acts as a data source, which is fetched by the wrapper and used locally. «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 libraries, e.g. provided by a jar le. «db jdbc» denotes the wrapping of a JDBC database. Operations de ned in classes of this type represent database SQL queries.
The pro le additionally provides stereotypes for speci c types of operations, such as «asynch» for asynchronous operations and «RSOp» for restful service operations. Exceptions can be speci ed explicitly by classes stereotyped «exception». Throwing and catching of exceptions are speci ed by dependencies stereotyped «throws» and «catches».
Behaviour { Activities and Actions: Behaviour is declared by operations in components. The behaviour of these operations are de ned by associated activity diagrams. An activity diagram de nes behaviour by sequences and branches of actions that are mapped to statements in code generation. Standard (opaque) actions contain embedded Java code. CallOperationActions are used for de ning invocations to de ned operations of related components. In addition, we de ne a set of stereotypes in the migration pro le for simplifying the action speci cation:
«return» is used to denote a return from the method execution with a speci c value; «assign» is used to denote an assignment of a value to a variable; «setState» is used to denote the setting of an internal state variable, speci cally used for asynchronous and long running operations; «setReturn» is used to set the return value of an asynchronous and long running operation; «param» is used to de ne an input parameter to a CallOperationAction. It references a previously de ned variable; nally, «valueparam» is used to de ne a literal value as an input parameter to a CallOperationAction.
In this section, we exemplify the use of the migration pro le on the oildrift prediction case in terms of structure and behaviour.
is de ned by a SoaML «serviceInterface» class, which implements the service interface with a set of exposed operations (Figure 4). The most interesting of these is the «asynch» operation predictOilDriftAsynch, which provides the main service in the oildrift prediction case. Since the execution of a simulation may run for hours, or even days, the operation is declared as asynchronous. The operation will return immediately with only a session id to identify the session.
Two additional helper operations are provided for checking execution status (getStatus) and to retrieve the result upon termination (getPredictOilDriftResult ).
The PredictOilDriftService is a structured class that contains a set of parts: the PredictOilDriftServiceController is the internal orchestration component for the service. All incoming calls are delegated to the controller, which implements the operations of the service. The DataTransformer provides operations for transforming input required by the Fortran simulation engine, and transforming result data after simulation. The FatesWrapper is an «exe» component, which wraps the execution of the Fortran simulation program. The WeatherServiceIntegrator provides operations for integrating with an external weather data provider. It is further de-composed by two parts: a «restfulWebService» called WeatherService and a «JNI»-component called GribDataTransformer. The getWeatherInfo operation gets weather data from a restful web service that provides binary data in the GRIB 2 format. To transform the GRIB-data to the input format used by the simulation engine, an external native library (in this case 2GRIdded Binary, http://www.wmo.int DLL) is integrated by the GribDataTransformer. The OilDatabase is a «db jdbc»-component, which provides oil type information from an SQL database.
The data types passed in the service interface are modelled as classes stereotyped using the SoaML stereotype «MessageType». Apart from the stereotype, the data types are speci ed with standard UML classes with attributes and associations.
Behaviour: Component behaviour is speci ed for di erent operations in the migration model. Behaviour is de ned by Activity diagrams that are associated with the operations they implement.
Figure 5 shows the behaviour of the predictOilDriftAsynch operation, which is contained in the PredictOilDriftServiceController. All invocations to the service PredictOilDriftService is by convention delegated to its controller part.
The example with the asynchronous operation is interesting, since it also requires handling of the longrunning external executable. In this case, this is handled by providing a second activity diagram, which speci es the behaviour upon termination of the executable.
The rst activity diagram speci es the initial behaviour of the operation, up until the call to the executable component.
The second activity diagram from Figure 5 speci es the behaviour occurring when the execution of the external program has terminated. When the nal action is executed, the service state (for this particular session id) is set to a ready state, and the client can fetch the result of the service.
Our approach for behavioural modelling is tied to the target language, in this case Java, since we in some cases embed small portions of code inside actions. We could get around this by incorporating a richer set of UML actions that can cope with variable declarations, property references, and object creation. This extension will be investigated as part of future work.
The purpose of the migration models is to automate
as much as possible the legacy system migration process.
We have developed a set of transformations, or code
generators, to support the transition from models to
deployable services. They were implemented with the
model to text transformation tool MOFScript[
Dorda et al.[
Within the Object Management Group (OMG), the
Architecture-Driven Modernization (ADM) task force
[
Razavian and Lago [
Canfora et al.[
We have presented a model-driven approach for legacy migration to service-oriented architectures, where the focus is black-box migration by wrapping legacy components using model-driven and generative techniques. We have de ned a UML pro le for migration and a set of code generators for generating services and wrapper components. We have tested the migration approach on an oildrift prediction system, by modelling and generating the services and wrappers required for integration with the various legacy components.
At this time, we have not addressed automation of legacy data mappings, which is a major concern in legacy modernisation. In the current case study, data mappings between binary data formats where written manually. In future work we will investigate appropriate techniques and tools for specifying data transformations at the model level, and for mapping these to the implementation level.
The results reported in this paper are from the SiSaS project (SINTEF Software as a Service). SiSaS is an internal project within SINTEF that focuses on migration of scienti c legacy scienti c software to services.