Migration of form based legacy systems towards service-oriented computing is a challenging task, requiring the adaptation of the legacy interface to the interaction paradigm of Web services. In this paper, a wrapping methodology is proposed to make interactive functionalities of legacy systems accessible as Web Services. The wrapper that is used for interacting with the legacy system acts as an interpreter of a Finite State Automaton that describes the Model of the Interaction between user and legacy system. This model is obtained by black box reverse engineering techniques. A migration process and a software architecture that allow a functionality of a legacy system to be exported as a web service are presented in the paper.

1. Migrating Interactive Legacy
Systems To Web Services
Porfirio Tramontana
Anna Rita Fasolino
Giovanni Frattolillo
Dipartimento di Informatica e Sistemistica
University of Naples Federico II, Italy
Gerardo Canfora
RCOST – Research Centre on Software Technology
University of Sannio, Benevento, Italy
1

2. Motivation
 Growing interest is currently being devoted to Service Oriented
Architectures
 IDC estimates that worldwide spending on Web services-based
software projects will reach $11 billion by 2008, compared to $1.1 billion
in 2003 (Neal Leavitt, IEEE Computer, November 2004)
 Possible approaches for obtaining Web Services
 Developing them from scratch
 Reusing existing software
 Legacy Systems pervade fundamental productive activities:
 Public administration, bank, tourism, customer relationships, …
 A relevant issue: migrating legacy system functionalities toward
Web Services
2

3. Three basic questions …
1. What to expose as a Web Service?
2. When the migration is convenient?
 G. Lewis, E. Morris and D. Smith have approached this question
in the yesterday tutorial and in the previous talk …
 S. Tilley, J. Gerdes, T. Hamilton, S. Huang, H. Muller, K. Wong
also outline the challenges inherent in migrating to Web services
3. Which approaches for the migration?
 Sneed and Sneed present a tool supported process to make
accessible selected sections of legacy code as Web Services;
 E. Stroulia, M. El-Ramly, P. Sorenson propose methods based on
the analysis of screen features and on the tracing of user
interactions to reverse engineering interfaces of an interactive
legacy system in order to support the migration
A specific problem:
the migration of interactive legacy system functionalities toward
Web Services 3

4. Comparing Interaction paradigms…
Form based Interactive Systems Web Services
Users query the system by inputting A Client party invokes a
data and sending commands, by service implemented by a
interacting with the user interface. provider party, using a request
message.
System answers by producing a The provider processes the
response screen, containing output request and sends a response
values and new input fields and message with the obtained
command buttons results.
Req
Resp
Which approaches for the migration?
Wrapping 4

5. The Wrapper
 The goal of the wrapper is to drive the legacy system during the
execution of each possible interaction scenario associated with
the use case to migrate, by providing it with the needed flow of
data and commands.
 The wrapped legacy system use case is accessible as a Web
Service
Application Server
Web
Wrapper
Service
Request
Legacy System
Web
Service
Respons
e
5

6. A key requirement of the Wrapper
 The wrapper must be reusable for migrating different use
cases, so…
 The wrapper behavior requested for each use case will
not be embedded in the wrapper…
 But it will be separately specified for each use case
 A key question: obtaining for each use case a complete
model of the interaction between the legacy system and
the user
 A Reverse engineering problem!
6

7. Modelling Interactions between User
and Legacy System
Input: 3
Input: /
Input: 4
Input: Quit
An example: a scenario from the
“Division” use case of a legacy
calculator program
7

8. The Model of the Interaction
 A Finite State Automaton FSA= (S, T, A, Sin, Sfin)
where:
 S is the set of Interaction States,
 A is the set of Actions performed by the user when an Interaction
State occurs,
 T is the set of Transitions between states,
 Sin and Sfin are the Initial and Final states of the interaction.
+ First A1 Second A2
Menu quit
Operand Operand Result Menu
Request Request
Initial State Final State
Interaction States Transitions Actions
8

9. A problem
Access
Login Password Permitted
Login Password
Request Request Password
?
Password Access
Denied
What the next State?
 The next state depends on the internal logic or on the internal state of
the legacy system.
 A solution: Non Deterministic Finite State Automata
 a Non Deterministic Finite State Automaton (NFA) is a
finite state machine where for each pair of state and input
symbol there may be several possible next states
9

10. Another Wrapper Requirement
 The wrapper must know the list of the possible Next States of a given State
 Possible successors of Password Request State are Access Permitted and
Access Denied states
 The wrapper must be able to identify the current state on the basis of the
returned screen
 Wrapper must discriminate among Access Permitted screen and Access Denied
screen
Access
Password Permitted
Login Login Password
Request Request
Password
Access
Denied
Same Action, but different Transitions!
10

11. Screen Templates
 A description of Legacy Screen is needed for the identification: Screen
Templates
 A Screen Template is a collection of Fields:
 Labels;
 Input Fields;
 Output Fields;
 Each field has a Location on the Screen. Location may be defined as a:
 Fixed Location, i.e. coordinates of the field;
 Relative Location, i.e. distance from another field.
