Information Systems Frontiers 5:2, 149–160, 2003C© 2003 Kluwer Academic Publishers. Manufactured in The Netherlands.

The Migration of Multi-tier E-commerce Applicationsto an Enterprise Java Environment

Terence C. LauCentre for Advanced Studies, IBM Canada LaboratoryE-mail: Lautc@ca.ibm.com

Jianguo LuDepartment of Computer Science, University of WindsorE-mail: jlu@cs.uwindsor.ca

John MylopoulosDepartment of Computer Science, University of TorontoE-mail: jm@cs.toronto.edu

Kostas KontogiannisDepartment of Electrical and Computer Engineering,University of WaterlooE-mail: kostas@swen.uwaterloo.ca

Abstract. As technology evolves, many organizations face theproblem of migrating legacy applications from one technologybase to another. We report on a case study involving the mi-gration of legacy code into the IBM©R WebSphere©R CommerceSuite product. Specifically, we focus on the problem of migratingapplications that use traditional database access techniques toapplications using the Enterprise JavaBean (EJB) programmingmodel. Our results include a practical methodology thatfacilitates such migration, as well as a tool that supports thismethodology. The tool has been released on IBM’s alphaWorkssite.

Key Words. e-commerce, migration, database reengineering, En-terprise JavaBean, SQL, Net.Data, JSP, relational-object map-ping

1. Introduction

Multi-tier applications typically consist of a middletier of web servers, web browsers at the front end,and database systems in the back end. Such applica-tions have existed for years and many of them needto be migrated to new technology platforms. This pa-per describes our experience in migrating the IBMe-commerce framework, a multi-tier application, to anew framework that is based on Enterprise JavaBean

technology. In particular, we focus on the migration ofthe presentation tier of the system using the relation-ships established in other tiers of the systems. Our re-sults include a practical methodology to support clientmigration. In addition, we describe our experience inbuilding a Net.Data-to-JSP (Java Server Page) HelperTool that is currently being used by developers in mi-grating e-commerce websites developed using IBMWebSphere Commerce Suite, from earlier versions tomore recent ones. Unlike most research on software mi-gration that focuses on monolithic systems, our workaddresses migration problems where both the sourceand target systems involve multi-tier architectures thatuse different programming languages.

The rest of the paper is organized as follows. Wefirst introduce in Section 2 background informationconcerning the source and target platforms for our mi-gration task. Section 3 describes the migration processfor the IBM Websphere Commerce Suite product. InSection 4 we present an implemented migration tool,while Section 5 introduces a generic migration modelfrom any legacy system to an EJB-based architecture.Section 6 compares our work with related research, andSection 7 offers conclusions and directions for furtherresearch.

149

150 Lau et al.

2. Background

2.1. Enterprise JavaBeanEJB (Enterprise JavaBean) is a distributed compo-nent framework that provides transaction, security andpersistence services in a distributed multi-tier envi-ronment (IBM, 2001; iPlanet Application Server Mi-gration Guide, 2000). The EJB framework separatesbusiness logic from low-level details, so that develop-ers can concentrate on a business solution. With thegrowing popularity of the EJB framework, more andmore legacy systems (web-based or otherwise) are be-ing transformed into an EJB architecture. Typically, alegacy system includes a large number of SQL queries.On the other hand, in an EJB-based architecture thoseSQL queries are not used directly. Instead, the popularmodel-view-control design pattern is adopted, wherequeries are wrapped inside EJBs so data are accessedthrough EJBs instead of SQL statements. A typicalEJB-based architecture is shown in Fig. 1.

At the center of the architecture is the EJB containerthat manages a set of enterprise beans. The beans accessbackend systems, typically relational databases. Theweb container typically uses JSP to access the EJB,transforms the JSP to HTML, and serves the HTMLto the browser. EJB client applications other than JSP,such as Java applets or other systems, can also accessthe enterprise beans.

