Towards a Framework for Migrating Web Applicationsto Web Services

Asil A. Almonaies Manar H. Alalfi James R. Cordy Thomas R.Dean

School of Computing, Queens UniversityKingston, Ontario, Canada

{asil,alalfi,cordy,dean}@cs.queensu.ca

Abstract

Migrating traditional legacy web applicationsto web services is an important step in themodernization of web-based business systemsto more complex inter-business services and in-teractions. While the problem of migratingvarious kinds of legacy software systems to aservice oriented architecture (SOA) environ-ment has been well studied in the literature, ap-proaches to migrate dynamic web applicationsto web services are lacking. In this paper weoutline the requirements for a semi-automatedapproach to migrate dynamic legacy web appli-cations to web services-based SOA applicationswhile preserving the original web application’sbusiness processes. A manual demonstrationof our approach is presented using two exam-ples from Moodle, a popular open source coursemanagement system. The migration process isguided by three goals: user interface plasticity,code refactoring and load balancing.

1 Introduction

There are a number of different approaches inthe literature to migrate various kinds of legacysoftware systems to a service oriented archi-tecture (SOA) environment [20, 10, 9, 21, 4].However, approaches to migrating web appli-cations to web services are lacking [2]. Manylegacy web applications are implemented us-

Copyright c� 2011 Asil A. Almonaies, Manar H. Alalfi,

James R. Cordy, and Thomas R.Dean. Permission to

copy is hereby granted provided the original copyright

notice is reproduced in copies made.

ing scripting languages such as PHP [3] orPython [7]. These languages are dynamicallytyped, reflexive and support dynamic changesto the code. In addition, PHP only fully sup-ported object oriented programming in version5 [16]. The continuing evolution of these ap-plications has resulted in implementations inmixed programming paradigms. For instance,while some modules in moodle are built us-ing the object oriented paradigm, other mod-ules are non object oriented, while others mixthe two paradigms in interesting ways. Thismixture of highly dynamic applications mixedparadigms, and the multilingual code bring thechallenge to the analysis and refactoring oflegacy web application systems for the purposeof migrating them into SOA. To the best of ourknowledge this work is the first effort to addressthese type of applications.

An additional challenges in modernizing alegacy system is the identification of the suit-able set of services in the legacy code that havebusiness value. We believe that the need fortools and techniques for analyzing large sourcecode bases to uncover and expose the code thatimplements business value as services is a cru-cial area of practical research. These tools andtechniques needs to take into consideration theunique characteristics of legacy scripting basedweb application, and this is one of the purposesof our work.

Web applications can be defined as the set ofweb pages (.aspx, .jsp, and HTML files), han-dlers, modules, executable code, and other files,such as images and configuration files, that canbe invoked from a web server. Currently, webapplications are facing new challenges, such as

Figure 1: The Proposed Approach

the ability to manage complex processes acrossmultiple users and organizations, to intercon-nect software provided by different organiza-tions, and the ability to create complex com-bined business scenarios.

To address these challenges, web services canbe used as an enabler technology that providessystem-to-system interaction and permits theimplementation of business constraints usingprocess control primitives to more easily adaptto these new requirements [6]. The migrationof traditional legacy web applications to webservices is therefore an important step in themodernization of web-based business systemsfor the new world of complex inter-business ser-vices and interactions.

Using web Services and SOA it is possi-ble to design and build web-based systemsand applications using independent, hetero-geneous, network-addressable software compo-nents. SOA organizes the computer softwareinto a collection of separate services that com-municate with each other. It focuses on a loosecoupling of the integrated elements, using a setof enabling technologies provided by web ser-vices such as XML, Simple Object Access Pro-tocol (SOAP) [25], Web Services DescriptionLanguage (WSDL) [26] and Universal Descrip-tion Discover and Integration (UDDI) [14] toachieve flexibility and agility. Using SOA, un-necessary dependencies between systems and

