Migration of a Large Scale J2EE Application from BEA ... · PDF fileMigration of a large scale...

Migration of a Large Scale J2EE Application from BEA WebLogic

to IBM WebSphere

E M A N U E L V I K L U N D

Master of Science Thesis Stockholm, Sweden 2006

Migration of a Large Scale J2EE Application from BEA WebLogic

to IBM WebSphere

E M A N U E L V I K L U N D

Master’s Thesis in Computer Science (20 credits) at the School of Computer Science and Engineering Royal Institute of Technology year 2006 Supervisor at CSC was Stefan Nilsson Examiner was Stefan Arnborg TRITA-CSC-E 2006:134 ISRN-KTH/CSC/E--06/134--SE ISSN-1653-5715 Royal Institute of Technology School of Computer Science and Communication KTH CSC SE-100 44 Stockholm, Sweden URL: www.csc.kth.se

Migration of a large scale J2EE application from BEA Weblogic to IBM Websphere Abstract The abundance of Java 2 Enterprise Edition application servers has made the question of server compatibility increasingly important. To analyze the compatibility we examined a migration of Planitgo, a J2EE application for online travel booking, from BEA WebLogic Server to IBM WebSphere Application Server. To perform the migration we developed a general methodology for migrating J2EE applications. The two main aspects of developing the methodology were identifying the key steps necessary and the order in which they should be performed. The learning from our migration was that the majority of the problems occur not because of shortcomings of Java but because of poor adherence to standards by application servers, development tools and developers. To mitigate those problems the key steps in any migration procedure are to learn the new application server and the associated development tools. Also, in comparison with a parallel study involving the migration to JBoss, we found IBM WebSphere Application Server to adhere more strictly to standards but to be more difficult to configure.

Migrering av en storskalig J2EE applikation från BEA Weblogic till IBM Websphere Sammanfattning Det stora utbudet av Java 2 Enterprise Edition applikationsservrar har gjort frågan om kompatibilitet mellan olika servrar allt viktigare. För att analysera kompatibiliteten undersökte vi en migration av Planitgo, en J2EE applikation för att boka resor på Internet, från BEA WebLogic Server till IBM WebSphere Application Server. För att genomföra migrationen utvecklade vi en generell metod för migration av J2EE applikationer. De två viktigaste aspekterna av att utveckla metoden var att identifiera de mest betydelsefulla stegen samt i vilken ordning de skulle utföras. Lärdomen från vår migration var att större delen av problemen inte inträffar på grund av Javas tillkortakommanden utan på grund av dåligt följande av standarder bland applikationsservrar, utvecklingsverktyg och utvecklare. För att avhjälpa dessa problem är de viktigaste stegen i en migration att lära sig den nya applikationsservern och tillhörande utvecklingsverktyg. I jämförelse med en parallell studie av en migration till JBoss fann vi att IBM WebSphere Application Server följer standarder bättre men är svårare att konfigurera.

Foreword The master’s project was conducted during the winter, spring and summer of 2004 at Amadeus in Sophia Antipolis 10 kilometers from Nice, France. This project covers half of a larger project trying to establish if the online travel booking application called Planitgo can be migrated from the current server BEA WebLogic Server to a new application server. The project was initiated to explore alternative solutions when the load on the application server exceeded the by the manufacturer tested upper limits. Within the scope of this project two servers were evaluated; IBM Websphere Application Server and JBoss. The application server choices were made to have two servers from opposite ends of the scale to fully explore how difficult the Planitgo application is to migrate. This master’s thesis focuses on the migration to IBM WebSphere but naturally some of the material overlaps with the JBoss migration. The migration to JBoss is handled in a separate report written by Erik Tjernlund. Throughout this thesis the term “we” has been used to represent the author. Finally, we would like express our deepest gratitude towards our supervisor at Nada, Stefan Nilsson, and our supervisors at Amadeus. Thank you!

Table of contents 1 Introduction, problem formulation and purpose ............................................................ 1

Principals ...................................................................................................................... 1 Question ........................................................................................................................ 1 Purpose.......................................................................................................................... 1 Goal............................................................................................................................... 2 Structure of the report ................................................................................................... 2

2 Background to the application and J2EE....................................................................... 3 Amadeus ....................................................................................................................... 3 The Planitgo application ............................................................................................... 3 System Architectures .................................................................................................... 4 Description of J2EE Technologies ............................................................................... 6

3 Migration methodology ............................................................................................... 14 Understand the application ......................................................................................... 14 Verify the source code on the current application server ........................................... 14 Install the new application server ............................................................................... 15 Learn the new application server ................................................................................ 15 Make the development environment work ................................................................. 15 Identify obvious migration problems.......................................................................... 16 Identify J2EE problems .............................................................................................. 16 Migration of the application ....................................................................................... 16 Migration back to the original server.......................................................................... 16

4 Analysis of the migration............................................................................................. 18 Understanding the Planitgo application...................................................................... 18 Verifying that Planitgo runs on WebLogic................................................................. 20 Installation of WebSphere application server............................................................. 22 Learning the WebSphere application server............................................................... 23 Setting up the development environment ................................................................... 24 Obvious migration problems ...................................................................................... 30 Analysis of J2EE services........................................................................................... 36 Migration of the application ....................................................................................... 42 Migration back to the original server.......................................................................... 43

5 Conclusion: How to perform a migration .................................................................... 44 Understand the application ......................................................................................... 44 Verify source code on the current server .................................................................... 44 Installation of the new application server ................................................................... 44 Learn the new application server ................................................................................ 44 Development environment.......................................................................................... 44 Obvious migration problems ...................................................................................... 45 J2EE problems ............................................................................................................ 45 Migration of the application ....................................................................................... 45 Summary..................................................................................................................... 45

6 Conclusion: A comparison of WebSphere and JBoss ................................................. 46 Adherence to standards............................................................................................... 46 Ease to work with ....................................................................................................... 46 Conclusion .................................................................................................................. 46

7 Future research............................................................................................................. 48 References....................................................................................................................... 49

Appendix......................................................................................................................... 51 Appendix A. Dictionary.............................................................................................. 51 Appendix B. Code....................................................................................................... 52

Chapter 1 Introduction, problem formulation and purpose

1

1 Introduction, problem formulation and purpose Principals This master’s thesis project was conducted at the e-Travel department at Amadeus s.a. in Sophia Antipolis, France, between January and July 2004.

Question Amadeus have a large scale Java 2 Enterprise Edition (J2EE) application called Planitgo. Our task was to investigate if that application could be migrated from BEA WebLogic Server (WLS) to IBM WebSphere Application Server (WAS) and how such a migration should be performed. In a separate but simultaneous project the task of migrating the application from BEA WebLogic Server to the open source JBoss application server was investigated. This paper will include some findings from that project and we refer the reader to that master’s thesis for the complete report [5].

