Migrating Interactive Legacy Systems To Web Services

1,018 views

Published on

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.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,018
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • IDC = International Data Corporation
  • What is possible to expose as a Web Service? Feasible approaches for the migration: White Box Reverse Engineering techniques Invasive approaches they need source code analysis and manipulation Black Box Reverse Engineering techniques The only feasible solution if the source code Is not accessible/modifiable Wrapping
  • Legacy systems are often based on form based user interface --- Vicewversa WS
  • Each State is associated with a different state of the user interface Actions cause Transitions Initial State is started by Legacy System launch; Final State is started by Legacy System closure
  • The Wrapper does not depend on the specific use case to migrate, but it is able to interpret any Automaton described according to the FSA description format
  • Stream Oriented terminals: They exchange data with the legacy system by using a bi-directional, byte oriented communication channel; The input typed by the operator are sent to the legacy system as soon as typed; The legacy system performs the required elaboration and then sends the output back to the terminal; The screen is organised as a matrix of characters.
  • Sposterei il processo di wrapping qui, introducendolo come il processo di migrazione seguito nel caso di studio
  • In this Section, a case study that was carried out for exploring the feasibility of the proposed migration approach will be presented.
  • Actions = Automaton Engine Actions Submit Command = Action launching a Transition
  • Si potrebbe eliminare per dirlo a voce
  • Migrating Interactive Legacy Systems To Web Services

    1. 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. 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. 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. 4. Comparing Interaction paradigms…Form based Interactive Systems Web ServicesUsers query the system by inputting A Client party invokes adata and sending commands, by service implemented by ainteracting with the user interface. provider party, using a request message.System answers by producing a The provider processes theresponse screen, containing output request and sends a responsevalues and new input fields and message with the obtainedcommand buttons results. Req Resp Which approaches for the migration? Wrapping 4
    5. 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. 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. 7. Modelling Interactions between User and Legacy System Input: 3 Input: / Input: 4 Input: QuitAn example: a scenario from the“Division” use case of a legacycalculator program 7
    8. 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 RequestInitial State Final State Interaction States Transitions Actions 8
    9. 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. 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. 11. Screen Templates A description of Legacy Screen is needed for the identification: ScreenTemplates  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. 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. 13. Wrapper Architecture Application Server Wrapper State Screen Identifier Template FSALegacy Terminal Description Identified Legacy Screen, DescriptionSystem Emulator Interaction State Current State Document Actions Automaton Legacy Screen Engine Web Service Web Service Request Response 13
    14. 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. 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. 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. 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"/> yTransition 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. 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. 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. 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 147 different scenarios: admitted) y y 20 q 15 Message End Message Mid Exit Confirm Page1) One Page Message (Read Message) <space> <space>2) Read Two Pages Message ReadMore than two Pages Message ReadBad Message NumberEmpty FolderFolder Not Found7) Incorrect Password 20
    21. 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. 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. 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. 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. 25

    ×