The enterprise beans in the middle tier function aswrappers over various systems, most notably relationaldatabase systems. There are two kinds of enterprisebeans: entity and session beans. Roughly speaking, ses-sion beans represent activities, while entity beans rep-resent entities of the application. An entity bean is a

Fig. 1. EJB architecture.

persistent object stored in a storage system such as adatabase system. In a simple scenario, one bean corre-sponds to a row in a table. The selection of certain rowsof the table corresponds to the selection of a group ofbeans satisfying a given condition. Beans are selectedby using a finder method that contains an embeddedSQL statement. We are interested in entity beans.

By using EJBs, web designers no longer need tolearn the details of database structure. In addition,changes in the backend database are shielded by thebeans, making the maintenance of Java Server Pageseasier.

2.2. Java Server PagesJava Server Pages (JSPs) enable Enterprise Java appli-cations to create dynamic content for browser-basedclients. JSPs constitute a presentation-centric methodfor developing servlets, i.e., Java programs that are ex-ecuted by a web server and have their output directedto a client browser. JSPs support a reusable compo-nent model based on JavaBean components and customactions.

Using JavaBean components web page designerscan focus on presentation while application developerscan develop specific components to process and returndata to be used in a page. JavaBean components canalso be used elsewhere in the application, as they arereusable and portable.