software elements are minimized, while main-taining functionality. Service-oriented archi-tecture can help to close the gap between ITprofessionals and the business professionals inan organization. It also reduces costs and in-creases return on investment because it focuseson the concept of reusability. A primary reasonfor its use is to improve business communica-tion, so that the goals of the enterprise can bemore directly and readily realized.

The contributions of this paper are:

1. Exploring the issues of the migration of amonolithic web application to SOA, lead-ing to a future semi-automated migrationframework. The analysis and refactor-ing of such system have a unique chal-lenges due to the highly dynamic nature ofthe legacy system, poorly structured code,multilingual code and weakly typed lan-guages.

2. A manual demonstration on the use of ourapproach to migrate two of the most inter-esting functionalities in Moodle, user au-thentication and the file upload. Our mi-gration process is guided by three goals:user interface plasticity, code refactoringand load balancing.

The remainder of this paper is organized asfollows. Section 2 describes our approach for

identifying and separating services. Section 3describes our first case study and our initial ef-forts to expose some of the functionalities ofthe Moodle LMS [13] as web services. Section4, reviews related work in migrating web appli-cations to web services, and Section 5 summa-rizes the present state and future directions ofour project.

2 Approach

In general, there are three goals when migrat-ing to web services:

• User interface plasticity, which is the ca-pacity of user interfaces to adapt, or to beadapted, to the context of use while pre-serving usability [5].

• Load balancing, which is a technique todistribute the the workload evenly acrosstwo or more computers, network links,CPUs, hard drives, or other resources, inorder to get optimal resource utilization,maximize throughput, minimize responsetime, and avoid overload [23].

• Code refactoring, which is a disciplinedtechnique for restructuring an existingbody of code, altering its internal structurewithout changing its external behaviour inorder to improve some of the nonfunctionalattributes of the software [11].

The proposed approach explores the areaof moving a dynamic monolithic web applica-tion to SOA with significant levels of automa-tion. The result can be considered as a service-oriented web application that implements theendpoints of a web service. The approach canalso be used to combine different sets of servicesfrom two or more different web applications toconstruct a new web service application whichbehaves like the two original applications to-gether.

The proposed approach (Figure 1) consistsof four main steps:

1. Identify independent services within theweb application. The main challenge inmodernizing any legacy system is findingthe business services in legacy code by

identifying business value in the large codebase. The first step in our approach is toidentify potential business services in theweb application.

2. Separate services in the original web appli-cation (that is, break the web applicationlogic into separate services). In this step,and because we are in the first instance mi-grating PHP-based web applications, weexpect to use two technologies:

• Service Component Architecture(SCA) [19], which provides an easyway to create and access servicesin PHP. It allows PHP scripts toexpose class functions as services andallows class functions to access otherservices regardless of whether theyare local to the current web server orrunning on a different web server.

• Service Data Object (SDO) [19],which provides a uniform PHP inter-face for handling different forms ofdata and provides a mechanism fortracking changes in data regardless ofwhere the data resides.

3. Migrate the separated services to SOAcomponents. Deciding which servicesshould be selected is a major issue and it isimportant to have a set of criteria in orderto determine the priority for choosing sep-arated services to be included in the targetSOA to avoid the selection of redundant orinefficient services.

4. The final step is the re-integration ofthe selected services into a new service-oriented application. The developed ser-vices will be combined to provide theoriginal system functionality as a service-oriented architecture. The result will bean SOA implementation of the originalweb application functionality.

The approach will be evaluated on an exist-ing production open source monolithic web ap-plication to demonstrate that the original ap-plication can maintain its original functionalitywhen moved to a web services-based SOA ar-chitecture using the approach.

Figure 2: SCA extension (taken from [15])

2.1 PHP SOAP Implementa-tions: SCA

There are several technologies that offer exten-sions for developing web services in PHP:

• NuSOAP: a group of PHP classes thatallow developers to create and consumeSOAP web services [18].

• PEAR: SOAP, and a SOAP Client/Serverfor PHP [24].