Purpose The purpose of this project was to first investigate how a migration of the application at hand could be performed and then draw general conclusions for this type of migration. To understand the purpose of this project, some background is required. Java was engineered in accordance with Write Once, Run Anywhere (WORA). To accomplish that, the platform dependent behavior is abstracted away using Java compilers and application servers. However, due to the abundance of application server providers and the mistakes of programmers, there is reason to believe that a large scale Java 2 Enterprise Edition (J2EE) application cannot easily be migrated between different application servers although it should, according to standards, be a straightforward operation. The heterogeneity in the application servers is not the only difficulty. To manage a large scale J2EE application you typically need an extensive set of tools. Most important are the build system, the code authoring tool, the versioning system and the debugging tools. To migrate a large application you thus have to find new solutions to all of these problems. In this project we will examine all these sub-problems even though the main focus will remain on the shift from one application server to another. Earlier migration studies have focused largely on how specific examples of code can be migrated but there are few independent studies on the overall implications of a major migration effort. Since the application at hand has high traffic1 the migration of 1 According to Alexia (http://www.alexia.com) 11th June 2006 the 3 month rank of www.opodo.co.uk was 2,369, making it number 13 worldwide in the air category. Planitgo also powers many airlines’ booking sites making the total traffic for the application even larger.

Chapter 1 Introduction, problem formulation and purpose

2

this specific application will provide interesting results which can be applied to other J2EE applications as well.

Goal Several groups will benefit from the migration study. Naturally Amadeus and anyone in their situation will find the migration study useful. But we believe that the groups that have the most to learn are the software developers writing the code and setting up the development environment. By having portability in mind you could save a lot of effort in a later migration. Furthermore, developers of application servers could also benefit from these results. Often there are no problems with the code as long as you work in the same application server, but since all application servers do not strictly adhere to standards there are ambiguities when you move the code from one environment to another. Also, the makers of development tools could gain insights in how tightly coupled application servers and tools should be.

Structure of the report First we will provide some background on Amadeus, Planitgo and J2EE related aspects. Then we will describe the methodology for how to perform a migration. After that, the main analysis chapter will follow where we thoroughly examine the application by using the migration procedure. The conclusions from the migration are then summarized in the subsequent chapter followed by a joint conclusion from the parallel JBoss migration project. The report is finally concluded with a short discussion of further research on the subject.

Chapter 2 Background to the application and J2EE

3

2 Background to the application and J2EE The background chapter will start with a brief presentation of Amadeus and their different products. We will present what products they sell and by whom those products are used. Then we will give some specifics of the Planitgo application. Next a brief background on large-scale software architectures and distributed objects will be presented as a foundation for the emergence of J2EE. The chapter ends with two short sections containing an introduction to application servers and a description of Java BluePrints.

Amadeus Company history Today Amadeus is arguably the leading Global Distribution Systems (GDS) in the world. Amadeus was founded in 1987, by Air France, Iberia, Lufthansa and SAS, and has grown rapidly since with Europe being a natural home market. Their online presence started in 1997 when they launched their first travel booking website. To strengthen the online presence they acquired e-Travel Inc., a leading supplier of hosted corporate travel technology products, in 2001. The former e-Travel Inc. is today an integrated part of Amadeus, developing and further refining online travel solutions [6]. Subsequently Amadeus also acquired a controlling stake in Opodo, a leading European travel website.

Products and Markets Being a joint-venture between major airlines, it is not surprising that airline bookings generate the lion’s share of online revenues.2 However, the product portfolio has been expanded to now include adjacent products such as ferry, hotel, car, railway, cruises and travel insurance. The typical customers of Amadeus products are travel agencies, airlines, travel portals, ferry lines, hotel companies, car rental companies and corporations in need of in-house travel solutions [7].

Technology Amadeus encourages the use of open standards where possible to make sure every technological solution is designed to be fully customizable as demanded by their heterogenic customers. The use of open technology is important for our study since we rely on the use of open standards for the results to be more generally applicable.

The Planitgo application The Planitgo [7] application is an online booking engine for airline tickets, developed especially with private customers in mind. You have probably used it if you have ever booked tickets through a major European airline’s website. The buyers of the Planitgo 2 After this project was conducted a majority stake of Amadues was bought by BC Partners and Cinven and the company delisted.


4

application and functionality are airlines and online travel portals. They buy the same base application which is then customized according to their particular needs. Most of the time, they do not need any big changes of functionality, it is more a matter of integrating the application with their current online offering. For the time being, Amadeus provides hosting of the application, but this could change if airlines would like to host their own applications. This imposes great demands on the application in terms of interoperability with many different technological environments. To accommodate these demands, Planitgo is built using Java 2 Enterprise Edition (J2EE). The J2EE technology will be further investigated later in the report but we can conclude that Amadeus both strives towards developing standards compliant products and their customers demand it. A priori we therefore expected Planitgo to comply well with software standards. This was also the belief of the software developers at Amadeus.

System Architectures System architectures have gradually developed over time and in the system architecture chapter we will cover the development from mainframe architectures to the n-tier architectures of today.

Mainframe architectures The mainframe architecture with a single large mainframe computer and many connected terminals became popular in the 1960s and 1970s. The main reason for the popularity was the fact that the expensive mainframes needed a large base of users to share the cost and the personal computer was yet to be introduced. There was simply no other way to give many users access to computational power at an affordable price. The main drawback of the mainframe architecture was that the graphical user interfaces were very poor on the terminals. Therefore, with the introduction of the personal computer in the 1980s which could handle more advanced user interfaces the mainframe and terminal based systems started to decline in popularity [9].

File sharing architectures The PC networks that grew in popularity first employed a file sharing architecture where files were downloaded from a central location and then manipulated. The file sharing architecture works well if the files are small, there are few users and the data is infrequently updated. With the rapid growth in the number of users during the 1990s the file sharing architecture could no longer accommodate the needs of users. Therefore a new architecture was introduced, the client-server architecture [9].

Client-server architecture The problem of the file sharing architecture was that data was dispersed across a large number of nodes, making it inherently difficult to know where data was and which data was the most recent. The client-server architecture solved the data integrity problem by introducing the concept of a database server in lieu of the file server. The clients would run a graphical operating system providing a visually appealing interface to the server [9]. The database server was most often a relational database management system (RDMBS) which users could query using standard query language (SQL). Advantages of the new approach were that the entire file did not have to be


5

transferred across the network each time and the location and consistency of data were no longer problems [9]. Client server architectures are usually categorized according to the number of tiers.

Two-tier architectures Two-tier are comprised of the user tier and the database tier. Divided between those tiers are three components/tasks:

1. User System Interface: which resides on the client 2. Processing Management: which is split between the server and the client 3. Database Management: which resides on the server

The user system interface and the database management are well defined tasks which reside on the client and server respectively. However, the processing management task is not clearly defined. The main tasks of processing management are accessing the data and performing operations on the data to make the context meaningful. Often the database server hosted the code for accessing the data whereas the client hosted the code for aggregating and manipulating the data in meaningful ways. Due to the somewhat arbitrary division of the processing management a third tier was introduced to make the division of the tasks between the layers less ambiguous and improve scalability of applications.

Three-tier architectures The three-tier architectures solve the main shortcomings of the two-tier architecture by introducing a third tier between the user tier and the database tier. The middle tier can be implemented in a variety of ways including transaction processing monitors, message servers and application servers. The application server’s task in this setting is to handle the “main body” of the application including business logic, computations and data retrieval. The main advantages of letting more code reside on a server are fewer security issues, better scalability and reduced installation and support costs. Not surprisingly, those are exactly the features required for a large scale application.

N-tier architectures The three-tier architecture can be further specialized by introducing new tiers. A common fourth tier is a web server which handles requests from web clients. The web server tier, or presentation layer, lies between the user and the application server layer.

Distributed enterprise architectures The distributed enterprise architectures are further developments of the n-tier architectures. They provide not only access to objects but also to business processes and models. The goal of the enterprise architectures is to provide a common framework where individual components can be plugged in as needed. Standardized interfaces between components give greater flexibility. The underlying system is organized as a distributed system where objects, processes and models are shared across the network and do not reside on one single host. In essence a distributed object is a piece of code or information that can reside anywhere on the network and the architecture comes with a set of tools for retrieving this object no matter where it is stored. Thus the exact location of the object is of no interest to the programmer.


6

One of the most successful distributed enterprise architectures today is the Java Enterprise architecture which Planitgo is written for. The main competitor in distributed enterprise architectures is the .NET framework from Microsoft [15].

Description of J2EE Technologies This chapter will give a general description of what the Java 2 Platform Enterprise Edition (J2EE) is and the specific technologies most relevant for the Planitgo application.

What is J2EE? So, what is J2EE? According to Sun Microsystems and their J2EE Frequently Asked Questions, J2EE is: “The Java 2 Platform, Enterprise Edition (J2EE) is a set of coordinated specifications and practices that together enable solutions for developing, deploying and managing multi-tier server-centric applications. Building on the Java 2 Platform, Standard Edition (J2SE), the J2EE platform adds the capabilities necessary to provide a complete, stable, secure, and fast Java platform to the enterprise level. It provides value by significantly reducing the cost and complexity of developing and deploying multi-tier solutions, resulting in services that can be rapidly deployed and easily enhanced.” [18] A short word of caution about J2EE is necessary. Most people in computer science have one or more times come in contact with the game Go which have the slogan “minutes to learn, a lifetime to master” [8]. Even though J2EE is comprehensive and fairly straightforward to learn, it is not straightforward how to use it in an optimal way. A collection of J2EE experts expressed it as follows: “While the fundamentals of the J2EE platform are relatively easy to describe, mapping these features to architectural issues in the design of distributed applications requires deeper understanding and careful decision making.” [3]

High level architecture of J2EE J2EE naturally divides applications into distinct tiers; the client tier, the middle tier and the Enterprise Information Systems (EIS) tier (see figure 1). The client tier is responsible for presenting a view to the client. The middle tier is responsible for processing and can be further refined into more tiers such as the web tier and the application server tier. The EIS tier is responsible for persistently storing the data.


7

Figure 1 Schematic picture of J2EE divided into tiers.3

J2EE includes three types of technologies to make the framework (see figure 1) work well:

• Component technologies: data and application components • Service technologies: manipulating data and components • Communication technologies: exchanging information over a network

Component technologies provide the foundations to create user interfaces and business logic among other things. The following components are available in J2EE:

• Applets • Application clients • Enterprise JavaBeans (EJB) components • Web components (JSP pages and Java Servlets) • Resource adapter components

The components in J2EE reside inside containers which are responsible for delivering a set of service technologies to the components. In order for the components to be useful they need access to J2EE services to perform tasks such as naming and transaction management. The core service technologies are:

• Java DataBase Connectivity (JDBC) API • Java Transaction API and Service • Java Naming and Directory Interface (JNDI) • J2EE Connector Architecture • Java API for XML Processing Technology (JAXP)

The last group of technologies is the communication technologies. They provide means of communication between clients, servers and distributed objects. The J2EE specification requires support for:

• Internet protocols (HTTP, TCP/IP and SSL) • Remote method invocation (RMI) protocols

3 Image from http://java.sun.com


8

• Object Management Group (OMG) protocols • Messaging technologies • Data formats

We will now explain what an application server does and after that walk through some of the most important specifications in J2EE which are used in the Planitgo application.

Application servers An application server is a collection of connected containers that supplies a J2EE application with the services that the J2EE API specifies as described above. The actual implementation of those services is up to the application server vendor. In effect this means that the container provides the infrastructure and takes care of all the low-level and generic functionality, leaving the developer to concentrate on creating the actual application specific logic. The J2EE specification is provided by Sun Microsystems, but it is open for anyone to create implementations of the described services. The openness has created a very competitive and fast evolving market for application servers, with many different vendors, including large corporations like IBM (Websphere) and BEA (Weblogic), but also open source products like JBoss [14] and Apache Geronimo [12]. “Application development responsiveness requires the ability to mix and match solutions to come up with the optimum configuration for the task at hand. Freedom of choice in enterprise application development should extend from servers to tools to components. The wide range of J2EE compatible solutions available today and in the future ensures the maximum freedom of choice.” [3] Application server vendors can get a certification from Sun that their server is compliant with a certain version of J2EE. Both WebLogic and WebSphere are J2EE 1.3 certified and JBoss was on the way of being J2EE 1.4 certified when this migration study was undertaken. Selecting application servers which are certified is a way to make sure all the necessary functionality is present.

Enterprise JavaBeans An Enterprise JavaBean (EJB) is a server-side component that either performs logic or takes care of persistence of data. EJBs are deployed in a container which takes care of operations such as transactions, communication between components and security. The container is provided by the application server [25]. The main purposes of EJBs are to be:

• Distributable. For example, EJBs can be run on different computers in a network or in different virtual machines (in different application servers) on the same physical machine. At the same time clients should be able to use the beans seamlessly, like if they were in the same virtual Java machine.

• Reusable. They should easily be reusable in more than one application. • Deployable. There should be infrastructure to take care of the required generic

functionality and a framework to deploy EJBs in such an environment. Part of this infrastructure is what we earlier referred to as services. The most


9

important services include life cycle management, support for transactions, security and remote access to the business objects. These services are provided by the EJB container.

There are three basic types of EJBs; Session Beans, Entity Beans and Message Beans.

Session Beans Session beans take care of business processes. In short they are like verbs; they do things. There are two different types of session beans; stateful and stateless. The stateful version remembers the state of a process spanning over multiple requests from a client.4 The stateless bean does not keep information at all from a previous request. The difference can easily be understood by looking at the following two examples; showing the price list of tickets versus purchasing a ticket.5 If you just request information about availability and prices for a certain trip there is no information that needs to be kept by the server for the next search, you just enter a new search for a new destination.6 If you proceed to the next step and purchase a ticket however, it is of crucial importance that we keep track of which trip you are trying to book, who you are and if you have paid the trip etc. Clearly you would need a stateful session bean in the latter example but not in the former case. The reason why you would not always want to have a stateful session bean is to improve performance. If you have to save information about each session the server will need more memory and processing power.

Entity Beans Entity beans describe business data. Compared to session beans, they are like nouns; they capture the state and properties of a thing. Entity beans are persistent objects which can be placed in permanent storage (e.g. in a database). The J2EE specification describes two different types of entity beans: the bean managed persistence (BMP) entity bean and the container managed persistence (CMP) entity bean. In the BMP bean, it is up to the developer to write the persistence operations (retrieving, saving and finding of data) using an API like JDBC. For example, to save an entity bean’s state, the developer would do a SQL INSERT statement via JDBC and store the data in an ordinary relational database. In CMP beans the developer is relieved from providing the specifics of persistence. It is up to the container to generate the code for storage of the bean. If the developer would like to execute commands on the database the EJB-QL language is available as a platform independent query language since SQL is not truly platform independent. All entity beans in Planitgo are BMP beans. The reason is that when they developed Planitgo CMP was not part of the J2EE specification. Furthermore, the fact that performance is crucial for the application makes optimization of database operations a necessity. The drawback of providing customized SQL is the tighter coupling between the application and a specific database vendor.

4 The state we are talking about here is conversational state which is the state of the conversation between a client and the application. The other type state that is usually referred to is the persistent state which is a state that is kept between different conversations by storing it in a database or on disk. 5 An example of persistent state would be a bank account which needs to keep information about the current balance. 6 In principle this is true although some services will keep the information about the destinations to facilitate new searches which often include the same departure city and/or date for example.


10

Message Beans The Planitgo application only contained a few message beans and their functionality was not critical. We will therefore not spend any further time on message beans.

Local vs. remote interfaces Entity and session beans can have either local or remote interfaces. The interface is the part of the bean that clients access to use the bean. The feature with having a local interface is that it does not have to be transmitted across the network upon each call and that it will be passed by reference instead of passed by value. The requirement to use a local bean is that the client is in the same Java Virtual Machine (JVM) as the bean. A bean can have both a local and a remote interface, but usually it is not very efficient to have each bean providing both a local and a remote interface. Instead, to give access to an entity bean to a remote client, the best way is often to create a session bean with a remote interface as a façade [1] which can perform the desired transactions on the local entity beans.

Implementation of EJBs EJBs are packaged in JAR files together with configuration information. Each EJB comes with an XML file called ejb-jar.xml which specifies configuration parameters. An example of the file is given in appendix B1. The ejb-jar.xml describes what type and name the EJB should have and which interfaces (local and/or remote) it should provide. It also includes references to other required EJBs and resources. How the application server maps the configuration in the ejb-jar.xml is dependent on the implementation. The most common solution is to include a vendor-specific configuration file that also goes together with the EJB. In the BEA WebLogic application server they have named that file weblogic-ejb-jar.xml and in appendix B2 an example matching the above mentioned ejb-jar.xml is provided.

Web component technologies There are two web component technologies specified in the J2EE specification, Java Servlets and JavaServer Pages (JSP) [3]. Both of them are used in Planitgo.

Java Servlets The Java Servlet API describes programs that extend and enhance web servers by allowing developers to add dynamic content to web servers. Servlets are similar to traditional CGI7 programs, but more efficient and portable. The Servlet API defines the interactions between the servlets and the web container.

JavaServer Pages JavaServer Pages (JSP) is an extension of the Java Servlet technology. JSPs are useful when you want to output dynamic content in the form of HTML. JSP pages are actually translated to Servlets when they are deployed in the server and are just a document-centric representation of dynamic content in contrast with the programmatic approach used in Servlets.

7 CGI stands for Common Gateway Interface and is a standard for access to legacy systems through the Internet.


11

JSPs can be written using either JSP tags or XML syntax, but a single JSP may not contain a mix of the two methods. “The JSP specification defines an alternate XML syntax for JSP pages. Pages in standard JSP syntax cannot be well-formed XML because the markup does not conform to XML’s requirements. Pages using the alternate JSP XML syntax can be validated against an XML Schema Definition Language (XSDL) schema to check for many potential errors that would otherwise appear only at runtime. XML syntax can also facilitate integration with development tools. For integrity, a single JSP file may not contain a mix of standard JSP syntax and XML syntax.” [3]

Usage of Servlets and JSPs Servlets and JSPs are often used together in variations of the familiar model-view-controller [1] design pattern. Two variations of the MVC pattern are generally used today, Model 1 and Model 2 [13]. Model 1 refers to a simple MVC pattern where the JSP receives requests from browsers and performs actions with JavaBeans. The Model 1 MVC pattern (see figure 2) separates data from presentation since all data is handled by the JavaBean. A common problem with the design is that since all processing is performed by the JSP it will contain a lot of Java code, making the page difficult to read and maintain.

Figure 2 Model 1 MVC pattern. 1) A request is sent from the browser to the JSP. 2) The JSP processes the request and uses the JavaBean to access the database 3) The JavaBean perform the necessary operations on the database 4) The response is returned to the browser by the JSP.