2.3. Net.Commerce and WebSphereCommerce SuiteIBM WebSphere Commerce Suite and its earlier ver-sions, Net.Commerce (Lau et al., http://alphaworks.ibm.com/tech/netdatatojsp) are platforms for building

Migration of Multi-tier E-commerce Applications to Enterprise Java Environment 151

e-commerce applications. WebSphere CommerceSuite supports functionalities ranging from prod-uct catalogue browsing and payment processing, toproduct promotion and auction. Starting in 1995,Net.Commerce went through five major revisions, wasrenamed WebSphere Commerce Suite, and more re-cently WebSphere Commerce. In November 2000, theWebSphere Commerce Suite offered a number of en-hancements over Net.Commerce, affecting its databaseschema as well as its programming model. The en-hancements emphasize clear programming structureand conformance with the EJB model. Since that time,existing WCS customers who want to transition tonewer versions of WebSphere Commerce Suite needthe help of tools as well as methodological guidanceto migrate their legacy e-commerce applications to thetarget environment.

2.3.1. The IBM Net.Commerce and WebSphereCommerce Suite Version 4 programming model.The early versions of Net.Commerce and WebSphereCommerce Suite are based on a programming modelbuilt on C++ and use commands, tasks and overrid-able functions. Commands are C++ components ser-vicing major functions, such as placing an order. Tasksrepresent sub-units of work within a command, such aschecking inventory or calculating the price for an order.Overridable functions are the C++ components thatactually perform the work of the tasks. Customers usu-ally introduce their own business logic by replacing theoverridable functions provided by WebSphere Com-merce Suite with their own. When results and responsesare presented to users, Net.Data©R macros are invokedto access the backend database, retrieve the appropriateinformation, and then present it on Web pages.

2.3.2. The IBM WebSphere Commerce SuiteVersion 5.1 programming model. Table 1 highlightsthe differences between the two e-commerce systems.For the presentation language, the old system uses

Table 1. WebSphere Commerce Suite (WCS) programming models:Now and before

Before (WCS V4.1and prior) Now (WCS V5.1)

Presentation language Net.Data JSPBusiness logic SQL EJBProgramming language C++ JavaProgramming model No clear MVC MVC

Net.Data, while the new one uses Java Server Pages(JSP), a widely accepted standard for dynamic webpages. For the business logic, the old system uses SQL,in many cases directly embedded in C++ programsand Net.Data scripts, while the new system uses EJB.For the programming language, C++ is used in the oldsystem, and Java in the new. As for the programmingmodel, the old system intertwined many things in thesame place and does not have a clear separation be-tween the view, model, and control of the system. Thenew system adopts the popular Model-View-Control(MVC) design pattern by using EJB.

3. Migration Process

3.1. The migration tasksThe transition of Net.Commerce and earlier versions ofWebSphere Commerce Suite to WebSphere CommerceSuite Version 5.1 consists of three major processes asillustrated in Fig. 2.

� Migrating software stacks: The software stacks in-clude the system and application software packagedwith WebSphere Commerce Suite Version 5.1 thatprovide basic system functions and third-party ap-plication functions. They also include the operatingsystem, the database system, the web server, the se-curity system and the like.

� Migrating WebSphere Commerce Suite infrastruc-ture: The WebSphere Commerce Suite infrastructureconsists of the basic components shipped with theproduct. Customers build their specific solutions onthis infrastructure. The infrastructure includes toolsfor building a Web site based on WebSphere Com-merce Suite, runtime infrastructure, the WebSphereCommerce Suite database schema, the WebSphereCommerce Suite class library and object entities.

� Migrating customer assets: Customer assets includethose accumulated, populated, customized, or ex-tended by customers in their commerce sites. Theseassets may be database data, pages designed specif-ically for the Web site, database schema extensions,and new or customized business logic in commandsand overridable functions.

The rest of the paper focuses on the migration of cus-tomer assets. In particular, the transition to WebSphereCommerce Suite Version 5.1 involves the conversionof the following major assets:

152 Lau et al.

Fig. 2. Migration processes.

� Data is migrated to the WebSphere Commerce SuiteVersion 5.1 database format and schema, and ac-cessed using the new object models of EJB and databeans.

� Net.Data macros are replaced by JSP. The SQL inNet.Data macros are replaced with JSP calls to Web-Sphere Commerce Suite Version 5.1 data or businessEJB. Business logic within a Net.Data macro shouldbe moved into a command to isolate the view fromthe model.

� Business logic is converted from C++ to Java com-mands. Overridable functions are replaced by EJBtask commands. Major C++ commands are replacedby EJB controller commands.

In the following we discuss the migration of Net.Datamacros to JSP.

3.2. The migration processOur process consists of two main phases: i.e., reverseengineering and forward engineering.

In the reverse engineering process the followingmappings are established:

(1) Schema-to-Schema Mapping (SSM): Relationaldatabase schema, mapping data from the sourceto the target system.

(2) Command to Command Mapping (CCM): We de-fine a command as a component of the source sys-tem that accomplishes a particular task and has acomparable counterpart in the target system, suchas addUser command.

(3) Entity to Relation Mapping (ERM): The relation-ship between the target system EJB Object (entitybeans) and database relation information.

(4) Component to Entity Mapping (CEM): This is themapping between the target system JavaBean com-ponents and Enterprise bean relations.

Taking the result of reverse engineering as input,the forward engineering process proceeds as shown inFig. 3.

Fig. 4 depicts in detail the various data sources andprocesses involved in our migration system. We nowexplain the purpose and relationships between variouselements of the system.

Migration of Multi-tier E-commerce Applications to Enterprise Java Environment 153

Fig. 3. Forward engineering process.

Fig. 4. System diagram.

154 Lau et al.

Prior to the first use of the tool the target appli-cation source code is analysed. The Object-DB anal-yser (Item C) extracts information from the target ap-plication to determine relations between Entity Beansand the underlying database. This is accomplished byparsing WCS source code from the target applicationand needs only to be run once provided the underlyingsource remains static. In general, there is an Entity Beanfor each table in the database that provides read/writeaccess to data elements and performs selection opera-tions on the data. We call this relationship the Primaryrelationship between the table and the associated En-tity Bean. A secondary relationship exists if the EntityBean uses data from other tables in any selection meth-ods. All of the finder methods of the entity beans arealso recorded.

We then examine the client JavaBean Componentsto determine their usage of entity beans (Item D)and any containment relationships that exist betweenthe JavaBean Components. This process is also runonce and needs only to be re-run when the underlyingJavaBean code changes.

During initialisation of the migration tool all rel-evant migration information is read into the system.The Database Schema Mapper (Item A) process ac-cepts as input the source-to-target database schemamapping relationship as specified in a configurationfile. This relationship states what target database ta-ble/column(s) map to what target database/column.The process generates an internal structure represent-ing this mapping relationship. The relationship be-tween the source database tables and target databasetables can be 1-to-1, 1-to-many, or many-to-1.

The Source-to-Target Relationship Synthesizer(Item E) integrates migration information so that givena table from the source application, it is possible todetermine all possible JavaBean components from thetarget application that could have access to similar datain the target system.

After initialisation, the tool accepts as input a sourcefile and extracts all the SQL statements contained inthe file. The SQL Analyser (Item F) extracts the col-umn(s) and tables used in a particular SQL statement.The following example illustrates the recommendationprocess.

Given the following SQL statement:

SELECT A, B, G, HFROM X, YWHERE X.A = Y.G

The SQL Translator translates the query into

SELECT A', B', G', H'

FROM X', Y', Z'

WHERE X'.A' = Y'.G'

Suppose that from the database schema mappingSSM we have mappings such as:

(source table) X -> X' (target tables)(source table) Y -> Y', Z' (target tables)

Now we compare the translated query with thequeries inside entity beans. Using ERM as below

X', Y', Z' (Target system table)-> X_EntityBean,

Y_EntityBean,Z_EntityBean,

we can deduce that X_EntityBean, Y_EntityBean,and Z EntityBean are relevant.

We then determine the set of JavaBean componentsthat use these entity beans based on the followingCEM:

X_EntityBean, Y_EntityBean, Z_EntityBean-> A_JavaBean,

B_JavaBean

The number of entity beans that a particularJavaBean component uses is treated as criterion to rankthe recommendations. The logic behind this rankingis that the more data coverage a component has, thebetter the chances that it will have a combination ofmethods that will return data similar to the data re-trieved from the SQL statement.

The set of ranked JavaBean components is passedon to the Recommendation Generator (Item H) thatproduces the output to the user in the form of a reportor to a GUI.

4. Net.Data-to-JSP Migration Helper Tool

We have developed a tool to aid the migrationof Net.Data macro files used in client e-commerceprojects to JSPs. The tool was developed following thearchitecture and processing model outlined in the pre-vious section.

The process of converting a commerce site usingNet.Data macros to a site using JSP templates is byno means an automated task. There are many designdecisions and code conversions to be carried out by the

Migration of Multi-tier E-commerce Applications to Enterprise Java Environment 155

developers responsible for the migration (particularlywhen developing business logic components). Thus,the Net.Data Migration Helper Tool is a reference toolthat helps the development team plan their Net.Datamigration and gives them guidance on where to begin.The tool can be used at two points in the migrationprocess:

(1) When the migration planners are trying to deter-mine how much work needs to be done on eachfile in order to create a project schedule for migra-tion. The tool gives a high level view of how manyfunctions each Net.Data file has, and how manystandard and customised tables are involved.

(2) When the developer is working on creating a par-ticular JSP template to replace a Net.Data file. Thetool acts as a reference for the mapping betweenNet.Commerce Version 4 and WebSphere Com-merce Suite Version 5 tables, for the functions inthe file and recommended beans that should be usedto perform the same function in a JSP.

4.1. Net.Data scripting languageIBM’s Net.Data product enables developers to cre-ate dynamic web pages using data from relationaldatabases and other back-end systems. Net.Data is ascript language that enables a developer to specify thelayout of Web pages, calls functions that are defined bymacro, and defines variables and functions.

Net.Data macros contain two parts: the declarationpart and the presentation part. Fig. 5 illustrates thestructure of a Net.Data macro.

Fig. 5. Net.Data language.

The function block is what we are more inter-ested in. A common function block has the followinglayout:

%function (dtw_odbc) name () {SELECT distinct safname, samname,

salname, shrfnbr, satitleFROM shopper, shaddrWHERE sashnbr = shrfnbr and

shlogid = '$ (SESSION_ID)' andsanick = '$(SESSION_ID)'

%REPORT{%ROW{<center>HTML formatting information for

rows returned from the SELECT statement</center>

%}%}

%}

The SQL statements that we analyse are generallyfound in the function blocks of a macro.

4.2. Objective of the tool and rationaleBecause of the significant differences betweenNet.Data and JSP, and the fact that customers mightwant to make functional changes during the migration,the objective of the tool is not to perform complete au-tomatic conversion of one Net.Data macro to one JSP.Rather, it is a helper tool. Although the conversion pro-cess requires human involvement, the tool significantlyreduces the total effort required of developers. A goodlist of recommendation can save a significant amountof effort and time during the first part of the conversionprocess.

The rationale for this approach is two-fold:First, from an implementation feasibility point of

view, automatically translating from Net.Data to Javais extremely difficult. Net.Data macros and JSPs arevery different in form and implementation. It is noteasy to predict the mapping from an SQL statement ina Net.Data macro to a particular data bean. Allowingthe users to participate in the mapping makes the toolmuch more useful.

Secondly, because of the many enhancements inWebSphere Commerce Suite Version 5 that customerswant to take advantage of, they will very likelyprefer not to perform an automated translation ofthe Net.Data. The database schema includes exten-sive enhancements from Net.Commerce Version 4 to

156 Lau et al.

WebSphere Commerce Suite Version 5, as well as im-proved function and design of some major components.It is neither practical nor useful to capture and fix thisinformation in one shot, because customers are likelyto customize the product and need to modify the infor-mation themselves. A more practical approach is to letthe helper tool provide a more general recommenda-tion initially, and allow users to add their own wisdomto build up the tool’s knowledge.

This approach also paves the way for a potentiallypowerful function, namely a learning capability. Ascustomers use the tool and indicate their choices, the in-formation is captured so that more specific recommen-dations can be made in future uses. Customers usuallyhave collections of similar Net.Data macros. After alead developer trains the tool for one macro, it can thengive out very useful recommendations for the rest ofthe collection to other developers. Similarly, this toolcan be used to capture the experience of one customersituation so that it can be re-used to deal with similarsituations. The learning capability is not included inthe first release of the tool.

4.3. Tool featuresThe features of the tool are of two categories. (a) In thereverse engineering process it extricates the relation-ships between the data beans, access beans, and entitybeans. Also, it establishes the connection between thedatabase and the enterprise beans. (b) In the forwardengineering process, it performs SQL translation andrecommends to the user Data beans are the JavaBeancomponents (data beans) to use. In order to fully un-derstand how to use the particular data bean and to con-firm that it is the right object for the task the tool pro-vides a link to the JavaDoc documentation of the databean.

4.3.1. Reverse engineering features

Schema mapper. This feature helps the user to cap-ture custom database schema mapping between theNet.Commerce Version 4 and WebSphere CommerceSuite Version 5 systems. Users first prepare an XML filespecifying the database relationship between the twoversions of WebSphere Commerce Suite. This XMLfile is placed in the configuration directory of the tooland used later on for database and bean analysis, map-ping, and recommendation.

Source code crawler. The source code crawler col-lects the data bean and access bean information from

the EJB source code in the system and generates anXML file containing such information for subsequentrecommendation.

SQL collector and extractor. The SQL collectorparses Net.Data macro files provided by the user, ex-tracts the SQL statements in an interactive manner, andgenerates an XML file containing the SQL informationfor subsequent analysis and processing. The SQL ex-tractor has a similar function to the SQL collector, butworks in a batch mode.

4.3.2. Forward engineering features

Bean recommendation. Fig. 6 is a screen-shot of thebase recommendation tool.

The left pane is a full editor into which the Net.Datamacro loads. The tool enables the user to cycle througheach of the SQL statements found in the macro. Theright pane shows the table and column mapping infor-mation and the recommended set of data beans of theactive SQL statement.

The tool can produce a report for the loadedNet.Data macro that lists all the SQL statements inthe macro, the function it came from, and the rec-ommended data beans and their related access beans.When the database schema of WebSphere CommerceSuite is modified by the customer, the tool can also dealwith the customised tables used in the SQL statements.

As an example, when a Net.Data page is loaded intothe tool, the macro is parsed to extract all the SQLstatements. After that, the SQL statement is parsed andrelevant information is extracted, such as columns andtables that are used. A typical sequence of activities bya user is as follows, with reference to panes [A] to [F]in Fig. 6:

1. Select the SQL statement in the Net.Data macro asdepicted in the top-left pane [A] of Fig. 6.

2. Note the Version 4 to Version 5 table correspondencein pane [B] of same figure.

3. Note the Version 4 to Version 5 column correspon-dence in pane [C].

4. Open the recommendation pane and note the relateddata beans in pane [D].

5. Go through the list selecting data beans of interestin [D], and note the detailed information of relateddata beans in pane [E].

6. Using the information in pane [F], compare againstgetter methods in pane [E] to narrow down the databean selection.

Migration of Multi-tier E-commerce Applications to Enterprise Java Environment 157

Fig. 6. Tool window view.

After going through the above steps, the possible out-put JSP code corresponding to the name() function inNet.Data file in the database schema mapper, as de-duced from the JavaBeans Hierarchy and informationanalyser and the source-target relationship synthesizer,might be:

......<jsp:useBean id = "addressbook"class = "com.ibm.commerce.user.beans.AddressBookDataBean" scope = "page"/><%com.ibm.commerce.beans.DataBeanManager.activate (addressbook, request); %>

</jsp:useBean><!-- HTML content -->......<center><h1> Shopping Cart for<% = addressbook.getTitle() %><% = addressbook.getFirstName() %>

<% = addressbook.getMiddleName() %><% = addressbook.getLastName() %></h1>......

SQL translator. The SQL translator parses SQL state-ments from a Net.Commerce Version 4 system, mapsout the corresponding WebSphere Commerce SuiteVersion 5 database information based on the Version 4to Version 5 database mapping information in the tool,and constructs corresponding WebSphere CommerceSuite Version 5 SQL statements.

4.4. Tool deploymentThis tool was first released in June 2001 on IBM’salphaWorks©R Web site (Lau et al., http://alphaworks.ibm.com/tech/netdatatojsp). The primary target audi-ence at that time was members of the WebSphere Com-merce Suite Service Teams embarking on migrationprojects, for project planning and code development.

158 Lau et al.

The database schema mapping is from WebSphereCommerce Suite Version 4.1 to the new Version 5.1schema.

5. A Generic EJB Migration Model

Based on our experiment for the migration of Web-sphere Commerce Suite, we identified a generic mi-gration model and the research challenges in movingfrom the multi-tier applications to EJB-based architec-tures other than IBM products. When reengineeringsuch applications, we will face two challenges that aredepicted in Fig. 7:

� When the enterprise beans are already provided, howto translate the queries embedded in the legacy codeto the equivalent EJB client code?

� When the enterprise beans are not provided, howcan we produce the beans, especially the finders andthe queries inside finders consistently with existinglegacy queries?

We propose to use SQL-EJB mediator to solve the firstproblem, and use view selection to solve the second.In general these two tasks are not performed indepen-dently. The reengineering is an iterative process with in-tervention from EJB designers. In a typical scenario theEJB designer defines some entity beans first, then usesthe SQL-EJB mediator to locate legacy SQL queriesthat cannot be reproduced using the enterprise beans.Those queries are then used as the basis for EJB gen-eration. By using the EJB generator, enterprise beans

Fig. 7. EJB migration problems.

and the finder methods are recommended for the de-signer to choose. The selected beans are added into theexisting system and we can iterate this process, run theSQL-EJB mediator once again.

As for the EJB generation from a set of queriesand their schema, there are two approaches. One isthe black-box reengineering. In this approach, the SQLstatements are not analysed. Instead, they are directlycopied into the methods of enterprise beans. This kindof reengineering requires generating some scaffold-ing code for the method so that it can access thedatabase. In general, this approach will use sessionbeans.

On the other hand, the white-box reengineering ap-proach is much more complicated. This will requirethe generation of entity beans and the rewriting ofthe queries into object interface. Several queries maybe combined into one method in one entity bean, orone query may be split into several methods in differ-ent beans, or as illustrated in Fig. 8. This is a goodlong-term solution offering a clean object-orientedarchitecture.

Currently the EJB client code in JSP is not automat-ically generated. We are using query-rewriting tech-niques to translate the SQLs to fragments of EJB clientcode. Furthermore, in a more general situation whenEJB architecture is not available yet, the EJB architec-ture and the finder methods as well as the SQLs insidethe finder methos will be generated.

6. Related Work

There are several tools and methodologies for migrat-ing EJB applications from one platform to another(iPlanet Application Server Migration Guide, 2000;Tech Metrix Research, 2000). These tools generally tar-get migration tasks where the source system is alreadyusing EJB technologies and are therefore addressing asimpler problem than that addressed here. Moreover,our work takes into account specific requirements dic-tated by the WebSphere Commerce Suite.

In addition, there are tools for mapping database ap-plications to EJB architecture (Takagiwa et al., 2001).However, these focus on the problem of mappingschemata to Enterprise JavaBeans, instead of migratingSQL code. Besides, the mappings supported by thesetools are typically either straightforward or have to beperformed manually. Such tools are most effective forthe problem of object-relational mappings.

Migration of Multi-tier E-commerce Applications to Enterprise Java Environment 159

Fig. 8. White-box reengineering.

In database reverse engineering and schema map-ping (Jahnke, Schafer, and Zundorf, 1996), a popularapproach is to map a relational schema to an objectschema directly. This paper addresses three additionalaspects. First, we map the relational schema to anotherrelational schema. Second, we extract and enrich theschema mapping from the hand-coded schema map-ping data provided by IBM that are recoded in XSLformat. Finally, we use the schema mapping to trans-late legacy SQL queries.

7. Conclusions and Future Work

We have presented a practical methodology fort the mi-gration of multi-tier applications that access databasesat the backend to ones using the EJB programmingmodel. The methodology is supported by a tool devel-oped for the IBM WebSphere Commerce Suite. Thetool has been implemented and is being used by devel-opers working on migration tasks. This work has alsoidentified a number of areas that we believe are fruitfulfor further investigation:

Firstly, the recommendation ranking technique israther simple in the current release of the tool and webelieve that it can be improved. We are investigatinghow the following changes to the Recommendation En-gine will improve the quality of the recommendations:

(1) Use the column usage information as a basis fordoing data coverage analysis.

(2) Analyse the containment relationships that hold be-tween data beans and the inheritance relationshipsbetween data and access beans, to see if these rela-

tionships relate to actual usage of the beans; if so,modify the ranking scheme to account for this.

(3) Retain user experience from previous migration ef-forts to aid developers encountering similar tasksin different migration projects.

Secondly, the tool can help programmers interactivelyproduce the JSP code, and especially the EJB clientcode in JSP. We are currently working on the followingtasks:� The generation of EJB client code using query rewrit-

ing technology based on existing EJB framework(Lu, 2002);

� The generation of entity beans and session beansfrom the legacy database systems when they do notexist (Lu, 2002);

� The translation from Net.Data to JSP code, especiallythe HTML part.

Acknowledgments

We would like to thank the anonymous reviewers fortheir detailed comments. In developing the migrationprocess and the Helper Tool, we had valuable help andinput from Erik Hedges, Emily Xing, members of the E-Commerce Development Team and E-Commerce En-gagement Team within the IBM Canada Laboratory.

The University of Toronto and Waterloo teams aregrateful to the Canadian Consortium for Software Engi-neering Research (CSER), the IRIS Network of Centresof Excellence, and the Natural Sciences and Engineer-ing Research Council of Canada for financial supportof this research.

160 Lau et al.

IBM, WebSphere, Net.Commerce, Net.Data, andalphaWorks are trademarks of International BusinessMachines Corporation in the United States, other coun-tries, or both. Java and all Java-based trademarksand logos are trademarks or registered trademarks ofSun Microsystems, Inc. in the United States, othercountries, or both. Other company, product, and ser-vice names may be trademarks or service marks ofothers.

This paper represents the views of the authors ratherthan IBM.

References

Behm A, Geppert A, Dittrich KR. On the migration of relationalschemas and data to object-oriented database systems. In: Pro-ceedings of the 5th International Conference on Re-Technologiesfor Information Systems, Austria, 1997.

Bergamaschi S, Garuti, A, Sartori C, Venuta A. The object wrapper:An object oriented interface for relational databases. Euromicro1997.

Brown K. Handling N-ary relationships in VisualAge for Java.www.ibm.com/vadd, Aug. 2000.

IBM, IBM Net.Data Reference. Version 7, http://www4.ibm.com/software/data/net.data/, June 2001.

IBM, IBM WebSphere Commerce Suite, Programmers Guide.Version 5.1 Second Edition. http://www4.ibm.com/software/webservers, March 2001.

In2J, Automated Tool for Migrating Oracle Pl/SQL into Java,www.in2j.com, Apr. 2001, Iplanet.

iPlanet Application Server Migration Guide. Version 6.0. http://docs.iplanet.com/docs/manuals/ias/60/migrate/http:///, May 2000.

Jahnke J, Schafer W, Zundorf A. A design environment formigrating relational to object oriented database systems. In:Proceedings of the International Conference on SoftwareMaintenance, pp. 163–170. IEEE Computer Society Press,1996.

Kassem N. and the Enterprise Team. Designing Enterprise Applica-tion with the Java 2 Platform, Enterprise Edition. Sun Microsys-tems, http://java.sun.com, Oct. 3, 2000.

Lau T, Lu J, Mylopoulos J, Hedges E, Kontogiannis K, XingE, Crowley M. Net.Data to JSP helper. IBM alphaWorks,http://alphaworks.ibm.com/tech/netdatatojsp.

Lu J. Reengineering database applications to EJB based architecture.In: CAiSE∗02, 14th Conference on Advanced Information SystemsEngineering. Toronto, May 27–31, 2002.

Miller RJ, Haas LM, Hernandez M. Schema mapping as query dis-covery. In: Proceedings of the Twenty-Sixth International Con-ference on Very Large Data Bases (VLDB). Cairo, Egypt, Sept.2000.

Moving from IBM WebSphere 3 to BEA WebLogic Server 5.1. Tech-Metrix Research, Sept. 2000.

Ramanathan C. Providing object-oriented access to existing rela-tional databases, PhD dissertation, Mississippi State University,1997.

Sun Microsystems, Enterprise JavaBeans 2.0 Specification.,http://java.sun.com/products/ejb/2.0.html, 2001.

Vermeer MWW, Apers PMG. Reverse engineering of relationaldatabase applications. In: Proceedings of the Fourteenth Inter-national Conference on Object-Oriented and Entity RelationshipModeling (ER’95), Dec. 1995.

Takagiwa O. et al. Programming with VisualAge for JavaVersion 3.5. IBM RedBooks, www.ibm.com/redbooks, April2001.

Yan L, Miller RJ, Haas LM, Fagin R. Data-driven understanding andrefinement of schema mappings. SIGMOD May 2001.

Dr. Terence C. Lau is a senior research associate at theCentre for Advanced Studies, IBM Toronto Laboratory,IBM Canada, and an adjunct associate professor at theDepartment of Electrical and Computer Engineering,University of Waterloo.

Dr. Jianguo Lu is an associate professor at the Depart-ment of Computer Science, University of Windsor.

Dr. John Mylopoulos is a professor at the Departmentof Computer Science, University of Toronto.

Dr. Kostas Kontogiannis is an associate professor at theDepartment of Electrical and Computer Engineering,University of Waterloo.