With the advent of cloud computing platforms, many companies are studying the migration of legacy applications to the cloud. The main difficulty in dealing with such system is the obsolescence, either due to the dependency on an obsolete platform, incomplete/incorrect documentation or using an inappropriate architecture for the cloud. The FP7 project REMICS (Reuse and Migration of legacy applications to Interoperable Cloud Services) intends to provide a model-driven approach to extract valuable information from existing code and automating the refactoring of old code into cloud enabled architectures. In order to do so, REMICS proposes a process based on three steps: Recovery, Migration and Deployment. The work to be performed during each step is partially automated by the tools developed in the project. This presentation is going to focus on the description of the process and its associated tools and on our experience in applying the process in an industrial case study.

1. Marcos Almeida
SOFTEAM
PMDE – ECMFA 2013
The REMICS model-driven
process for migrating legacy
applications to the cloud

2. Softeam
 Specialist in OO technologies, new architectures, new
methodologies
 Banking, Defense, Telecom
 20 years of experience
 700 experts
 UML Editor: Modelio
 CloudML, SysML, MARTE, Code Generation, Documentation,
Teamwork

3. REMICS: Reuse and Migration of
legacy applications to interoperable
Cloud Services
 A FP7 EU Project
 9/2010  8/2013
 Partners
Stiftelsen Sintef (NO) Research
Fraunhofer-FOCUS (DE) Research
Tecnalia Research & Innovation (ES) Research
Institute of Information and Communication
Technologies – Bulgarian Academy of Sciences
(BG)
Research
University of Tartu (EE) Research
Warsaw University of Technology (PL) Research
DI Systemer AS (NO) End-user, SME
DOME Consulting & Solutions, S.L. (ES) End-user, SME
Netfective Technology SA (FR) Tool and consultancy provider, SME
Softeam (FR) Tool and consultancy provider, SME

4. In short: How to migrate legacy
applications to the cloud?
 Cloud
 Cloud computing
 Virtual Machines, Platforms, Services
 “Cheap” scalability
 Legacy applications
 Client-server based or Desktop based
 Better performance?  Better hardware!
 “Expensive” scalability
 Migration
 Retrieve
 Refactoring: frameworks x Architectures
 Deploy
 How
 Ad-hoc x Process

5. Cloud computing: cheap
infrastructure, platforms and
services, but…
 Infrastructure as a Service (IaaS):
 Virtualizing hardware platform
 Operating System as a Service
 Cheap “out and up” scalability
 Platform as a Service (PaaS):
 Virtualizing software platform
 Software framework as a Service
 Software as a Service (SaaS):
 Virtualizing software services
 Software as a Service
5
Infrastructure as a Service
Platform as a Service
Software as
a Service

6. … but one needs to deal with legacy
applications.
 Client-server based or Desktop based
 Different frameworks & Platforms
 PaaS specific APIs
 Desktop UI x Web UI
 Different habits
 Dependency on specific operating systems
 Dependency on specific hardware configurations
 Dependency on specific support software (e.g. databases, registry…)
 Dependency on writing/reading to/from the file system
 Multi-tenancy x Multi-instances
 Better performance? Better hardware!
 Buy, configure, maintain new hardware…
 “Expensive” scalability
6

7. Deal with legacy = Migration =
Refactoring
 In order to refactor, we need to….
 Understand the old architecture
 Define the requirements of the new version
 Find a cloud provider
 Take a look at the supported API’s, platforms, architectures…
 Define the new architecture
 Refactor the old code.
Can we automate any of these?
7

8. Starting points: Models and Services
 Model Driven Engineering
 Language independent approach
 Automated transformations
 OMG ADM = Architecture Driven Modernization
 Start with knowledge discovery!
 Then follow the MDA approach
 CIM  PIM  PSM
 OMG SoaML = Services Oriented Architecture Modelling
Language
 Break applications into services!
8

9. State of the Art: Cloud mostly
unsupported
 No cloud-ready standards
 There are no standards for platform independent modelling combining SOA and cloud
computing for SaaS design.
 Extend the SOA models with peculiarities of cloud computing paradigm.
 Nothing more than reversing code
 The knowledge discovery is often limited to reverse engineering of legacy code. The
business process and rules recovery is poorly addressed.
 There is a lack of methods for service interoperability on model level.
 Efficiently adapt existing services and increase their interoperability to cope with the migration
requirements.
 Only Ad-hoc processes
 The Service Clouds architecture migration methods are mostly ad-hoc and lack a
comprehensive methodology addressing dedicated design patterns and transformations.
 Automate the architecture migration with model transformation.
 Don’t even think about validating what you’ve done…
 There are no dedicated testing technologies for Service Clouds migration validation.
 Reuse the legacy application in automated testing of the new migrated SaaS application
9