The other and more complicated variation is called Model 2 (see figure 3) and has a servlet acting as a controller which dispatches requests from clients to the correct JSP. By using the Model 2 pattern design is truly separated from content, which is also the intention of the model-view-controller pattern. The design is also consistent with the intention of JSP pages and servlets, leaving presentation to JSPs and processing to servlets.


12

Figure 3 Model 2 MVC pattern. 1) A request is sent from the browser to the Controller Servlet. 2) The Controller Servlet creates the necessary JavaBeans for the JSP page 3) The Controller Servlet dispatches the request to the correct JSP 4) The JSP performs the requested actions using the JavaBean created by the Controller Servlet 5) The response is sent back to the browser.

“In the Web tier, the question of whether to use JSP pages or servlets comes up repeatedly. JSP technology is intended for application user interface components, while Java Servlets are preferred for request processing and application control logic. Servlets and JSP pages work together to provide dynamic content from the Web tier.” [3]

Java Naming and Directory Interface The Java Naming and Directory Interface (JNDI) is an API that provides naming and directory functionality to Java applications. Naming and directory basically means providing a yellow pages type of service to look up paths and configuration information. JNDI comes bundled with Java Development Kit (JDK) 1.3 and higher and provides a unified interface to multiple naming and directory services. It is the backbone of many other J2EE APIs, for example EJBs. The J2EE specification defines a special JNDI context that extends the normal JNDI context in two ways [11]:

1. Indirect lookup. The name used in the Java code to look up an object is not the real name of the object but an alias for the real object name. This means that the name of the actual object can be changed without changing the name in the Java source code.

2. Deploy-time binding of target objects. The deployment descriptor describes which object the name should be associated with. This makes it possible to define dependent EJBs and services at deploy time, independently of the Java code.

Implementation of JNDI EJBs and web components are required to provide JNDI configuration information for lookup of components. Both provide the configuration in the mandatory XML configuration files:


13

• META-INF/ejb-jar.xml for each EJB JAR • WEB-INF/web.xml for each web component (JSP and servlet)

Application servers also require vendor specific configuration details for JNDI to be specified.

Java DataBase Connectivity API The Java DataBase Connectivity (JDBC) API provides connectivity to a wide range of SQL databases. Database vendors can implement the JDBC API to make the database accessible even in a heterogeneous environment. “Much of the data of value to organizations has been collected over the years by existing enterprise information systems. Much of the programming investment resides in applications on those same systems. The challenge for developers of enterprise applications is how to reuse and commoditize these existing information assets.” [3]

Java Management Extensions JMX is not an important part of the Planitgo functionality and therefore we will not spend time further analyzing it.

Java BluePrints At the same time as the fast development and abundance of application server providers is one of the great advantages of J2EE, it is also a source of problems since software providers sometimes are too far ahead of the standardization process, with diverging best practices as the result. To help developers, a set of design principles and best practices have been developed under the name of Java BluePrints [19]. “Different implementations of the J2EE platform may provide distinguishing characteristics that improve their performance or development ease in particular areas. However, the level of abstraction provided by the J2EE standard enables common themes to be developed, explained, and explored and certain common design guidelines to be developed. That’s what Java BluePrints is all about.” [3] We highly suggest that any J2EE developer uses these design principles as it will ensure that you use each standard the way it is intended. Also, it will provide answers to common design problems.

Chapter 3 Migration methodology

14

3 Migration methodology The migration was completed following the methodology below. This methodology was developed in close cooperation with the principals from Amadeus. The purpose of a structured and ordered approach was to schedule the migration effort and minimize redundant work. The steps we went through were in order:

• Understand the application. • Verify that the application runs on the current application server. • Identify the requirements of the new application server and install it. • Learn the new application server • Make the development environment work. • Identify obvious migration problems. • Identify J2EE problems. • Migrate the application to the target application server. • Migrate the application back to the source application server.

We will now go through each step in the migration process and give a description of what will be covered and why it is important.

Understand the application One of the most important things is to have an overview of the application at hand, including which technologies (i.e. J2EE specifications and design patterns) are used. Even large J2EE applications could be understood reasonably quickly at a high level since several classes perform similar tasks and/or have a common superclass or interface. If the application has been developed in accordance with good software design principles, the task should be further simplified. Usually there is also extensive documentation of larger applications provided by the developers. A particularly interesting and helpful piece of documentation would be Unified Modeling Language [2] (UML) documentation. UML was developed as a generic language to describe software and uses of software and is today an industry standard [2].

Verify the source code on the current application server Although this may seem like a superfluous step it is mandatory in any migration study. The purpose is mainly twofold. First we would like to isolate all the possible errors during the migration to the change of application server. Hence, there can be no confusion over what made the error occur (e.g. all errors should come from the migration and not from already present bugs). Secondly, it gives you a further chance to understand the application and the current development environment. Almost without exception, you will have to make changes to the code when you realize that the source and target application servers do not behave in the same way. If that is the case you should ideally take one step back and implement all the application server independent changes on the source application server. Having a


15

working version of the application on the old application server can prove invaluable when running into problems on the new application server since you have a reference implementation in case you are hesitant on the desired behavior. Since the process of continuously staging the source code on the old application server can be time consuming when you have changed many things, one solution is to continue to work on the new application server and then migrate the application back to the source application server after the migration is completed. The backward migration is covered last in the methodology.

Install the new application server This step includes looking at requirements of the new application server and installing it. Main obstacles could include hardware requirements, software requirements and configuring the server. The mission-critical requirements such as operating system should have been assessed before choosing which application server to migrate to and hence that step has not been covered in our study.

Learn the new application server In our experience, learning the new application server is one of the most important steps in the whole migration and cannot be emphasized enough. Different application servers have different ways of functioning and behaving. What we suggest here is a “spend time early to save time later” approach. If possible you should attend a course on the application server. Even though the test applications are usually easy to start it is an entirely different thing to try to move an existing application to a new application server. Not to mention the level of skill and experience needed to do a meaningful performance evaluation. Naturally you will have to go back to learning the application server several times when running into problems.

Make the development environment work To have a well functioning development environment is very important: “Access to the appropriate tools for the job is another important choice. Development teams should be able to adopt new tools as new needs arise, including tools from server vendors and third-party tool developers. What’s more, each member of a development team should have access to tools that are most appropriate to their skill set and contribution.” [3] The most crucial aspects of setting up the development environment include a standardized way to work with and edit:

• Source code version control • Rapid Application Development (RAD) tools/source code editors • Deployment descriptors • Build process • Deployment process • Server configuration

We will examine how each of these tasks/tools can and should be set up in more detail later.


16

Identify obvious migration problems There are a few migration problems that can be expected in any migration between two specific application servers. Identifying those early on could reduce the errors and focus the effort on the other problems. Large applications are almost certain to contain vendor specific code. Typical examples are features provided by the vendor to simplify tasks such as logging or monitoring. Since programmers unfortunately are only human, there probably also exists code that should be changed because it does not follow good design principles, or even worse, does not work at all. Differences in packaging options between application servers could also cause problems.

Identify J2EE problems Java is a platform independent language but there are still some parameters that need to be changed when migrating an application. The first and easiest check of this is to make sure that the application servers actually support the same Java version (this should already have been done before the decision of which application server to migrate to). Other typical examples of J2EE problems are configurations for JNDI, JMS and database connectivity. Furthermore, there often exist other problems related to misconceptions of the J2EE standards and sloppy adherence to standards by developers and application servers.

Migration of the application Planitgo has two parts, the front-end and the back-end. The front-end contains what will later be explained as the presentation, application and business layers. Basically it handles everything but the data access which is handled in the back-end. The two parts of the application have been developed as two separate components, making it possible to deploy them separately and have them communicating through a defined interface. The division of the application made it possible to first migrate one part and then the other. A two-step approach would isolate changes made in the front-end from those made in the back-end and thus greatly simplify debugging and testing. In terms of complexity and size, the front-end is by far the more complex and larger part of the two. Therefore we quickly realized that it would be beneficial to start with the migration of the back-end to not have to handle all the potential problems at once. Also, since the back-end did not contain any code that handled servlets or JPSs we reduced the number of different J2EE specifications involved in the first step of the migration. Once the back-end was migrated we could undertake the migration of the front-end.

Migration back to the original server All code changes of general nature should in principle be staged on the existing server. However, since they are often not discovered until late in the migration process a final one-time effort to migrate the changed application back to the original system could be performed. The need for the backward migration becomes evident


17

considering the sloppiness of application servers to enforce standards. By migrating the application back to the original application server you make sure that your code changes are application server independent, at least for the source and destination application servers.

Chapter 4 Analysis of the migration

18

4 Analysis of the migration In this chapter we will go through the methodology described above in detail and present the results from the migration study.

Understanding the Planitgo application This section will describe the most important design and packaging aspects of the Planitgo application.

Design The underlying design principle of Planitgo is the MVC pattern. The application is divided in layers, where each layer has a specific task and is only accessed from the layers immediately above and below. The four layers are the presentation layer, application layer, business layer and access layer (see figure 4). The specific type of the model-view-controller pattern that is used in Planitgo is the Model 2 MVC pattern.

Figure 4 Schematic overview of the Planitgo architecture including the four layers. The components of each layer will be described in the section describing the specific layer. Different clients will send requests to the presentation layer. The back end of the application is the GDS (Global Distribution System) which stores all booking information.


19

Presentation layer The presentation layer is the communication interface. It handles two types of requests, SOAP/XML and HTML requests. The presentation layer is responsible for dispatching decoded requests to the application layer, and then presenting encoded results to the client. The presentation layer contains the flow and the presentation logic of our components and uses servlets and JSPs in accordance with the Model 2 pattern.

Application layer The application layer contains what is referred to as Action components. Actions are neutral pieces of logic (a Java class which implements a proprietary Planitgo action interface) capturing a user action and being used to call a business component. Each action is mapped to a Uniform Resource Identifier (URI) and is called by the controller part of Planitgo for every incoming request (HTML or SOAP). Data is transmitted between the presentation and application layers using a proprietary class, DataMap, which is basically a hash map implementation in the spirit of the Data Transfer Object pattern [10]. The application layer cannot be used remotely; access must come through the SOAP/XML or HTML interfaces in the presentation layer and be forwarded from there.