Initial Cursor Position
Fixed Location
x 1 *
y
Locati on 1 * Field * Screen Template
1 optional
size
Relati ve Location
*
offset x
offset y
Label Output Fi el d Input Fiel d
Regul ar Expression Value Value
11

12. Characterising Interaction States
 An Interaction State is characterised by a
Screen Template and a set of actions to
perform on its fields, causing transitions to
other Interaction States
 User Actions may be: Screen T empl ate Set Input Field
Value
 Set Input Field Actions 1
* *
 Get Output Field Actions Interaction State 1 1..* User Action Get Output Field
Value
 Submit Command Actions +to
*
+from Submit
Transi ti on Command
12

13. Wrapper Architecture
Application Server
Wrapper
State Screen
Identifier Template
FSA
Legacy Terminal Description
Identified Legacy Screen, Description
System Emulator Interaction State Current State
Document
Actions Automaton
Legacy Screen Engine
Web Service Web Service
Request Response
13

14. Terminal Emulator
Legacy Terminal
System Emulator
Actions Automaton
Legacy Screen Engine
 The Terminal Emulator component is
responsible for the dialogue between the
Wrapper and the Legacy System terminal
 Different implementations of the Terminal Emulator
are needed for different Legacy System Terminals
 Stream Oriented terminals;
 Block oriented terminals;
 Web Applications.
14

15. State Identifier
 The State Identifier State
component is responsible Identifier
Screen
Template
FSA
for the identification of the Legacy Screen,
Description
Description
Interaction State reached Current State
Document
by the Legacy System Automaton
Engine
 It has to match the current screen of the legacy system with the
Screen Templates associated with potentially reachable
Interaction States
 The Screen Templates descriptions are part of the Automaton
Description Document
 Moreover, the State Identifier
 localises Labels
 localises Input Fields
 Localises Output Fields and read their values
15

16. Automaton Engine
 The Automaton Engine is responsible for interpreting the FSA
associated with a given service offered by the legacy system. It:
 Sends commands to and receives screens from the Terminal Emulator
 Queries the State Identifier about the identification of the Current
Interaction State
 Interprets the request message received from the application server
 Builds the response message and sends it to the application server
 Manages Automaton Variables (i.e. temporary variables needed to save
intermediate results of the execution of the Automaton)
NOT (Current Interaction State = Final State)
Start Activity Interpretation Activity
do/ Get Request Message do/ Get Output Field Values Current Interaction
do/ Set/Update Automaton Variables Final Activity
do/ Init Automaton Variables State = Final State
do/ Start Legacy System do/ Set Input Field Values
do/ Build Response Message
event Legacy Screen Returned/ Get Legacy Screen do/ Submit Transition Command
do/ Identify Current Interaction State event Legacy Screen Returned/ Get Legacy Screen
do/ Identify Current Interaction State
16

17. Finite State Automaton Description
Document
Fixed Location
Relative Location
<automa> <screen id="GoToHeader">
Location offset x
x
offset y <automa-states> <size width="80" height="25"/>
y
Transition
1 1 * <simple-field id="GoToHeaderId"
+to 1
…. optional="false" input="false">
* 1 Initial Cursor Position
+from
* *
Label
<fixed-location>
* Interaction State Screen T emplate
*
*
Field <state id="go_to_header" type="automa" <point x="0" y="22"/>
Regular Expression
1
1 screen="PineGoToHeaderScreen"> </fixed-location>
1 1
<description>State <content pattern="Message number to
*
</description> jump to" length="25"/>
1 Get Output Get
<layout> </simple-field>
Output Fi eld Input Fi eld
Field Action <location x="1" y="2"/> <simple-field id="prompt" optional="true"
* *
Submit Com mand
1 <size width="8" height="2"/> input="true">
Action
Command
</layout> <fixed-location>
Set <actions> <point x="25" y="22"/>
* <set-fields-action> </fixed-location>
Set/Update Automaton
* * <field ref="prompt"> <content pattern="" length="5"/>
Set Input Field
Response Variable Action
Action
<data ref="/root/header"/> <focus order="1">
Expression
Expression </field> <advance-key id="ENTER"/>
1
Build * </set-fields-action> </focus>
*
Request 1 Set/Update Get </actions> </simple-field>
1 Build Response Action <next-states> <caret-location>
Get
1 Get 1
<next-state ref="bad_header"> <fixed-location>
*
1 1 * </next-state> <point x="28" y="22"/>
Init Action Automaton Variable
<next-state ref="header"> </fixed-location>
* </next-state> </caret-location>
</next-states> </screen>
Set
</state>
…
Automaton Description
</automa-states>
</automa>
Document UML model
An excerpt of an Automaton
Description Document
17

18. A Case study
 A migration case study has been carried out
according to a process including the following
phases:
 Identification, i.e. reverse engineering of the
interaction model;
 Design, i.e. defining the FSA describing the Wrapper
behaviour;
 Implementation, i.e. realisation of the XML FSA
Description Document;
 Web service deploy, i.e. deployment of the wrapper in
the context of an application server;
 Validation, i.e. testing of the scenarios of the migrated
use case
18

19. A Case Study
 Legacy system: Pine (ver. 4.64)
 client mail software, that allows a user to read, compose and