• Service Component Architecture (SCA)and Service Data Objects (SDO), whichare standards for enabling service-orientedarchitecture. SCA and SDO are imple-mented in several programming environ-ments, such as Java, C++, and PHP[12].

In our approach we chose to use SCA andSDO, because they are straight forward to in-stall, adopt and understand. In addition, byusing the SCA extension, we are able to imple-ment reusable services using composite refer-ences. SCA also provides bindings other than

SOAP, such as XML-RPC, JASON-RPC, andREST-RPC [19], making our results more flex-ible. Figure 2 shows the implementation ofSCA in PHP. SCA and SDO consists of twoparts. The first part is a dynamic library thatextends the php interpreter module of the webserver. This extension library scans for anno-tations given in comments to recognize a PHPclass as a web service. This is shown on the leftof figure 2. The annotation @service, shownat the top of the file MyService.php designatesthe class as a web service. The @binding an-notation tells the extension which binding touse for the web service. If ws is soap, thenthe SOAP bindings is used for the web service.One feature is that the WSDL descriptions areautomatically generated when the wsdl param-eter is added to the invoking url (e.g. http ://hostname/MyService.php?wsdl.

The second part of SCA and SDO for PHPis a set of utility functions defined in the in-clude file ��SCA/SCA.php�� used to find andinvoke SCA services. The SCA infrastructurehandles the invocation of other SCA services,

Login Service Moodle Login: Moodle provide a login page to all its users (administrator, teacher, student and guest), where a user name and password are required (administrator, teacher, student) which their information are checked against Moodle�’s database. We applied code refactoring on the index.php file which is the main login page of Moodle in order to provide us with the basic login functionality which is supplying a user name and a password.

Functions are called in the three main Moodle libraries:

lib/moodlelib.php : contains general stuff. lib/weblib.php -: related to output of HTML lib/dmllib.php �– related to getting data in and out of the database.

Function user_login($username, $password);

This is the primary function used to login users into Moodle. You can do what you need in this function to finally return a boolean indicating the matching or mismatching of the given username and password.

There are several authentication methods done in Moodle for our case study we will adapt the manual authentication which Just do a simple check of the user name and password against the Moodle database. (Should I mention the other authentication methods)?

Fig 2: The login hierarchy

auth.php

Index.php

authlib.php

Figure 3: Moodle’s login hierarchy

including those written in other implementa-tion languages.

3 Case Study

We use Moodle [13], a popular open sourceCourse Management System (CMS) to explorethe issues in SOA migration. Moodle standsfor “Modular Object-Oriented Dynamic Learn-ing Environment”. It allows teachers to createonline courses, which students can access as avirtual classroom. A Moodle home page in-cludes a list of participants (teacher and stu-dents), a calendar with a course schedule, andlist of assignments. Other interesting featuresinclude: online quizzes and forums, where stu-dents can post comments and questions, glos-saries of terms, and links to other web re-sources.

Moodle users have four primary roles: ad-ministrator, teacher, student, and guest. Wechose Moodle because it is widely used interna-tionally, has good documentation and a strongsupporting developer community. While Moo-dle exibits a plug-in architecture, it is accom-plished using include files, classes and methodcalls in a monolithic web application. SinceLearning Management Systems (LMS), whichprovide Internet- based education, are becom-ing very popular in academia, it is one of thefirst approaches to provide web services forLMS users using the SCA extension.

We investigate the issues of code refactoringby investigation the migration of Moodle’s lo-gin functionality to expose it as a service and ofuser interface plasticity by investigating the file

upload service. There are some reusable andreliable functions with valuable business logicembedded in any legacy system. These func-tions are useful to be exposed as independentservices.

While our work is aimed at automating theextraction of the relevant functionality to beselected as services, and in order to developsuch a capability we need first to understandhow this extraction can be done. In this firstexperiment, we demonstrate the manual ap-plication of our approach to the migration ofsome of the interesting internal functionalitiesof Moodle, such as the login process, that canbe reused. We have manually analyzed Moodlein a top-down manner, dividing basic function-alities into sub-functionalities in order to gaininsight into the application, and as a result wehave identified a number of potential indepen-dent services.

3.1 Example 1: Login Process

Moodle provides a single login page to allits users (administrator, teacher, student andguest), where a user name and password arerequired (administrator, teacher, student) andtheir information validated before the user isallowed to continue. The code that generatesand processes page is in login/index.php, rel-ative to the Moodle base directory. Login isthus the first functionality we have identifiedas a potential service.

���������������� ��������� ������������� ���������� ������������

������������ ��!���"#��$�%�$&'(�)�**��+�$��,������������� ����-������ ��������� ����-���-�������.���/��,�������/���*���0'�$!�/�� �-��)���������1���*���0'�$!���//1����)������������� ��/��2��1����,��������������3'4!�/�� �-��)�*��/����������� ��������� �/���//���-���������.���/��,�������� ��������� �������-���������.����.

�5

Figure 4: Simplified login/index.php page

������������� ��������� ���������� ������������ ���������

�� ��� ���� �������������� ���������������� � ����� ��������������� ����� ������������������������� ������ �����

������������!� �"������� ���������������� �������#$���� �����������%�$

Figure 5: Authentication Code

3.1.1 Moodle’s Login Identification

Moodle’s login functionality is already struc-tured as multiple plugins which are providedusing an factory routine that chooses the cor-rect login method based on configuration in-formation. While one approach provides a newplug-in for an SOA method, we instead chooseto investigate migrating one of the existingplug-ins to an SOA environment. We start ana-lyzing the code manually to identify the candi-date functionalities. We have identified severalof the authentication plugins used in Moodle:

• Manual authentication : accounts are cre-ated manually by an administrator.

• Email authentication: accounts are cre-ated manually by the users.

• LDAP authentication: accounts informa-tion are on external Lightweight DirectoryAccess Protocol server.

• Nologin authentication: accounts are sus-pended.

We choose to investigate the first option,manual authentication which does a simplecheck against the Moodle database. This func-tionality is spread over the following php pages:

• login/index.php : which is the default loginpage.

• lib/moodlelib.php: contains the func-tion authenticate user login() called by in-dex.php which get the list of all the en-abled authentication plugins.

• lib/auth/manual/auth.php: contains themanual authentication.

• lib/authlib.php: contains all the authenti-cation plugins types.

������������� ������ �����������

���������������������� ��������������������������� ���������!�� "��������� ��

���������#!�$%&%'(�)�*+,-�� ��������������������������������!.���������.��� �������� !.��.�������������!�#�������#������#������� ����#��������������������!�#��������������������

����������!!/���������������01������� �!!��������������������������2�����������������������������2��22

�1

Figure 6: Manual authentication module

The Moodle login logic hierarchy is as shownin (Figure 3). From the above authenticationmethods supported by Moodle, we will adaptthe manual authentication method, which justdoes a simple check of the user name and pass-word hash against the Moodle database.

3.1.2 Moodle’s Login Refactoring

We begin with the Moodle login page in lo-gin/index.php which is responsible for display-ing the form that allows the Moodle users toenter their information. It also includes theauthentication code that uses the function lo-gin which takes two parameters; the usernameand password. We have produced a simplifiedversion of the login code to illustrate the differ-ences shown in figure 4.

Figure 5 shows the simplified code in au-thenticate.php. In Moodle, this is an factorymethod that instantiates the class that imple-ments the login method given in the configu-ration file and invokes the login method. Wehave simplified to code to instantiate and callthe class that implements the manual methodof user authentication.

Figure 6 shows our simplified version of theoriginal manual authentication code. Whilesimplified it still reflects the basic function-ality of Moodle’s manual method. The userpassword is hashed using md5 and the valuesare checked in the internal Moodle database.

If there, the function returns true, otherwisefalse.

3.1.3 Moodle’s Login New Service

In this case the migration to SOA is straight-forward. We create a copy of the original codewith a new name (file and class name mustmatch in php). We add the include statementfor the SCA library, and annotations for theclass and method. This includes the @serviceand @binding.soap annotations for the class,and the parameter and result annotations forthe login method. This enables the class as aremote service.

The original class is replaced by a wrapper asshown in figure in (Figure 8). The PHP versionof SCA automatically generates a WSDL file ifthe php file is invoked remotely with the wsdlparameter. Thus the wrapper starts by gen-erating a WSDL file from the remote serviceand saving it locally (production code cachethe WSDL file). This file is then used to in-stantiate the service and then call the remoteservice. The result of the service is returned tothe calling function (i.e. login).

Thus authenticating a user from lo-gin/index.php is accomplished by calling thefactory login routine in authenticate.php. Thefactory routine instantiates the wrapper classin authmanualSOA.php and invokes the login,which in turn calls the remote service.

������������� ������ ������������ ����������������������������� �����!�������"���� �"���"�#�$"��"��%�&��$�#��'������"�"$��#����(�����"$�����"�"$��#����(�"��)��������#����!����"������ #��������(�����"$�*(�"��)����'(��+�$�,�(�"��)�����(����-+���./.�0���12%3�$�������)����������"$�+�(�����"$���"����"��)���+�(������

4�5

Figure 7: Remote Version of Manual Authentication

������������� ������ ������������ ������������������� ��������� ������!�"�#��� ���������$�%$��#$��&������� �������������'��� �������������� �� ��������������� ������!�"�� ��������(������������ ������������� ������!�"�� ����(����%$���$���) ��&����''������) ��������� ������!�"�� ����(������$�������&�$���) �*+�����$�%$����������$�������,

,�+

Figure 8: Wrapper Class to Call Remote Service

3.2 Example 2: File Handling

As a course management system, Moodle pro-vides a facility to allow users with the teacherrole (i.e. professors, TA’s) to provide files forstudents to download. The file functionality inmoodle allows teachers to upload, organize, re-name, delete and generate zip archives of thefiles.

In this experiment we focus on converting thefile uploading functionality to a service. Onceconverted to a service, the Moodle’s multi-pagebased file management interface can be con-verted to a more interactive Ajax interface.Thus the objective of this activity is user inter-face plasticity. As with the login functionality,the base logic of the file management function-

ality is located in files/index.php in the Moodledirectory.

3.2.1 Moodle’s File Uploading Identifi-cation

The main code of the file module is locatedin files/index.php. There are also several li-brary files used to implement file uploading,adminlib.php (which contains functions thatis used by the administrators), filelib.php andfile.php(which contain functions for analyzingfile content and file types), and uploadlib.phpwhich contains the class that manages the up-load functionality. What makes this more dif-ficult is that presentation logic and file man-agement is spread throughout the upload class.

���������������� �����������������������������������

��������������������

������������� ������������������������������������������������������������������������������������������������������ ���!��������������������"���������������"��������������#��

��

$

���������������� �����%�����#������������ ������##���������������$����&� ������� ����������'���� �����(#�))������'��*��(����!#��

���������+,,�-������������������������������������������� �,+����������� ����������������#��

������������������������������� ������� ��������� .����'��('���� �����(���������������+������ .����'��('������(##��� �

��������������������+������� .����'��('������(���/01 .�������� ��������#�� �

���� .����'��('���������(����������������+������ .����'��('������(�� �

���� .����'��('����������(����23�2���� �������������������#��

���� .����'��('������(��������

��4�������'(������� .����'��('������(��

��

�.

Figure 9: The Moodle upload manager

������������� ��� �������������� � �������������������������������������������������� ���!���"��������!�����������!�������#���������������$% !���"����&!"'()*�+�����,+����"�����,��!�������&!"'()*�+�����,+������,�!�������#&-�������-��$�"��������"���$!���"����%% �$����"��������"���$!���"����.!�������#�!�������%% ������-'���������������������#-�/����������-'���������0'����-�//���� ������-�����-�

����1

Figure 10: The uploadservice.php

For example the upload manager generatesHTML directly to the user when it encounterserrors, either in the format or content of thefiles, or in file management.

The method move uploaded file( string $file-name,string$directory) of uploadlib.php is usedto check the validity of the file (file type, ab-

sence of malware, etc.) which is uploaded viaan HTML form. If it is valid then it is movedto the destination directory (Figure 9).

3.2.2 Moodle’s File Uploading Refac-toring and New Service

The file management routines from the libraryare collected into a single class and convertedto a local service. Figure 10 shows the movefilemethod of the class. The upload manager classis then converted to call the SOA functions.The collection of the file management code intoa service separates the management of the filesfrom the generation of the error messages.

4 Previous Work

Service-oriented architecture (SOA) migrationis an architectural migration from any non-SOA system to a system that follows theservice-oriented architecture principles, in or-der to achieve a new maintainable service-oriented architecture implementation of thesystem. The major benefits of adopting serviceoriented architecture as a design framework isthe ability to realize rapid and low-cost systemdevelopment, to improve overall system qual-ity, and to better enable integration with othersystems.

Several methods in the literature studied theproblem of migrating traditional legacy systemto web services. We discuss some of them here,and for a comprehensive discussion of other ap-proaches, interested user can refer to our previ-ous work [2], in which we present a comparativestudy of modernization approaches for leverag-ing /exporting legacy systems to SOA.

Aversano et al. [4] present a case studyin which a COBOL system is migrated toweb-based service oriented architecture. Thelegacy system is divided into user interface andserver (application logic and database). Theuser interface has been migrated into a webbrowser shell using Microsoft Active ServerPages and the VBScript scripting language,and the MORPH approach has been used tomap the components of the existing interfaceinto the new web based interface. While theserver has been wrapped and integrated intothe new web-enabled system with dynamicload libraries written in Microfocus ObjectCOBOL, loaded into Microsoft Internet Infor-mation Server (IIS), and accessed by the ASPpages.

H. M. Sneed and S. H. Sneed [21] discuss atool-supported method, where the legacy codeis a COBOL program wrapped behind an XMLshell allowing individual functions within theprograms to be offered as web services to anyexternal user.

Smith [20] and Lewis et al. [10, 9], dis-cuss a migration technique called the Service-Oriented Migration and Reuse Technique(SMART). It is a technique that helps or-ganizations analyze legacy systems to decidewhether their functionality can be reasonablyexposed as services in a service-oriented archi-tecture.

Little work has been done to migrate webapplications to SOA. A sample of such effortsis the work done by Tatsubori and Takash [22].The authors present a framework named H2W,which can be used for constructing web servicewrappers for existing, multi-paged web appli-cations. H2Ws contribution is mainly in itsservice extraction step. The authors proposea page-transition-based decomposition modeland a page access abstraction model with con-text propagation. With the proposed decompo-sition and abstraction, developers can flexiblycompose a web Service wrapper of their intentby describing a simple workflow program. In[8] the paper discusses how web services can beused to leverage web applications in a similarway in general.

Vijaya and Rajan [17] focus on exploringweb services features, how they could effec-tively shape the e-learning process, and ad-vantages and compromises for the migrationfrom traditional distributed application devel-opment to web services enabling technology.Mainly they explore the benefits of convertingto web services, without introducing any spe-cific approach to conversion. Most of the workdone in this area is similarly general, where thefocus is on discussing the benefits of using webservices to leverage web application, withoutintroducing a full framework for addressing theproblem.

The work done by Ajlan and Zedan [1] is tointroduce web services to Moodle. The focus ofthe paper is to expose the assignment moduleof Moodle as web services. UML diagram (col-laboration diagram) is used to analyze it andto capture the necessary information needed to

expose the assignment module as web services.Furthermore, NuSOAP is used to create andconsume web services. The goal of our paperis to introduce an approach for moving legacyweb application to web services in a service-oriented architecture.

5 Conclusion and FutureWork

The proposed approach represents a new ap-proach to the problem of migrating legacy sys-tems to service-oriented architecture. It is oneof the first approaches to explore the area ofmoving a monolithic web application to SOA,and the first with a complete approach and sig-nificant levels of automation. We presenteda simplified version of the Moodle login as aservice, which we were able to successfully au-thenticate users into Moodle by checking theusername and password provided against theMoodle database.

As future work, we will expose the file up-loading functionality via SOAP protocol . Alsowe will choose more functionality to be exposedas services within Moodle to achieve the userinterface plasticity and load balancing goals re-spectively. We analyzed both functionalities inorder to identify the potential service withineach function, which is done manually at thisstage. We are also going to automate the ser-vice identification process by applying TXL.

In addition, as a demonstration of the flex-ibility of the results of the approach, we willcombine the services extracted from two dif-ferent web applications. This will demon-strate a new hybrid system that uses mixed ex-tracted services from the applications to offernew higher-level business functionalities thatuse the services of both.

Acknowledgements

This work is supported in part by the NaturalSciences and Engineering Research Council ofCanada and by an IBM Center for AdvancedStudies Faculty Fellowship.

About the Authors

Asil Almonaies is a PhD candidate in theSchool of Computing at Queen’s Universityworking under the supervision of Profs. JamesCordy and Thomas Dean. She received herM.Sc. and B.Sc in Computer Engineering fromKuwait University. Her research interests arein the area of software engineering, focusing onweb applications, web services, service-orientedarchitecture, and legacy systems migration.

Manar Alalfi is a postdoctoral fellow in theSoftware Technology Laboratory of the Schoolof Computing at Queens University, workingwith Prof. James Cordy. Dr. Alafi receivedher Ph.D. from Queens University in 2010. Hermajor specialization is software engineering, fo-cusing on security analysis in web applications,studying types of web application vulnerabil-ities and proposing and developing techniquesto harden software systems to survive maliciousattacks. Her other research interests includeservice oriented architecture and model drivenengineering for automotive systems.

James Cordy is Professor and past Directorof the School of Computing at Queens Univer-sity. From 1995-2000 he was vice-president andchief research scientist at Legasys Corporation,a software technology company specializing inlegacy software system analysis and renovation.As leader of the TXL source transformationproject he is the author of more than 130 ref-ereed contributions in programming languages,software engineering and artificial intelligence.Dr. Cordy is an ACM Distinguished Scientist,a senior member of the IEEE, and an IBM CASvisiting scientist and faculty fellow.

Thomas Dean is an Associate Professor inthe Department of Electrical and ComputerEngineering at Queens University and an Ad-junct Associate Professor at the Royal MilitaryCollege in Kingston. His background includesresearch in air traffic control systems, languageformalization, and five and a half years as aSr. Research Scientist at Legasys Corporationwhere he worked on advanced software trans-formation and evolution techniques in an in-dustrial setting. His current research interestsare software transformation, web site evolutionand network application security.

References

[1] A. Ajlan and H. Zedan. E-learning (MOO-DLE) Based on Service Oriented Architec-ture. In the EADTU’s 20th AnniversaryConference, Lisbon, Portugal, 8-9 Novem-ber, Lisbon-Portuga, pages 62–700, 2007.

[2] A. Almonaies, J.R. Cordy and T.R. Dean.Legacy System Evolution towards Service-Oriented Architecture. In InternationalWorkshop on SOA Migration and Evolu-tion, pages 53–62, 2010.

[3] Mehdi Achour, Friedhelm Betz, AntonyDovgal, Nuno Loopes, Hannes Magnus-son, Georg Richter, Damien Seguy, andJakub Vrana. PHP Manual. http://www.php.net/manual/en/index.php, last ac-cessed Aug 2011.

[4] L. Aversano, G. Canfora, A. Cimitile, andA. De Lucia. Migrating legacy systems tothe web: an experience report. In Pro-ceedings of Fifth European Conference onSoftware Maintenance and Reengineering,pages 148–157, 2001.

[5] Joelle Coutaz. User interface plasticity:Model driven engineering to the limit! In2nd ACM SIGCHI Symposium on En-gineering Interactive Computing Systems,pages 1–8, 2010.

[6] Dieter Fensel and Christoph Bussler. TheWeb Service Modeling Framework WSMF.Electronic Commerce Research and Appli-cations, 1:113–137, 2002.

[7] G. Van Rossum. Python programminglanguage. http://www.python.org/, lastaccessed Aug 2011.

[8] K. Dezhgosha and S. Angara. Web ser-vices for designing small-scale Web appli-cations. In the 2005 IEEE InternationalConference on Electro Information Tech-nology, 4 pages, 2005.

[9] G. Lewis, E. Morris, L OBrien, D. Smith,and L. Wrage. Smart: The service-oriented migration and reuse technique.In Proceedings of the 13th IEEE Interna-tional Workshop on Software Technology

and Engineering Practice, pages 222–229,2005.

[10] G. Lewis, E. Morris, and D. Smith. An-alyzing the reuse potential of migratinglegacy components to a service-orientedarchitecture. In In Proceedings of theConference on Software Maintenance andReengineering, pages 15–23, 2006.

[11] Martin Fowler. Refactoring: improving thedesign of existing code. Addison-WesleyLongman Publishing Co., Inc., Boston,MA, USA, 1999.

[12] Caroline Maynard, Graham Char-ters, Matthew Peters, and SimonLaws. SCA/SDO for PHP. http://pecl.php.net/package/SCA_SDO, lastaccessed Aug 2011.

[13] Moodle Trust. Moodle. http://Moodle.org, last accessed October 2010.

[14] OASIS. UDDI Version 2.03 DataStructure Reference. http://www.uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm, lastaccessed September 2010.

[15] Open SOA Collaboration. SOA PHPHomepage. ihttp://www.osoa.org/display/PHP/SCA+with+PHP, last ac-cessed Aug 2011.

[16] Php.net. PHP 5 ChangeLog. http://www.php.net/ChangeLog-5.php, last ac-cessed Aug 2011.

[17] Amala Vijaya Selvi Rajan and Jim Otieno.Leveraging traditional distributed applica-tions to web services for e-learning appli-cations. In 15th International Workshopon Database and Expert Systems Applica-tions, pages 430–435, 2004.

[18] Scott Nichol. Introduction to Nu-SOAP. http://www.scottnichol.com/nusoapintro.htm, last accessed Septem-ber 2010.

[19] Simon Laws. SCA with PHP.http://www.osoa.org/display/PHP/SCA+with+PHP, last accessed September2010.

[20] D. Smith. Migration of legacy assetsto service-oriented architecture environ-ments. In Proceedings of the 29th Interna-tional Conference on Software Engineer-ing, pages 174–175, 2007.

[21] H. M. Sneed and S. H. Sneed. Creatingweb services from legacy host programs.In Proceedings of the Fifth IEEE Interna-tional Workshop on Web Site Evolution,pages 59–65, 2003.

[22] Michiaki Tatsubori and Kenichi Takashi.Decomposition and abstraction of web ap-plications for web service extraction andcomposition. In IEEE International Con-ference on Web Services, pages 859–868,2006.

[23] TechGuruLive. What is a hard-ware load balancer? http://techgurulive.com/2011/01/17/what-is-a-hardware-load-balancer/,last accessed October 2010.

[24] The PHP Group. Package Information:SOAP. http://pear.php.net/package/SOAP/redirected, last accessed Septem-ber 2010.

[25] W3C. Simple Object Access Protocol(SOAP) Version 1.2. http://www.w3.org/TR/soap12, last accessed September2010.

[26] W3C. Web Services Description Language(WSDL) Version 1.1. http://www.w3.org/TR/wsdl11, last accessed September2010.