Business layer Persistent information is managed in the Business layer which contains all business components and services that can be re-used by the application layer. Every component in the business layer manage the business logic of a given use case and access to the access layer. Each component is implemented by a stateless session bean and follows the Session Façade pattern [1]. This pattern is common in J2EE applications and enforces the partitioning of the application in different layers with low coupling. That means that the boundary between the application layer and the business layer is properly defined by an interface. The implementation of that interface is hidden from the client view (and the other layers). The Session Façade pattern also optimizes the number of calls between the presentation layer and the EJB container. Further, the ability to use EJB local interfaces increases performance and reduces network traffic. To make Planitgo customizable the concept of a site was developed. A site is a specific instance of the Planitgo application, customized for a particular customer. The customization is implemented by the proprietary class SiteContext which holds customizable parameters for a specific site. Each component accepts a SiteContext instance which provides access to the various functional settings corresponding to the relevant site. Coupling between layers is low since each component accepts a Data Transfer Map and then decodes and checks the input and upon completion returns fully decoded results within the Data Transfer Object.

Access layer The Access layer is a flexible way to plug-in new data providers to Planitgo. This connector-like architecture can integrate multiple sub-systems or providers without modifying the global architecture by adhering to common interfaces.

Packaging Planitgo can be packaged in two different ways, either the complete application can be packaged in one EAR or the access layer plus some utility classes can be packaged


20

separately from the other three layers. The top three layers are referred to as the front end and the access layer is referred to as the back end in the two module packaging scenario. One of the main reasons for the packaging is to make testing easier. Many times you do not want to worry about where the data comes from when you are testing the front end. Instead you want to be sure to receive the correct data in a timely fashion, for example when performance testing the front end. These two packaging options allow the data connectivity and the functionality to be tested separately. For testing the front-end, a dummy back-end is deployed, sending pre-defined static data. Testing the back-end on the other hand, one would not want the front end to be deployed as it would be difficult to determine where a possible error occurred if the data passes through all of the front-end processing before the error is discovered. We decided, as mentioned earlier, to migrate the back-end first to establish the connectivity and then the front-end to establish the functionality.

Summary This concludes the section of understanding the application. We felt that we had a sufficient understanding of the application and the different parts. The extensive documentation already provided made us feel fairly comfortable with the overall structure of the application despite of the large scale. The main purpose of understanding the application is to identify which technologies are used and if there is any way to divide the application in smaller pieces which can be handled separately. The information given above gave us confidence that we were on the right track and we proceeded by examining how and if the application functioned in the current environment.

Verifying that Planitgo runs on WebLogic To verify that Planitgo was functioning on BEA WebLogic Server (WLS) was a fairly straightforward task, Amadeus had already provided some tests and Planitgo passed these tests. In most applications there will be a test suite to determine that the application is working and those can be used to stage the application before the migration. We did however run into problems in the parallel migration effort and those are described next.

Migrating to Java 1.4 We ran into problems when we tried to start the JBoss application server in the parallel migration effort since JBoss could not start using Java 1.3 for unknown reasons.8 Because of the Java incompatibility we had to decide whether to upgrade to Java 1.4 or not. The obvious benefit of upgrading is that you get an application that can take advantage of the latest functionality in Java. Furthermore, most applications need to be upgraded sooner or later if they are to be further developed. If you expect to have to upgrade the application to the new Java version at some point it would be better to

8 Several other developers had experience the same problem but no solution had been presented by JBoss and neither was it a priority since a new version of JBoss was soon to be released.


21

do it when you are already going through the application carefully. Hence it seemed appropriate for us to also perform the Java upgrade as a part of the migration process. However, there was one thing that made us hesitant to upgrade. There could be hidden bugs which would become evident when we upgraded to the new Java version. Not until the new Java version has been used in production for some time can it really be thought of as stable, if ever. It is important to remember that not only bugs in the application, but also in the new Java version could be introduced. If upgrading to a new Java version it would probably also mean that a lot of benchmark testing had to be repeated. After consulting with the responsible for the Planitgo application it was decided that we should migrate Planitgo to Java 1.4 in order to solve the problem. We upgraded the application in the old WebLogic environment and staged the source code and tested it once more. The main obstacles when upgrading to the new Java version were related to some new classes and keywords that were introduced in Java 1.4 and gave conflicts with proprietary Amadeus class names. An example of the problem with keywords is included below. The original source code looked as follows:

import java.util.*; import com.amadeus.ocg.uti.dictionary.LinkedHashMap; … LinkedHashMap m = new LinkedHashMap();

The problem is that in Java 1.4 a new class named LinkedHashMap was introduced in the java.util package. Since we imported both the proprietary Amadeus LinkedHashMap and the new Java LinkedHashMap class there was an ambiguity relating to which LinkedHashMap class we actually wanted to use. We therefore rewrote the above code to explicitly state the package name.

import java.util.*; import com.amadeus.ocg.util.dictionary.LinkedHashMap; … com.amadeus.ocg.util.dictionary.LinkedHashMap m = new com.amadeus.ocg.util.dictionary.LinkedHashMap();

Summary The key takeaway from this is to make sure the application works using the target Java version and configuration on the current application server before migrating. Otherwise it is difficult to know if errors are due to the application server change or due to other configuration changes. Further, once again it has proved important to keep the code clean with regard to import statements and variable naming. Most development environments contain tools to help keeping the code clean.9

9 An analogy can be drawn with the spellchecking introduced in word processors, nowadays there is little excuse for outright spelling mistakes.


22

Installation of WebSphere application server Just to get a new application server installed with the standard configuration is seldom a problem. The problems arise as you need to configure the server and in particular when you try to optimize it for performance. The configuration is something necessary to do for functionality whereas the optimization is not immediately required. We therefore focused our efforts on the configuration and the two parts of it; the internal set-up of the server and the set-up of external resources such as databases and web servers.

Software and hardware requirements Before you start you need to investigate the software and hardware requirements for the new application server. You need to make sure that the intended server computer has necessary memory and processor power. If you plan to run the server on your local machine, remember that you will not only run the development environment alone but also office applications such as e-mail and word processing while working on the migration study. If your local machine cannot handle both the IDE and the server at once, having a dedicated server could be an option.

Installation options Even though the installation is seldom a problem there are however a few occasions when you need to make important design decisions at installation time, for example there are often different types of installations of the application server. WebSphere Application Server (WAS) has numerous installation options. These options have to be understood before one can make a proper installation. The problem is that it is often hard to understand the implications of a choice beforehand, especially since the knowledge of the previous application server, the new application server and the application is very limited when you first come to the server installation step in the process. We recommend starting with the standard installation option unless there are reasons not to. After you have started to work on the application you will probably discover changes that need to be made. Since reinstalling the server should not be a large effort the best approach is to get started with the standard configuration. From there on you can change the configuration as needed. The important thing is that the configuration is done in such a way that it can easily be replicated if reinstalling the server. Some application servers have configuration in XML files that can be easily copied (JBoss is an example of such a server). Other application servers require more elaborate efforts to save and restore configurations. In IBM WebSphere Application Server the best way to perform automatic configuration changes is by writing a Jacl [21] script with the configuration parameters and executing it on the server. If you cannot reuse configurations when you reinstall the server you need to spend time up front making sure that you select the correct installation parameters.

Summary The most important thing is to have an easily replicable installation. You can always buy more hardware or have the application server run on a separate computer to solve performance issues during the migration study.


23

In the next section we will talk about learning to configure and work with the new application server once it has been installed.

Learning the WebSphere application server We were faced with two problems; we did not know the old application server and we did not know the new application server. Since we did not expect to be working with the old application server we did not make an effort to learn it. Due to the tight timeframe we focused on learning the new application server despite knowing that knowledge of how the application was configured in the old server would help us greatly. It can be expected that there already are some people in a company who knows the current application server and the configuration of it. This was the case at Amadeus and we tried to leverage their knowledge when there were questions regarding the old configuration.

Learning the WebSphere server To quickly learn the new server we installed it and tried the test applications bundled with it. Most servers come with some test applications; they are a good way to verify that the server is actually running and to quickly get a brief understanding of the server. To further get acquainted with the server we created small test examples which we deployed. However, later in the migration we discovered that our knowledge was not nearly sufficient to work with the new server. We knew nothing about how professionals worked with the server within the context of a large scale J2EE application. The set of functionality that you need when deploying a single EJB application is very different from the set of tools required when you are working with an application the size of Planitgo. Several problems emerged because of our underestimation of the required application server knowledge. Therefore we recommend that anyone who is supposed to undertake a migration do one of two things; either take a course to learn the new application server thoroughly or get extensive experience of it by working with it in an existing development environment. Preferably you should do both. The reason for consulting experts is that to set up a development environment you have to have a good understanding of the server and its possibilities as well as its limitations. If possible, we recommend that an expert of the new server is involved in setting up the new development environment and server configuration together with a senior developer with knowledge of the current environment. A key concern in any software development company is to improve the effectiveness and efficiency of developers and an optimal set-up for the existing developers is needed. The experienced developer’s task is to make sure that the new set-up is as similar to the current as possible while the expert on the new application server has to make sure the configuration is a good one with regard to the new server and its possibilities and limitations.

Alternative migration scenarios We have assumed that a migration effort aims at moving from one software platform to another one, both in development and production. Other possible scenarios are to


24

move only the development environment or only the production environment. The two situations have somewhat different key issues. The key issues when porting the production environment:

• Stability of the server • Capacity and scalability • Hardware requirements

Key issues when porting of development environment:

• Development tools • Build system • Debug tools

The most obvious advantages with using the same server in development and production are:

• Knowledge of only one server is required among developers and testers. • Compatibility issues between different servers are avoided.

There are however a few cases when using different servers in development and production could be an alternative. If the application server in production has too large requirements when it comes to hardware or the test-debug cycle takes too much time it could make sense to have developers using an application server that increases their productivity. The testing could then be performed by a certain group of people testing the application on the production server. The availability of debugging tools could also be a consideration. Typically the development and production environments have different demands on the server but as noted earlier, most often it makes sense to use the same application server for both tasks.

Summary The most important issue is to have professional help in learning the new application server. It will improve the efficiency in the migration process and it will avoid the most common errors. But also, you must consider what the purpose of the migration is; a development environment migration poses other challenges than a production environment migration.

Setting up the development environment One of the most difficult decisions we had to face was how to structure the development environment. In this section we will describe how we went about to select the final configuration.

Evaluation criteria The process of selecting and setting up a development environment is very costly in terms of time and money10 and the potential cost of a malfunctioning environment could be significant. The importance of a productive development environment is stressed by J2EE experts:

10 The license costs of development tools lies in a wide range; from zero to thousands of dollars per license.


25

“Productivity is thus vital to responsive application development. Providing application development teams with standard means to access the services required by multitier applications and standard ways to support a variety of clients can contribute to both responsiveness and flexibility.” [3] During the course of a full scale development environment analysis you would typically evaluate the development environment with respect to three groups and uses (see figure 5) [4]:

• Management. Need to be able to supervise the development. • Developers. The environment needs to be supportive of modeling and coding. • Test engineers. Quality assurance is critical in a large application.

Figure 5 Schematic picture of the three main groups involved in software development and their respective involvement in the development process [4]

As you can see this is an extensive list of tasks/tools that are dependent upon the development environment. Since our primary task was to evaluate whether the application was moveable from one application server to another we will follow a reduced evaluation focusing on the necessary tasks needed to complete the migration. We will start with the current tools that Amadeus had in their development environment and switch to new tools only when needed. For our migration we decided to focus on the most important tools for this project’s success:

• Management Group o Source Code/Configuration Management o Build Management