manage e-mail messages from an existing message box.
 Pine is a form based legacy system based on stream
oriented terminals.
 Usually, Pine is accessible via the Telnet protocol.
 We submitted to the migration process the Get Message
use case that allows the owner of a mailbox to get the text
of a specific e-mail message contained in a specific
mailbox folder.
Use case: Get Message
Preconditions None
Input Login, Password, Folder, Message Number
Output Date, From, To, cc, Subject, Body, Exception
Postconditions None
19

20. The Automaton: graphical view
Login
1 2 Password 4 Folder
g 5 8 9
Authentication Authentication Menu Main j
Go To Folder Folder Open Go To Message
Menu (Ask Login) (Ask Password) Menu
Folder
Password
Folder Mess.Numb. Mess.Numb.
3
Authentication 6 7 10
12
Menu (Incorrect q Folder Not Empty Folder Bad Message
Header
Password) Found Number
17
Exit Confirm
<Control>C q <enter>
(Folder Not >
18
Found) 11
16 Exit Confirm 13
Folder Open
Main Menu (User (Empty Folder) Message First
(Bad Message
not admitted) Page
q Number)
19
q
y Exit Confirm <space>
21 (Bad Message
y <space>
Exit Confirm y Number)
(User not 14
7 different scenarios: admitted)
y y
20 q
15
Message End
Message Mid
Exit Confirm Page
1) One Page Message (Read Message) <space> <space>
2) Read
Two Pages Message
Read
More than two Pages Message Read
Bad Message Number
Empty Folder
Folder Not Found
7) Incorrect Password 20

21. The Automaton: a tabular specification
Interactio Interaction State Description Actions Submit Next
n State ID Command State
START Init (Login, Password, Folder, Message Number) 1
1 Authentication Menu (Ask Login) Set Input Field: Login <Enter> 2
2 Authentication Menu (Ask Set Input Field: Password <Enter> 3,4
Password)
3 Authentication Menu (Incorrect Set Automaton Variable: Exception = “Incorrect Login and <Control>C 16
Password) Password”
4 Main Menu g 5
5 Go To Folder Set Input Field: Folder <Enter> 6,7,8
6 Folder Not Found Set Automaton Variable: Exception = “Folder not found” q 17
7 Empty Folder Set Automaton Variable: Exception = “No messages in the folder” q 18
8 Folder Open j 9
9 Go To Message Set Input Field: Message Number <Enter> 10,12
10 Bad Message Number Set Automaton Variable: Exception = “Incorrect Message Number” <Enter> 11
11 Folder Open (Message not found) q 19
12 Header > 13
13 Message First Page Get Output Fields: (Date, From, To, Cc, subject,, Body); <Space> 14,15
Set Automaton Variables: (Output: (Date, From, To, Cc, subject,
Body))
14 Message Mid Page Get Output Field: Body <Space> 14,15
Update Automaton Variable: Body = Body + Output:Body
15 Message End Get Output Field: Body q 20
Update Automaton Variable: Body = Body + Output:Body
16 Main Menu (User not admitted) q 21
17 Exit Confirm (Folder Not Found) y END
18 Exit Confirm (Empty Folder) y END
19 Exit Confirm (No Message) y END
20 Exit Confirm (Read Message) y END
21 Exit Confirm (User not admitted) y END
21
END Build Response: (Date, From, To, Cc, Subject, Body, Exception)

22. Testing Strategy
 A Test Suite comprehending 7 Test Cases had
been selected in order to cover the 7 linear
independent paths individuated on the FSA
TC# TC Description Interaction State Sequence
1 One Page Message Read S-1-2-4-5-8-9-12-13-15-20-E
2 Two Pages Message Read S-1-2-4-5-6-9-12-13-14-15-20-E
3 More Than Two Pages Message Read S-1-2-4-5-8-9-12-13-14-14-15-16-21-E
4 Bad Message Number S-1-2-4-5-8-9-10-11-19-E
5 Empty Folder S-1-2-4-5-7-18-E
6 Folder Not Found S-1-2-4-5-6-17-E
7 Incorrect Password S-1-2-3-16-17-E
 We noticed that all the 7 scenarios of the
migrated use case had been covered by the
selected Test Suite 22

23. Conclusions
 A method and a tool supporting the wrapping of
interactive legacy system have been presented
 A preliminary experiment showed the
effectiveness of the approach
 A more detailed description of the potentialities of the
tool and of the experiment that have been carried out
will be presented in the Tool Demo Session after the
lunch!
 Many ideas for future works arises …
23

24. Open problems and future works
 Definition of criteria for identifying migrable use cases
 Exploring the feasibility of the approach for the migration of different
categories of legacy systems:
 Legacy system using block oriented terminals
 Legacy Web Applications
 Defining and validating reverse engineering approaches for
obtaining the FSA specification (in particular Screen Template
description)
 Concept Analysis approaches
 Feature Selection approaches
 Exploring the scalability of the approach for more complex
functionalities to migrate
 Identification of elementary functionalities to be migrated
 Orchestration of migrated functionalities obtaining complex services
24

25. 25