10. In REMICS: Cloud based migration
 A cloud-ready standard : PIM4Cloud
 There are no standards for platform independent modelling combining SOA and cloud
computing for SaaS design.
 Extend the SOA models with peculiarities of cloud computing paradigm.
 Reversing business processes too
 The knowledge discovery is often limited to reverse engineering of legacy code. The
business process and rules recovery is poorly addressed.
 There is a lack of methods for service interoperability on model level.
 Efficiently adapt existing services and increase their interoperability to cope with the migration
requirements.
 A migration process
 The Service Clouds architecture migration methods are mostly ad-hoc and lack a
comprehensive methodology addressing dedicated design patterns and transformations.
 Automate the architecture migration with model transformation.
 Validation and test tools
 There are no dedicated testing technologies for Service Clouds migration validation.
 Reuse the legacy application in automated testing of the new migrated SaaS application
10

11. Approach: a process covering
everything from the legacy code to
the deployed migrated code
11

12. Not only a process, but a set of tools!
 Recover
 BlueAge (Netfective)
 ReDSeeDS (WUT)
 Migrate
 Modelio (SOFTEAM)
 Deploy
 Cloudscript (SINTEF)
 Manage
 Desktop2Cloud (Uni. Tartu)
12

13. The focus of this presentation is the
Migration process.
13
Migration Process

14. The DOME Case Study: Managing
Travel Providers
 DOME Consulting
 Solutions for effective management of multiple kinds of travel
related providers
 DOME Software
 Delphi + PL/SQL
14

15. In the end we want to go to the
Cloud…
 AmazonEC2 IaaS
 On the UI: JEE+JSF
 On the Server: JBoss + Derby database
15

16. Modelio Orchestrated Migration
Process
Recovery Recovered
Model
Component
Recovery
Model
Migration Architecture
Model
Implementation
Model
Test Model
Deployment Deployment
Model
Deployed
Implementation
Model
Deployed Test
Model
16

17. Modelio Orchestrated Migration
Process
Recovery Recovered
Model
Component
Recovery
Model
Migration Architecture
Model
Implementation
Model
Test Model
Deployment Deployment
Model
Deployed
Implementation
Model
Deployed Test
Model
17

18. The Recovered Model: Entities,
Services and Business Processes
18
Entities
Services
Behavior

19. Modelio Orchestrated Migration
Process
Recovery Recovered
Model
Component
Recovery
Model
Migration Architecture
Model
Implementation
Model
Test Model
Deployment Deployment
Model
Deployed
Implementation
Model
Deployed Test
Model
19

20. From Services to Components
20
Objective:
1. Identifying components by
grouping Entities and Services
2. Classifying components into:
• Behavior
• Presentation
• Data

21. Output: The Component Model
21
Behavioral components Data components
Presentation
component

22. Modelio Orchestrated Migration
Process
Recovery Recovered
Model
Migration Implementation
Model
Test Model
Deployment Deployment
Model
Deployed
Implementation
Model
Deployed Test
Model
22

23. Thinking about the Architecture with
SoaML, …
23
Participants
Services
Interfaces

24. then the User Interface using MVC, …
24
User Interface Modelling
Behavior Modelling

25. … finally a detailed description of the
Entities and Relationships
25
Entities
Relationships

26. Modelio Orchestrated Migration
Process
Recovery Recovered
Model
Component
Recovery
Model
Migration
Deployment Deployment
Model
Deployed
Implementation
Model
Deployed Test
Model
26

27. Now we start thinking about the
implementation details
27
Implementation level
details

28. Modelio Orchestrated Migration
Process
Recovery Recovered
Model
Component
Recovery
Model
Migration
Deployment
Deployed
Implementation
Model
Deployed Test
Model
28
Implementation
Model
Test Model

29. How to package the new system into
meaningful packages?
29
Implementation
Packages
Deployment
Packages

30. Modelio Orchestrated Migration
Process
Recovery Recovered
Model
Component
Recovery
Model
Migration Implementation
Model
Test Model
Deployment Deployed Test
Model
30

31. Deploying the application with
PIM4Cloud
31
Cloud Resources
Installed Packages

32. Current State
 Experimenting with Migration
 Actually supports JEE based IaaS
 Working on CloudML standardization (based on
PIM4Cloud)
32

33. Lessons Learned
 Model based web design may not be a good idea…
 But model based refactoring is!
 Process may need to be improved
 Maybe consider deployment as early as possible
 Cloud providers constraints need to be considered when defining the
architecture of the application.
33

34. Thank you for your attention!
Marcos Almeida
SOFTEAM | ModelioSoft
marcos.almeida@softeam.fr
SOFTEAM R&D Web Site:
http://rd.softeam.com
ModelioSoft Web Site:
http://www.modeliosoft.com
www.modelio34