• Modeling and Coding Group o Component IDE and debugger o JDK

Each of these tools/tasks will be examined in separate sections.


26

Source Code/Configuration Management The source code/configuration management section contains two pieces of analysis; first one on source code management and then one on server configuration. There are several products and methods available for source code control. Amadeus was currently using Microsoft’s Visual Source Safe. Since a requirement from Amadeus was that the Source Safe directory structure was to be preserved we did not have much choice but to keep Visual Source Safe. There are other products on the market and a port to any of those could have been undertaken without a major effort. One problem that we ran into using Visual Source Safe was that the set-up of the directory structure made the path names too long. The long path names created a problem when we wanted to add several new files at once to Visual Source Safe but it could be solved by adding files one at a time. The server configuration is done differently in most application servers. Some use XML files and other use web interfaces. The easiest way to configure the server in WebSphere was through a web interface. We believe that the easiest way should be used when trying to figure out the correct information, but once the configuration has been finalized you should try to find an automatic way of re-establishing the configuration. In WebSphere we had to write a configuration script to mimic the configuration we had set up. This step is less critical to automate than the deployment of the application, but for most large scale applications you need to have an easily replicable configuration.

Build Management The Planitgo Ant build system had to be heavily modified to be able to support other server platforms than WebLogic. Ideally the build system should have been completely re-factored to make it easier to accommodate multiple application servers. Also the use of tools like XDoclet [22] to generate meta data (deployment descriptors, EJB interfaces etc) would greatly have simplified development and increased portability. Deployment is different in each application server. In WebLogic the deployment was automatic through an Ant task. This is an ideal way to do it but unfortunately we did not have an Ant task for WebSphere. We had to construct a special script invoked from Ant that took care of the deployment. The most important aspects of the build system are that it is automated and loosely coupled with the IDE and application server and since Ant allowed for that we kept it with some adjustments for WebSphere.

Component IDE and debugger In this section we will first discuss the selection of the component IDE and then focus on the specific issue of migrating and maintaining deployment descriptors. Arguably the most important choice in this migration was of the component IDE. The IDE is the tool that you spend most time using and the choice also has implications for how you work with deployment descriptors as well as building and deploying the application. Often, if you choose the same supplier of the application server and code editor there are several features that make development easier.


27

To make a thorough evaluation of the IDE choice we designed a set of evaluation criteria for comparing the IDEs. These should by no means be seen as exhaustive but will summarize the most important aspects.

• Documentation (availability and usability) • Purchasing Cost • Time to install and get started • Interoperability with building/deploying • Interoperability with current application server/current source code package • Interoperability with target application server • Requirements in terms of start-up time and memory consumption • Planitgo specifics: Interoperability with current platform

Naturally, the first step was to gather a list of possible code editors to use. We selected four different code editors in a first phase based on previous experiences and the current development environment. The four editors were Emacs, JBuilder, WebSphere Studio Application Developer (WSAD) and Eclipse. Emacs was chosen because it is easy to use and has been the most common tool during our studies. JBuilder was the current code editor of Amadeus. The other two IDEs are different flavors of the same one; WSAD is the commercial product sold by IBM but it is built on Eclipse which is open source. It soon became apparent that Emacs would not be a suitable code editor since the people at Amadeus were used to more visual tools. In the choice between Eclipse and WSAD we quickly realized that for our purposes WSAD was the superior choice, due to the help with deployment descriptors it offered. Since WSAD was built on Eclipse they provided similar functionality in other aspects. The cost of WSAD was not an issue for us since there were trial versions of WSAD available for free during the time of our project. Thus, it came down to a choice between WSAD and JBuilder, a choice between keeping the current infrastructure and trying to build a new infrastructure with tools closely coupled with the new application server. Each of the evaluation points above will be discussed below and will be graded on a three grade scale with the marks good, satisfactory and not satisfactory. The grading will to a large extent be relative to the other IDE and should not, even though the terminology suggests, be taken as absolute judgment of the quality and capabilities of the tools. To compare WSAD and JBuilder on the selected criteria we start with a comparison of the documentation. First there is built in help in both programs with search possibilities with similar features. WSAD also has an extensive list of other tutorials and so called red books published by IBM. They are well written and cover a lot of functionality. With JBuilder we didn’t really have to search for a lot of documentation since the set up of the environment had already been made and there were many people in the office to ask for help. WSAD had one shortcoming in our opinion; there was very little information available online apart from the red books. Being used to find most answers doing a search with Google we struggled to find answers to more difficult questions or problems that included several steps and were not straightforward. We do not know if those problems had been easier to solve with the documentation of JBuilder but our lack of documentation covering these aspects sometimes wasted a lot of time. The provided documentation is sometimes too


28

extensive and there are numerous books that have to be searched to find answers to relatively simple questions. Our judgment is therefore that WSAD has satisfactory documentation. Regarding JBuilder we should really put N/A but for completeness we will grade it satisfactory as well, much due to the available knowledge pool within the department. With regard to cost, both providers performed equally good/bad. Both licenses are costly but there is the possibility to try the software during a limited time period for free. Both of the tools received the grade satisfactory. Since JBuilder was already installed we did not experience any installation problems. We will stick to the grade satisfactory even tough N/A would be appropriate. It was troublesome to download all the WSAD installation files due to a slow internet connection and a complicated web interface but the installation procedure in itself worked well. When we talk about build and deploy tools we talk mainly about Ant and vendor specific tools used to deploy applications. Since all parts of the build and deployment will be taken care of by Ant, either directly or through scripts run by Ant, the important question is which environment is better at working with Ant scripts. In JBuilder Amadeus had already constructed a good structure with the Ant script and it could be run directly from the IDE. WSAD also supported Ant and hence it would take only minor efforts to set it up in WSAD. Since both JBuilder and WSAD include support for Ant scripts the interoperability of both is judged to be satisfactory. Regarding the interoperability with the current environment it is hardly a surprise that JBuilder is regarded as the best. You can debug the code form JBuilder and everything that you need is set up in JBuilder. In WSAD on the other hand, a large effort is needed to import the application in its current form. We did not attempt this import since we considered it to be too time consuming. With the target environment the roles are interchanged to a certain extent. However, JBuilder still has all the necessary functionality except from the debugging. Due to unknown reasons it was not possible to fully debug the application using JBuilder when the application was running on WAS. The system requirements in terms of operating systems are similar. Also the processor requirements are the same. The memory requirements are however different, WSAD requires almost double the memory. The memory requirement is not a limitation since memory, both RAM and hard disk is inexpensive. The problems occur mostly since the larger memory requirements make the start-up slower. This is particularly true when it comes to starting the editor. We therefore found JBuilder to be better performing than WSAD. The last point concerning the interoperability with Planitgo concerns how the editor will handle specific techniques used by Planitgo. Since JBuilder already had everything set up it obviously had a huge advantage. Even though WSAD has some of the required functionality we judged it too difficult and time consuming to set everything up in WSAD. Therefore we give JBuilder a higher grade.


29

Table 1 Summary of the evaluation of JBuilder and WSAD.

JBuilder WSAD Documentation Satisfactory Satisfactory Cost Satisfactory Satisfactory Installation Satisfactory Satisfactory Interoperability with build/deploy tools Satisfactory Satisfactory Interoperability with current environment Good Not satisfactory Interoperability with target environment Satisfactory Good System requirements Satisfactory Not satisfactory Interoperability with the application (Planitgo) Good Satisfactory Overall we see that JBuilder scores higher on all dimensions but the interoperability with the future environment (see table 1) and we therefore decided to go with JBuilder considering the information we had to date. When we chose to go with JBuilder we did not have all the information that we have now and probably the decision would have been in favor of WSAD instead if we had known more. The problem occurred in working with the deployment descriptors and we will now discuss the issue. The deployment descriptors provide necessary information about the code. For example they include the JNDI names of J2EE components and references to other J2EE components. The first cause of problems was that naming wasn’t implemented correctly in Planitgo as described above. Once we had implemented a correct naming of all the components it was difficult to migrate the actual deployment descriptors. WebLogic descriptors were easily edited by hand in an XML format. The XML format was clearly documented and there were no problems understanding what was actually said in the deployment descriptors. The same thing applies to deployment descriptors in many other application servers such as JBoss. However, with WebSphere we ran into difficulties. The problems were mainly due to the fact that the files were supposed to be written in XMI format, a barely readable format in a text editor. Further, there was no documentation explaining the format of the XMI deployment descriptors. We had to resort to the final option; reverse engineering all the deployment descriptors by creating new descriptors in WSAD and seeing what the outcome was. We did not anticipate much work when we decided to go ahead with JBuilder as the main code editor. Not providing adequate documentation and forcing users to have WSAD is clearly a big drawback of WebSphere. Below you can find a simple deployment descriptor from JBoss.

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE jboss PUBLIC "-//JBoss//DTD JBOSS 3.2//EN“ "http://www.jboss.org/j2ee/dtd/jboss_3_2.dtd"> <jboss> <enterprise-beans> <session> <ejb-name>nativeverbhandler</ejb-name> <jndi-name>com/amadeus/ocg/util/api/nativeverbhandler</jndi-name> </session>


30

</enterprise-beans> </jboss>

The WebSphere specific deployment descriptors are ibm-ejb-jar-bnd.xml and ibm-ejb-jar-ext.xml, here we present the latter because the first one does not contain any meaningful information for this and most other usages.

<?xml version="1.0" encoding="UTF-8"?> <ejbbnd:EJBJarBinding xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:ejbbnd="ejbbnd.xmi" xmlns:commonbnd="commonbnd.xmi" xmlns:ejb="ejb.xmi" xmlns:common="common.xmi" xmi:id="EJBJarBinding_1"> <ejbJar href="META-INF/ejb-jar.xml#ejb-jar_ID"/> <ejbBindings xmi:id="Session_1_Bnd" jndiName="com/amadeus/ocg/util/api/nativeverbhandler"> <enterpriseBean xmi:type="ejb:Session" href="META-INF/ejb-jar.xml#Session_1"/> </ejbBindings> </ejbbnd:EJBJarBinding>

Clearly the task of migrating the deployment descriptors was difficult and for anyone who will undertake a migration we recommend that you get very familiar with the application server and the IDE candidates before you make the selection. We were too influenced by the fact that JBuilder already had been set up.

JDK As described earlier we decided to use JDK 1.4 due to compatibility issues with JBoss.

Obvious migration problems By learning the application server thoroughly as suggested above finding obvious migration problems will be greatly simplified. There are several obvious migration problems that you can expect to run into. By knowing the application server you will be able to quickly solve most of these. The most common problems are:

• Application server specific code • Bad code solutions • J2EE Client Connectivity • Deploying • Packaging of optional JAR libraries

We will review these problems one at a time below.

Application server specific code Although application server specific code may seem like a bad design practice in terms of WORA, applications in the real world are prone to contain such code. Due to the fact that the Java specification is constantly evolving, most application server vendors include features that greatly simplify development but have not yet been incorporated as part of J2EE. It is important to locate these classes to estimate the amount of work required to fix it. All the application server specific code may not


31

have to be changed depending on the importance and later a framework will be given for how to decide what to do with such code. We will also give some hints on how you can actually re-write the existing code by using well-known design patterns. These patterns should also be used when you want to take advantage of new application server specific features to make sure that application server dependent code can easily be located and changed. An easy way to find most of the application server specific code is to go through all classes and look for import statements of non-core Java classes. A simple Perl program could solve the task quickly. Going through the import statements below we would find that there could be two possible sources of non-core classes; those in com.amadeus.flight.* and in weblogic.*. By listing the classes which actually contain import statements to non-core Java classes as a first step would exclude many classes with only Java imports. Also, some import statements which are known not to cause any problems such as com.amadeus.flight.* could also be disregarded from the selection and thereby limit the number of classes that actually has to be examined further. After a minimal list of classes using non-core Java classes has been generated from an automatic Perl script or similar it has to be examined manually to see which classes actually use non-core classes which could pose a problem.

import java.io.*; import java.util.List; import com.amadeus.flight.*; import weblogic.*;

In the code example above it is evident that the com.amadeus.flight package as well as the weblogic package are not part of standard Java classes and need to be examined further. Once you have identified the classes that are not part of standard Java you have to decide what to do. We have identified four ways to handle the problem, where the first solution typically is the least time-consuming and the last one is the most time-consuming:

• Do nothing, i.e. comment or remove the code. • Replace the code with an abstract class or an interface where the functionality

can be implemented later. • Re-write using a similar feature from the new application server or a part of

standard Java. If using a feature from the new application server it should be done in a way that enforces loose coupling with the application server.

• Re-write completely, i.e. implement the functionality yourself in an application server independent way.

The first approach could be used if the code is no longer used and is not important for the application. We found some examples of this. Besides helping us proceed with the migration, removing the old code increased the code quality. The second approach should be taken in all other cases when the code still is useful in some way. The typical way to do it is to create an interface or an abstract class which defines the functionality required and then, depending on the need, continue with options three or four to implement that class. If there is standard Java functionality


32

that you can use, the Java class will serve as the interface or abstract class. Many times option two should be taken as a first step and in order of importance the functionality can be implemented as described in option three and four. The third option takes advantage of the second option and then requires that you implement the functionality using server specific code from the new application server. The fourth option is the same as option three but you re-write the functionality from scratch. The fourth option is often the most time-consuming choice but it has the advantage of making the code truly vendor-independent. However, this should not be necessary in most of the cases and should be avoided because it introduces new code which will have to be quality assured. Which option to choose is not easy to decide but the following guidelines should be of some help. Option one should clearly be chosen if the code is obsolete. In all other cases option two should be a good starting point. By putting in an abstract class you do not have to change any of the code. You only have to make an empty implementation of that class and put it in instead of the vendor specific class. As we see it, there is a definite advantage of doing the migration this way since you can safely test your newly implemented class separately to verify that it behaves as desired. Since you have not changed the code of the original application you do not need to test it again. If instead, you would have implemented everything in the existing application you would have needed to re-test it extensively. Even if you plan to use standard Java classes to substitute the vendor specific functionality it could be a good practice to separate the old code from the new in this way. So, option two should be a starting step if option one is not chosen. The choice between option three and four depends on the amount of labor needed in the two cases. When you have the choice to use standard Java instead of vendor specific classes you should in most cases go with the standard Java. When that is not possible you have to estimate the time taken to implement everything from scratch and the time taken to use vendor specific classes. In most cases it would take too much time to implement anything from scratch and in such cases third-party solutions could be used. Typical problems that we experienced when you need to decide between these options are:

• Logging • Tuning of the server • Monitoring and management of the server

This is due to the fact that many providers have implemented their own solutions with both necessary and unnecessary features. We will present an example how we solved the logging solution in Planitgo using the Template Design Pattern [1]. Before the logging class was implemented with only one class (see figure 6). After we redesigned it we introduced an interface and also an abstract class to hold common functionality as suggested by the Template Design Pattern (see figure 7). The Template Design Pattern helps minimizing the code since common functionality is implemented in the Abstract class. Since we had limited time we could not fully


33

implement the previous functionality and had to settle for just printing the log messages in the server log file. But with this re-factoring approach, you can more easily move the application to a new application server and then during later stages add the required functionality.

Poorly designed or incorrect code There will probably be parts of the code that do not follow good design principles, or worse, do not work as intended. Our suggestion here is to neglect those parts of the code until the application has been ported. The argument is that we want to minimize the number of changes to the code before we move it to make sure our “improvements” do not create other problems. Alternatively, you could first change the code and re-validate that it works as intended on the old application server. But with that approach you still run the risk of creating bugs and you have to work a lot with the old application server, hence having to learn two application servers. Also, the part of the code that you change could, at worst, be obsolete when the application is ported since the new application server might have different modules to perform tasks. One may also argue that fixing bugs and re-factoring the application is not a part of the migration effort and should hence be handled by a different initiative. We strongly suggest that you leave these problems for someone else and focus on the core issues of the migration although it might be tempting to get engaged.

Deployment and deployment units There are three types of deployment units available in J2EE according to the specification:

• Stand-alone J2EE modules. • J2EE applications, consisting of one or more J2EE

modules. A J2EE application must include one J2EE application deployment descriptor.

• Class libraries packaged as .jar files according to the Extension Mechanism Architecture. These class libraries then become installed optional packages [26].

A J2EE application is packaged in an .ear file and a stand-alone J2EE module is packaged in a .jar, .war or .rar file. We touched upon it earlier, that different application servers have different ways of deploying applications and we will now expand our discussion on deploying applications.

Deploying in WebLogic The deployment in WebLogic was automated using an Ant task which copied an exploded EAR file to a specific application server directory. Exploded EAR files are

Figure 6 The old logging.

Figure 7 The new logging.


34

not listed in the standard as a valid deployment unit and hence we had to change it to a normal EAR file.

Deploying in WebSphere The specification does not say anything about exploded EAR files and hence they are non-standard. We therefore compressed the exploded file using an Ant task. Regarding the mechanism to deploy, WebSphere does not provide a directory to which you can copy an application as WebLogic does. Instead there are two ways to deploy a file in WebSphere; either you can write a script that will provide the application server with the necessary information to go with the file or you can use a web interface to provide the necessary information. Since the desire in any development environment is to automate as much as possible we chose to use the script-based method. This meant that we made a jacl script which provided the necessary deployment configuration to the application server.

Ongoing standardization There is currently an ongoing standardizing of the deployment process but that was not available to us at the time of the project: “The Java 2 Platform, Enterprise Edition (J2EE) Deployment API Specification (JSR-88) defines standard APIs to enable a deployment of J2EE components and applications. It is intended to enable the development of platform-independent deployment tools.” [24]

Packaging of optional JAR libraries J2EE applications often use functionality beyond that of standard J2EE. To accommodate the usage of optional JAR libraries, the J2EE specification supports importing extra functionality to an application. This functionality is provided in JAR file libraries created by the application provider or obtained from a third party. The problem with the packaging is how to include the JAR file libraries in a way that is sound both from a programmer’s perspective and the standard’s perspective. The optimal solution will be a completely portable application that includes JAR file libraries in a way that is easy to maintain. Naturally it will be a compromise between different factors, ultimately depending on the specifics of the situation. Common scenarios when you want to import extra functionality from a JAR file library are:

• The application uses the Struts Model-View-Controller framework. • The application uses the JavaServer Pages Standard Tag library and hence has

to include jstl.jar. • The application uses a logging utility such as log4j that is packaged as a

separate jar. We will go through different scenarios and suggest ways to deal with the problems [26].

Mechanisms to include optional packages There are three different options to include optional libraries in a vendor independent way.

• Use the WEB-INF/lib directory. • Bundle the optional libraries with the application (i.e. the EAR file). • Install the libraries in the Java Runtime Environment.

What makes the situation difficult is that most application server provides have other ways to allow developers to include optional libraries. To our knowledge, many times


35

developers are content once they can access the optional library and do not take the time to make sure that they actually packaged the application in accordance with good design principles. There are two problems when choosing between the above options. First you have to decide where the library JAR file should be placed and secondly the application has to be able to find the classes in the JAR file. We will review the options one at a time. The WEB-INF/lib directory option only works for web modules (WAR files). It makes the JAR file available to web applications or web modules within the same WAR. The obvious drawbacks are that the JAR is only available to the WAR in which it is packaged and it is not usable for other modules such as EJB modules. If you instead bundle the optional libraries with the EAR file they are also available to EJB modules. To reference a library from the EAR file you use the Class-Path attribute in the manifest file of the module containing the referencing class. This implies that all files which are JAR files (EAR, WAR and RAR files) can reference the library. The last option is to install the package in the lib/ext directory of the JRE. Such a JAR can be accessed from all JAR files within the same JRE. To access the classes in the library JAR you need to use the Extension-List attribute in the manifest file.

Tools to verify the packaging Sun provides a series of tools called the Java Application Verification Kit (AVK) for the Enterprise that can test an application for correct usage of J2EE APIs and maintain portability across J2EE compatible application servers [17]. Among other things this tool tests that the packaging of the application follows the standards. The tool can be easily run using the simple Ant [20] script provided in appendix B3.

Recommendations When it comes to choosing between the different options the general guideline is to choose the most “local” option first. In order of preference the list would be:

1. WEB-INF/lib directory. 2. Bundled with the application. 3. Installed in the JRE.

The guideline follows the same principles as when you want to declare a variable. You want to limit the scope as much as possible. However, there are some more complicated considerations here since we do not want to duplicate the JAR files since that will cause maintenance problems. Therefore, the “most local first” guidance is only applicable while there are no maintainability issues.

WebLogic packaging The packaging in WebLogic was done in one big exploded EAR file. This EAR contained several optional JAR libraries. Since the Planitgo application was supposed to run on dedicated servers there would be no other applications running at the same servers. Hence, the libraries could be placed both within the EAR file and in the JRE. Following the local first principle, the latter was the correct packaging. Keeping everything within the EAR file made the application easier to install and overview.

WebSphere packaging We had to add some references in some manifest files to be able to access the optional JARs within the EAR. There were only a few minor changes and it did not involve


36

any further important design decisions. Once we had understood how the specification suggested to deal with the problem it did not take very long to manually complete the changes.

Analysis of J2EE services We will analyze the J2EE services and go though problems related to J2EE services in this chapter. Most of our problems were related to EJBs, including lookup of EJBs through the JNDI system.

Java Naming and Directory Interface Since JNDI is implemented differently in each application server there is some specific configuration information to be specified. In Planitgo this information was hard coded which gave problems since we would have to change the hard coded properties in all places that used JNDI. The two main problem areas were the use of the vendor specific t3 protocol and the use of hard coded server URLs and WebLogic InitialContextFactory names. We will examine each of these problems one at a time.

The use of the t3 protocol The t3 protocol is a protocol just like FTP or HTTP that specifies how to talk to an application server. Since the t3 protocol used by WebLogic is not a standard protocol it should be avoided. The migration to the standard IIOP protocol is fairly easy and involves two steps:

• Implement a correct usage of PortableRemoteObject narrow when typecasting remote interfaces (explained in detail under the Enterprise JavaBeans chapter below)

• Change the JNDI properties to use the IIOP protocol by changing the protocol in the URL.

Hard coded URLs and InitialContextFactory names A URL is required to know where to connect. Unfortunately this was hard coded in Planitgo and therefore required us to change it to a dynamic name in all places where a context was looked up. The purpose of the InitialContextFactory is to return the appropriate InitialContext according to the factory pattern [1]. This property was also hard coded and had to be changed to the appropriate class name.

Recommendation Local environment information should be provided by command parameters or system environment arguments. This is due to the fact that the local environment is not available in J2EE clients. There are essentially three ways to pass environment information; to use the –D command line option to send parameters, extract properties from the operating system or read properties from application specific configuration files. When you decide which approach to use, think about the number of parameters. Naturally a large scale application cannot use the command line solution and should preferably use the application specific configuration file. The Planitgo application had such a configuration file but it did not contain all the necessary parameters since some were still hard-coded. We solved this by extracting the information from the code and put it in the configuration file. Before we changed anything the code looked as follows:


37

Properties h = new Properties(); h.put(Context.INITIAL_CONTEXT_FACTORY, “weblogic.jndi.WLInitialContextFactory”); h.put(Context.PROVIDER_URL, “t3://localhost:7001”); InitialContext ic = new InitialContext(h);

After we changed to the jndi.properties file we had the following code:

InitialContext ic = new InitialContext();

The new jndi.properties file provided the configuration information and looked like this:

java.naming.factory.initial=com.ibm.websphere.naming.WsnInitialContextFactory java.naming.provider.url=iiop://localhost:2809

Clearly the latter is a more elegant solution than the former one and we highly recommend using this set-up to provide JNDI configuration information.

Enterprise Java Beans EJB references There are several ways to look up local EJBs in most application servers, but only one way that is approved by the standard. As an example we will look at the SiteContext bean in Planitgo. The code is shown below:

ErrorsHome errorHome = (ErrorsHome) com.amadeus.ocg.util.naming.Context.lookupLocal("business/sitecontext/errors/Errors"); public static Object lookupLocal(String name) throws NamingException { javax.naming.Context ic = com.amadeus.ocg.util.naming.Context.getInitialContext(); name = "java:comp/env/" + s_defaultContextPath + "/" + name; return ic.lookup(name); }

There were two main problems with this approach. First there was no ejb reference to the local bean which was used in the SiteContext bean. Secondly the ejb-name sitecontext.home did not follow design principles for how to name ejbs. Since the latter problem was not critical and would be best categorized as a bad code solution we did not change it. Below we present the ejb-jar.xml file for the SiteContext entity bean as it looked before the migration.

<ejb-jar id="ejb-jar_ID"> <enterprise-beans> <entity id="Entity_1"> <ejb-name>sitecontext.home</ejb-name> <home>com.amadeus.ocg.framework.sitecontext.SiteContextHome</home> <remote>com.amadeus.ocg.framework.sitecontext.SiteContext</remote>


38

<ejb-class>com.amadeus.ocg.framework.sitecontext.SiteContextBean</ejb-class> <persistence-type>Bean</persistence-type> <prim-key-class>com.amadeus.ocg.framework.sitecontext.SiteLangPK</prim-key-class> <reentrant>False</reentrant> </entity> </enterprise-beans> </ejb-jar>

In the SiteContext bean there was a lookup of a local EJB called Errors as shown above. However, since there was no local ejb reference in the deployment descriptor we could not find the bean in the JNDI namespace when we tried to look it up in WebSphere. Weblogic had introduced some extra functionality so that the name was placed in the local namespace even though it didn’t have to be placed there according to the Java standard. To solve the problem we introduced a local EJB reference in the ejb-jar.xml file to solve the reference problem. This problem occurred with all the local ejb references that were used and hence resulted in many but uncomplicated changes. Below is the correct ejb-jar.xml file that we developed.

<ejb-jar id="ejb-jar_ID"> <enterprise-beans> <entity id="Entity_1"> <ejb-name>sitecontext.home</ejb-name> <home>com.amadeus.ocg.framework.sitecontext.SiteContextHome</home> <remote>com.amadeus.ocg.framework.sitecontext.SiteContext</remote> <ejb-class>com.amadeus.ocg.framework.sitecontext.SiteContextBean</ejb-class> <persistence-type>Bean</persistence-type> <prim-key-class>com.amadeus.ocg.framework.sitecontext.SiteLangPK</prim-key-class> <reentrant>False</reentrant> <ejb-local-ref id="EJBLocalRef_001"> <ejb-ref-name>com/amadeus/ocg/standard/business/sitecontext/errors/Errors</ejb-ref-name> <ejb-ref-type>Entity</ejb-ref-type> <local-home>com.amadeus.ocg.framework.sitecontext.errors.ErrorsHome</local-home> <local>com.amadeus.ocg.framework.sitecontext.errors.Errors</local> </ejb-local-ref> </entity> </enterprise-beans> </ejb-jar>

Typecasting of remote interfaces Client applications which access remote enterprise beans need to typecast the objects to the correct type. Here is a cause of problems since application servers use different protocols to communicate between the application server and the client. Although


39

RMI-IIOP is the suggested protocol to use, some servers, including Weblogic use the t3 protocol. The t3 protocol does not require typecasting11 and hence code written on application servers using the t3 protocol could potentially lack the correct typecasting. In the Planitgo application there were many different examples of where the typecasting was not correctly performed.

Java Management Extensions Many application servers have included features to monitor the status of the application server such as the current load and memory usage. Since the release of the J2EE Management Model [27], it should be the preferred solution to request information from the server. We realize that the difficulty and time required to rewrite this part of an application depends heavily on how much code that needs to be fixed. We suggest that only mission critical functionality should be fixed before the migration, the rest can be done afterwards. The argument is as before, the fewer changes you make, the fewer bugs you will introduce.

J2EE client connectivity The authors of Designing Enterprise Applications state that application clients are not completely specified by the standard: “However, the exact behavior for installing EJB clients is not completely specified for the J2EE platform, so the client-side container and deployment mechanisms for EJB clients vary slightly from application server to application server.” [3] If we dig deep into the J2EE 1.4 specification we find that it defines three types of containers:

• “Components that are deployed, managed, and executed on a J2EE server. These components include web components and Enterprise JavaBeans components. See the separate specifications for these components.

• Components that are deployed and managed on a J2EE server, but are loaded to and executed on a client machine. These components include web resources such as HTML pages and applets embedded in HTML pages.

• Components whose deployment and management is not completely defined by this specification. Application Clients fall into this category. Future versions of this specification may more fully define deployment and management of Application Clients.” [26]

The last point concerns the J2EE application clients and as you can see the J2EE standards do not fully cover how Application Clients should be implemented [26]. The implication is that application server providers have solved the issues in different ways and that it is hard to make something that is truly portable. We will list a few common issues when it comes to client connectivity and suggest ways to solve the problems.

JVM First we had some problems with the choice of Java Virtual Machine (JVM). When running on WebLogic the application used the Sun JVM, the same as the client.

11 The t3 protocol does not require the use of the PortableRemoteObject.narrow() method.


40

However, when the application was migrated to WebSphere the application was instead using the IBM JVM at the server. This imposed a problem since we were not able to run the client using the Sun JVM anymore. Hence it is important that you verify which vendors’ JVMs can be used on the server and the client beforehand.

Lightweight application clients When you want to design a lightweight application client there is a trade-off between making the client portable and lightweight. Typically, a portable client needs more libraries than a vendor specific client. WebLogic provides a very “thin” client model but that will also make the client highly dependent on WebLogic provided functionality. The recommended approach is to first migrate the client to a standard application client that includes everything stated by the standards. Then, if necessary, you can begin to optimize the client. As an example you should provide EJB interfaces and stubs. In WebLogic the use of the t3 protocol made it possible to dynamically load stubs during runtime. Since all application servers do not support that it should be avoided. However, in the future we are likely to see improvement in this area through new mechanisms. There are two ways to provide the EJB interfaces and the stubs; either by adding them to the client JAR or by placing them in a new jar that is added to the classpath. The second approach is slightly better since it is more flexible. Several application servers also provide specific commands which create such JARs.

JDBC data access API We did not experience any big difficulties with the JDBC API. Since we did not change the database we only needed to find the MS SQL Server JDBC API for the new application server and make sure it was included in the class path. However, we would expect a lot of problems to surface if they tried to change the underlying database since the EJBs use bean managed persistence and hence can contain vendor specific SQL code to handle the persistence.

JavaServer Pages and Java Servlets Errors in JSP pages required a large amount of time to fix during our migration. The JSP pages had been automatically generated by a program which Amadeus had developed to automatically generate a website with modifications. For various reasons we did not have access to the program that generated all JSP pages and hence had to correct the errors in the generated pages in all places and provide our feedback to the team working with the generation program. The three most common errors were:

• JSP tags were not ended correctly. • XML syntax and ordinary syntax mixed in JSP pages. • Variable definitions were duplicated in JSP pages.

The reason why these problems surfaced now was that the previous servlet engine did not strictly enforce those standards and hence the problem was not detected.

JPS tags not ended correctly Many JSP tags had for some reason been written as below being ended by “%>” instead of the correct “/>”. Incorrect JSP tag:

<pltk:value key="/BOOL_NEW_PROFILE" display="false" id="newUser" %> Correct JSP tag:


41

<pltk:value key="/BOOL_NEW_PROFILE" display="false" id="newUser" />

XML syntax mixed with JSP syntax There are two ways to write tags in JSP pages, either through the use of the XML syntax or through the use of ordinary JPS tags. But as we explained earlier you are not allowed to mix the two. There were several instances where Planitgo JSPs used both ways in the same JSP. Incorrect example:

<%@ include file="page.jsi" @%> <jsp:scriptlet> // CABIN COLOR strings String strColorFirst = "#800080 "; String strColorBusiness = "#FF8000 "; String strColorEconomy = "#516916 "; String strColorEcoRestricted = "#004080"; String strCabinColor = ""; </jsp:scriptlet> <jsp:directive.include file="inc_service.jsi" />

Correct example: <%@ include file="page.jsi" %> <% // CABIN COLOR strings String strColorFirst = "#800080 "; String strColorBusiness = "#FF8000 "; String strColorEconomy = "#516916 "; String strColorEcoRestricted = "#004080"; String strCabinColor = ""; %> <%@ include file="inc_service.jsi" %>

Variable definitions duplicated in JSP pages Another problem with the generated JSP pages was that when we compiled them on the application server several of them had repeated variable names. For example a variable with same name could be defined multiple times within the same scope in a JSP file. The source for this problem was twofold; first the JSP pages used include directives which inserted other files into the JSP page. Due to the fact that it was virtually impossible to see which variables were defined in other pages or include directives, mismatches were introduced. The second reason for the problem was that the JSP pages were generated by an application, this application sometimes included the same definitions in multiple places. On the old application server this set-up apparently didn’t cause any problems but in the new environment this was rightfully not accepted.

Recommendation We identified three things they should do to improve the situation:

1. Create taglibs for all functionality that is repeated. 2. Reconsider having all code generated dynamically. 3. Consider using a web application framework.

What they should have done, as a first step, was to create more custom tags to handle required functionality. By creating custom tags the duplicate variable definitions would have been avoided. Creating taglibs would also solve the previous problem of


42

the mixing of ordinary JSP syntax and XML syntax since on many occasions the problem was that included code had a different syntax than the JSP page itself. Secondly and more long-term, we didn’t really see the absolute need to have the code generated, at least not that much of the code. After all, JSPs are supposed to dynamically create code. The main reason for the generation application seems to have been historic. Since previous versions of HTML were not as easily customizable they needed to change the look-and-feel through generating the JSPs. Today much of the same functionality can be achieved by using different style sheets. Moving away from the generated JSPs would also greatly enhance the readability of the code making it possible for developers with special skills in GUI design to work with the JSPs and developers with programming skills to work with Java code development. The third suggestion would require a great deal of redesign. A web application framework would provide all functionality which is not found in the J2EE specification but yet required in most web applications. Examples of web application frameworks are Apache Struts and JavaServer Faces. As we described earlier, Planitgo was already using a Model 2 framework but we would highly suggest that as a long-term initiative they should consider moving to a standard web application framework instead of a proprietary solution.12

Migration of the application Contrary to our a priori expectations, the migration of the actual application code proved to be fairly easy. As mentioned above we started by migrating the back-end and then moved on to the front-end. As expected, both due to the number of technologies involved and the number of lines of code, the back-end was much easier to migrate than the front-end. With portability in mind a good idea is to work very actively around the packaging of the application. There are basically three ways of looking at packaging of applications:

• Each enterprise bean is packaged in a separate module • All enterprise beans are packaged in one module • Related enterprise beans are packed in one module

Obviously the first choice gives most options, but it is also very time consuming since you have to work extensively with providing references between the modules. The second option is the easiest one but on the other hand it makes code in the application difficult to reuse. The third option can be thought of as the middle road and is often the best option. That being said it is difficult to always distinguish which objects that are truly related and should be packaged together. This also depends on the size of the application since with a small application it might be possible to put everything in just one module. A good rule of thumb is to start with a bean central to the application’s functionality and then add beans which are required for that bean to do any meaningful work and group it all as one unit.

12 In a separate project, Amadeus was actually investigating the Apache Struts framework to understand the difficulty of adopting it instead of their proprietary framework.


43

Migration back to the original server Migrating the application back to the old application server will ensure that it is at least complying with two application servers.

Chapter 5 Conclusion: How to perform a migration

44

5 Conclusion: How to perform a migration Drawing upon our experiences from the previous chapters we will now summarize the most important aspects of a large scale J2EE migration and also provide insights on where most problems can be expected.

Understand the application A well structured application should be fairly easy to understand. Given that there should be developers to ask about the design decisions we believe that for most applications getting a basic understanding of the application is an easy step. The key issue when learning the application is to understand if there is any way to divide the effort into smaller pieces by migrating only part of the application as a first step.

Verify source code on the current server There should be a test environment in place and a systematic way to verify functionality. Verification of the source code on the current server should also be a simple step since the application should work when the migration effort is initiated. It is very important to make sure that the application works on the current application server before migrating to a new server to isolate the source of problems to the migration.

Installation of the new application server Installation of a new application server should be relatively easy. The main problems are often related to configuring the server in general and performance tuning. Since we didn’t perform any performance tuning we had few problems. With regard to the configuration it is important to have an easily replicable configuration.

Learn the new application server Learning the new application server was one of the most time consuming steps. We highly recommend that you either consult an expert on the new application server or take an organized course. By knowing the new application server well you will save a lot of time later. The time savings are both from a good set-up which speeds up the development and from avoiding the most common errors.

Development environment We went through an extensive evaluation before selecting the development environment. With hindsight we did underestimate the importance of having a development environment that is productive with the new application server. We decided to keep most of the current tools because a shift was estimated to be very time consuming. However, once more it was proven that most investments that facilitate the development process are good investments. We hence recommend that

Chapter 5 Conclusion: How to perform a migration

45

experts on the tools in question are consulted before deciding which solution to use. Also, the set-up of the environment should be done with expert help, both from the current and the new tools.

Obvious migration problems The most alarming point here is the application server specific code. Depending on the amount of proprietary functionality used and its importance for the application finding and fixing the obvious migration problems could be a difficult and time-consuming step. We did not experience that many problems but we didn’t migrate the full code. The difficulty fixing the obvious problems could be estimated by examining the code for non-core Java imports.

J2EE problems Most of the J2EE problems could and should have been avoided since they were the results of deviations from the J2EE standards. There are two good ways to enforce that the application follows standards and increase the productivity.

• A code generation tool such as XDoclet should be used for generating as much of the code as possible.

• The application should be tested on multiple application servers to make sure that flaws in the application server do not result in the usage non-standard J2EE solutions.

Migration of the application Once all the other issues have been resolved the migration of the application should be painless. We found the pure Java code to be truly platform independent but the tools necessary for that were sometimes difficult and time consuming to use.

Summary We were surprised how portable the Planitgo application was at the code level. Very few changes were required to port the actual Java code. What proved to be more difficult however, was the setup of the application server and the development environment. We believe this was due to both our limited knowledge about the application server and development tools but also the inherent complexity of configuring a productive development environment. Hence the main focus of any migration effort should be to learn the new application server and development tools thoroughly. In fact we believe that the development environment is a far more important choice than the choice of application server.

Chapter 6 Conclusion: A comparison of WebSphere and JBoss

46

6 Conclusion: A comparison of WebSphere and JBoss We will now provide a comparison between the WebSphere application server and the JBoss application server. For more information about the migration from Weblogic to JBoss please refer to the master’s thesis Migration of a J2EE application from Weblogic to JBoss. We will by no means provide a complete comparison of the two application servers but it will give some guidance on what characteristics each of the two has. We found the main differences between the application servers to be how rigorously they adhered to standards and how easy they were to work with. Not surprisingly, there was an inverse relationship between the two aspects.

Adherence to standards The application server that by far follows standards the best is WebSphere, on second place comes WebLogic and worst of all is JBoss. With that being said the adherence to standards does not mean that JBoss does not implement everything that the standards specify, on the contrary JBoss provides much more functionality than the standards specify. You could argue that this is better since it gives the developers more choices. We argue that only in certain circumstances are the extended options useful. An extra feature which induces developers to adopt a poor design decision that is not described in the standard is not to be considered a good feature. Unfortunately, many of the extra features of JBoss are counter-productive.

Ease to work with The easiest application server to work with was JBoss. JBoss was easier due to the fact that the configuration was simple to make through the XML files. Furthermore, installation and system requirements were much lower with JBoss than the other servers. Also the interoperability with other tools and servers was better with JBoss.

Conclusion After the migration effort, we realized that even though an application server is easy to work with because it allows you to take shortcuts which aren’t defined by the standards, you can have a tough time if you ever considering migrating to a different application server. In conclusion we believe that JBoss is a good environment when the developers are skilled and the development team is smaller (see table 2 for a summary). For larger environments WebSphere and WebLogic is more on par with JBoss. However, that being said, we do not think that there necessarily has to be a contradiction between being easy to work with and to follow standards. To merge the configuration and deploy system of JBoss with the strict adherence to standards in WebSphere should be doable and something for application server providers to strive for.

Chapter 6 Conclusion: A comparison of WebSphere and JBoss

47

Table 2 Summary of WebLogic, WebSphere and JBoss performance.

WebLogic JBoss WebSphere

Adherence to standards Ok Poor Good Ease to work with Ok Good Poor

Chapter 7 Future research

48

7 Future research We see one interesting subject for future research, to extend the migration from a single server set-up to more advanced set-ups including clustering and load-balancing. Since all J2EE applications with large traffic require a clustered solution with several nodes a complete migration must include a clustering solution. We started setting up a clustered environment in JBoss but due to time constraints and the difficulty of getting access to enough computers we did not fully test and benchmark our setup. Our preliminary testing showed promising results for JBoss compared to WebLogic.

Chapter 8 – References

49

References Books [1] GAMMA E., HELM R., JOHNSON R., VLISSIDES J. 1995. Design Patterns – Elements of Reusable Object-Oriented Software. Addison-Wesley. ISBN 0-201-63361-2 [2] POOLEY R., STEVENS P. 1998. Using UML, Software engineering with objects and components. Addison-Wesley. ISBN 0-201-36067-5 [3] SINGH I., STEARNS B., JOHNSON M., AND THE ENTERPRISE TEAM. 2002. Designing Enterprise Applications with the J2EETM Platform, Second Edition. Addison-Wesley. ISBN 0-201-78790-3

Articles [4] ODROWSKI J. 2004. A Process for Evaluating and Selecting a Development Environment. 26th International Conference on Software Engineering. http://www.lsi.upc.edu/events/mpec/mpec04/

Master’s thesis [5] TJERNLUND E. 2006. Migration of a large scale Java 2 Enterprise Edition application from BEA WebLogic to JBoss. Master’s thesis, Royal Institute of Technology, Stockholm, Sweden.

Online [6] AMADEUS S.A. 2005. Amadeus. http://www.amadeus.com [7] AMADEUS S.A. 2005. Amadeus e-Retail engine (Planitgo). http://www.amadeus.com/x7746 [8] AMERICAN GO ASSOCIATION. 2005. American Go Association. http://www.usgo.org/ [9] CARNEGIE MELLON UNIVERSITY. 2005. Software Technology Roadmap. http://www.sei.cmu.edu/str/ [10] FOWLER, M. 2005. Data Transfer Object Pattern. http://www.martinfowler.com/eaaCatalog/dataTransferObject.html [11] GAWDE K., POWER L., WANG H., SERRANO TIMONET M., MOORE B., BEATON W. 2002. Migrating WebLogic Applications to WebSphere Advanced Edition V4. http://www.redbooks.ibm.com/ [12] GERONIMO. 2005. Apache Geronimo. http://geronimo.apache.org/ [13] JAVAWORLD. 1999. Understanding JavaServer Pages Model 2 Architecture. http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-jspmvc.html [14] JBOSS. 2005. JBoss Application Server. http://www.jboss.com/ [15] MICROSOFT. 2005. Microsoft .NET. http://www.microsoft.com/net/

Chapter 8 – References

50

[16] POWER L., MOORE B. 2003. Migrating WebLogic Applications to WebSphere V5. http://www.redbooks.ibm.com/ [17] SUN MICROSYSTEMS. 2004. Java™ AVK for the Enterprise: Testing J2EE™ Applications for Portability. http://java.sun.com/j2ee/verified/ [18] SUN MICROSYSTEMS. 2005. J2EE FAQ. http://java.sun.com/j2ee/faq.html [19] SUN MICROSYSTEMS. 2005. Java BluePrints. http://java.sun.com/reference/blueprints/ [20] THE APACHE ANT PROJECT. 2005. The Apache Ant Project. http://ant.apache.org/ [21] THE TCL/JAVA PROJECT. 2005. The TCL/Java Project. http://tcljava.sourceforge.net/ [22] XDOCLET. 2005. XDoclet. http://xdoclet.sourceforge.net/

Standards [23] SUN MICROSYSTEMS. 1999. Java Naming and Directory Interface 1.2 Application Programming Interface (JNDI 1.2 API). http://java.sun.com/products/jndi/ [24] SUN MICROSYSTEMS. 2002. Java 2 Enterprise Edition Deployment API Specification, Version 1.1. http://java.sun.com/j2ee/tools/deployment/ [25] SUN MICROSYSTEMS. 2003. Enterprise JavaBeansTM Specification, Version 2.1. http://java.sun.com/javaee/ [26] SUN MICROSYSTEMS. 2003. Java™ 2 Platform Enterprise Edition Specification, v1.4. http://java.sun.com/javaee/ [27] SUN MICROSYSTEMS. 2005. Java Management Extensions (JMX). http://java.sun.com/products/JavaManagement/

Appendixes

51

Appendix Appendix A. Dictionary EJB Enterprise Java Bean JMS Java Message Service JNDI Java Naming and Directory Interface JSP Java Server Page J2EE Java 2 Enterprise Edition JVM Java Virtual Machine RMI Remote Method Invocation WORA Write Once, Run Anywhere XML Extended Markup Language

Appendixes

52

Appendix B. Code B1. ejb-jar.xml example

<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'> <ejb-jar id="ejb-jar_ID"> <description>1A Air module contains two EJBs: availability and itinerary menagement</description> <enterprise-beans> <session> <description>Air Availability module provides service for obtaining availability/schedules.</description> <ejb-name>airavailability</ejb-name> <home>com.amadeus.ocg.standard.business.air.availability.AirAvailabilityHome</home> <remote>com.amadeus.ocg.standard.business.air.availability.AirAvailability</remote> <local-home>com.amadeus.ocg.standard.business.air.availability.AirAvailabilityHomeLocal</local-home> <local>com.amadeus.ocg.standard.business.air.availability.AirAvailabilityLocal</local> <ejb-class>com.amadeus.ocg.standard.business.air.availability.AirAvailabilityBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> </enterprise-beans> </ejb-jar>

B2: weblogic-ejb-jar.xml example <!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic 7.0.0 EJB//EN' 'weblogic-ejb-jar.dtd'> <weblogic-ejb-jar> <weblogic-enterprise-bean> <ejb-name>airavailability</ejb-name> <enable-call-by-reference>false</enable-call-by-reference> <jndi-name>com.amadeus.ocg.standard.business.air.availability.AirAvailability</jndi-name>

Appendixes

53

<local-jndi-name>com.amadeus.ocg.standard.business.air.availability.AirAvailabilityLocal</local-jndi-name> </weblogic-enterprise-bean> </weblogic-ejb-jar>

B3: Ant script to test an archive <target name=”static-archive-test”> <ArchiveTest appName=”/path/to/ear/filename.ear” reportingOpts=”a”/> </target>

TRITA-CSC-E 2006:134 ISRN-KTH/CSC/E--06/134--SE

ISSN-1653-5715

www.kth.se

Date post:	07-Feb-2018
Category:	Documents
Upload:	doduong
View:	216 times
Download:	1 times

Migration of a Large Scale J2EE Application from BEA ... · PDF fileMigration of a large scale...

Documents