A CHOICE BETWEEN INTEROPERABILITY AND MIGRATION

by

CHAITANYA KURADA

Bachelor of Technology, Acharya Nagarjuna University, India, 2004

A REPORT

submitted in partial fulfillment of the requirements for the degree

MASTER OF SCIENCE

Department of Computing and Information SciencesCollege of Engineering

KANSAS STATE UNIVERSITYManhattan, Kansas

2006

Approved by:

Major ProfessorDr. Daniel Andresen

ABSTRACT

Many of the websites today are mainly based on the J2EE standard or the

Microsoft.NET architecture and use similar client-server technologies. ASP.NET

provides a fast means of developing a rich user interface while the J2EE standard

provides more flexibility with the business logic tier. Companies that use J2EE

technology are bound to using JSP/Struts/Spring for their presentation layer. Companies

that want a few applications with the interface in asp.net but are currently using J2EE

technology have either the option of migrating their business logic to a new server like

IIS for these applications or build web services and use them from their presentation layer

in asp.net, i.e. giving their system a heterogeneous architecture.

This project tries to analyze the choice of interoperability as opposed to migration

and answers the question of feasibility in merging the presentation layer in an ASP.NET

framework with a business layer written in J2EE while developing a fully functional E-

Commerce website. It also addresses the issues and challenges that could occur in

developing such a heterogeneous website. The business logic in J2EE is built using EJB’s

which is exposed to the asp.net client using web services. The feasibility of such a

heterogeneous architecture is primarily dependent upon the response time of the web

server to fulfill the requests. The first part of the report gives the details of the

implementation while the latter gives details about the testing and draws conclusions

based on the results of the testing.

TABLE OF CONTENTS

LIST OF FIGURES.......................................................................................................v

LIST OF TABLES........................................................................................................vi

ACKNOWLEDGEMENTS.........................................................................................vii

CHAPTER 1 - Introduction...........................................................................................1

CHAPTER 2 - KEY TECHNOLOGIES INVOLVED..................................................3

2.1 ASP.NET.............................................................................................................3

2.2 J2EE.....................................................................................................................4

2.3 Interoperability Technologies..............................................................................5

2.3.1 Microsoft DCOM..........................................................................................5

2.3.2 CORBA/ Java RMI.......................................................................................6

2.3.3 Web Services................................................................................................6

2.3.3.1 Web Services Technologies...................................................................8

2.3.3.2 Web Service Invocation.......................................................................10

CHAPTER 3 - TOOLS AND TECHNOLOGIES USED...........................................11

3.1 Visual Studio.NET 2003:...................................................................................11

3.2 IIS 5.0 Server.....................................................................................................11

3.3 WebLogic 8.0 Application Server/WebLogic Workshop IDE..........................11

3.4 Enterprise Java Beans........................................................................................12

3.5 Web Services / XML.........................................................................................12

3.6 Ajax....................................................................................................................13

3.7 JavaScript / DOM..............................................................................................13

3.8 Scriptaculous 1.6.1.............................................................................................14

3.9 RSS 1.0..............................................................................................................14

CHAPTER 4 - IMPLEMENTATION.........................................................................16

4.1. System Architecture..........................................................................................16

4.2 Use Case Diagram............................................................................................17

4.3 Class Diagram....................................................................................................18

4.4 Database Design................................................................................................20

iii

4.5 Web Services.....................................................................................................21

4.6 Functionality......................................................................................................22

CHAPTER 5 - INTEROPERABILITY, A PROGRAMMER’S PERSPECTIVE......25

CHAPTER 6 - TESTING............................................................................................27

6.1 Unit Testing.......................................................................................................27

6.2 Performance Testing..........................................................................................29

CHAPTER 7 - EXPERIENCES AND PROJECT METRICS....................................35

7.1 Problems faced...................................................................................................35

7.2 Overall Experience............................................................................................35

7.3 Project metrics...................................................................................................36

CHAPTER 8 - CONCLUSION AND FUTURE WORK............................................37

8.1 Conclusion.........................................................................................................37

8.2 Future work........................................................................................................37

8.2.1 Implementation...........................................................................................37

8.2.3 Testing.........................................................................................................37

REFERENCES............................................................................................................39

iv

LIST OF FIGURES

Figure 1: Architecture of ASP.NET Framework [2].....................................................3

Figure 2: Architecture of J2EE......................................................................................5

Figure 3: Web Services Technologies [2].....................................................................8

Figure 4: Web Service Invocation [3].........................................................................10

Figure 5: Format of RSS feed [4]................................................................................15

Figure 6: System Architecture.....................................................................................16

Figure 7: Customer Use case diagram.........................................................................17

Figure 8: System use case diagram..............................................................................18

Figure 9: Class diagram...............................................................................................19

Figure 10: Database Relational Schema.....................................................................20

Figure 11: Snapshot of NUnit testing..........................................................................28

Figure 12: Graphical view of the performance under heavy load...............................31

v

LIST OF TABLES

Table 1: Configuration of System................................................................................27

Table 2: Summary of test results.................................................................................30

Table 3: Overall analysis of the test suites..................................................................34

Table 4: Lines of code/ number of classes...................................................................37

vi

ACKNOWLEDGEMENTS

My special thanks to my major professor Dr. Daniel Andresen for giving me

timely advice, encouragement, and guidance throughout the project.

I would also like to thank Dr. Gurdip Singh and Dr. Mitchell Neilsen for

graciously accepting to serve on my committee.

I would like to thank the administrative and technical support staff of the

department of CIS for their support throughout my graduate study.

vii

CHAPTER 1 - Introduction

Software companies that are bound to using a technology like J2EE for their

applications might want to consider moving their presentation layer to a different

technology like ASP.NET, as .NET offers advanced features to build attractive web

pages. In such situations, the companies have two options.

1. The option of moving their entire business logic to a new asp.net server and rewriting

the entire code in asp.net or

2. Expose the existing business logic of J2EE to the asp.net client without having to

rewrite the entire code in asp.net.

The first option is referred to as migration and the latter is referred to as interoperability.

Migration gives the system a homogeneous architecture whereas interoperability gives

the system a heterogeneous architecture.

The decision of choosing between migration and interoperability is dependent on the

following factors.

1. Migration needs the programmers to be experienced in the other platform.

2. If the business logic is complex, the time frame should be considerably large for

migration.

3. Interoperability needs the complete knowledge of the business logic and the ease to

expose it to the outside world.

4. Performance of the interoperated services.

This project analyses the feasibility in exposing the J2EE business logic from a

programmer’s perspective by developing an E-Commerce web site and then compares the

performance of the web server in a homogeneous architecture to that in a heterogeneous

one. The user interface and functionality of this website is inspired from the online

shopping site of ‘finishline’ [11]. The first two chapters talk about the technologies

needed to build a cross platform based website and the tools and technologies used to

develop this website. Chapter 4 talks about the details of implementation, architecture,

and functionality while Chapter 5 throws a light on the programmer’s perspective of

developing an interoperable website. Chapter 6 talks about the testing and compares the

1

performance of the web server in a homogeneous architecture vis-à-vis the performance

in a heterogeneous one. The later chapters talk about the future work and conclusions

derived.

2

CHAPTER 2 - KEY TECHNOLOGIES INVOLVED

This chapter discusses the technologies that are needed to integrate two

heterogeneous platforms to achieve interoperability. The platforms considered here are

the J2EE standard and Microsoft’s ASP.NET.

2.1 ASP.NET

Microsoft has introduced ASP.NET, a new version of ASP, which allows the

developers to build Web applications with great ease, courtesy of its highly advanced

IDE, Visual Studio .NET. ASP.NET and Web Services are the main components of what

is called the .NET framework (Fig 1).One of the most significant features of the .NET

framework is it enables code written in multiple languages to work together seamlessly.

One of the significant improvements in ASP.NET is the way the code is handled at run

time. Instead of interpreting the page source each time a client requests a page; ASP.NET

seamlessly compiles the page to Microsoft intermediate language (MSIL) code the first

time the page is requested. Once the page is compiled in MSIL, the just-in-time (JIT)

compiler converts the MSIL to native code.

Figure 1: Architecture of ASP.NET Framework [2]

3

Layered on top of the system services is the CLR which loads and runs code written in

any language which targets the runtime. The .NET Framework classes provide classes

that can be called from any .NET enabled language. On the top of the .NET Framework

class library is ADO.NET and XML data. ADO.NET is a set of classes that provide data

access support for the .NET Framework based on ADO but to work with XML and work

in a disconnected environment. On top of ADO.NET and XML lies specific support for

two different types of applications. One is the traditional client application that uses

window Forms and the other is ASP.NET which offers Web Forms and XML Web

Services. On top of these is the common language specification which ensures that each

language has a common set of features.

2.2 J2EE

The Java 2 Platform, Enterprise Edition (J2EE) was designed to simplify complex

problems with the development, deployment, and management of multi-tier enterprise

solutions. J2EE is an industry standard, and is the result of a large industry initiative led

by Sun Microsystems.

J2EE has historically been architecture for building server-side deployments in the Java

programming language. It can be used to build traditional web sites, software

components, or packaged applications. J2EE has been extended to include support for

building XML-based web services as well. These web services can interoperate with

other web services that may or may not have been written to the J2EE standard.

4

Figure 2: Architecture of J2EE

2.3 Interoperability Technologies

To allow the two heterogeneous platforms discussed above to interoperate, we

need a technology that can communicate with both of these irrespective of the

architecture of the underlying system. There are many such technologies which are

designed to facilitate the leveraging of remote components. This section throws light on

such technologies, their merits, and demerits.

2.3.1 Microsoft DCOM.

The Microsoft Distributed Component Object Model (DCOM), a distributed object

infrastructure that allows an application to invoke Component Object Model (COM)

5

Presentation Tier

Database/ Message Queues

STRUTS

JSP’s Web Services

XML Beans

Local/ Remote Stateless Session EJB’s

Message Driven Beans

JMX

Services Tier

JDBC

Row Sets

JMSJava Mail

Local CMP

Entity Beans

Integration Tier

WebLogic/J2EE Component

Open Source/ 3rd Party Component

components installed on another server, has been ported to a number of non-Windows

platforms. But DCOM has never gained wide acceptance on these platforms, so it is

rarely used to facilitate communication between Windows and non-Windows computers.

ERP software vendors often create components for the Windows platform that

communicate with the back- end system via a proprietary protocol.

2.3.2 CORBA/Java RMI

CORBA is the acronym for Common Object Request Broker Architecture,

OMG's open, vendor-independent architecture and infrastructure that computer

applications use to work together over networks. Using the standard protocol IIOP, a

CORBA-based program from any vendor, on almost any computer, operating system,

programming language, and network, can interoperate with a CORBA-based program

from the same or another vendor, on almost any other computer, operating system,

programming language, and network.

Disadvantages of CORBA/RMI/DCOM

Since we want a .NET client written in C sharp to communicate with the EJB

business logic written in Java, we need a technology that is both platform independent

and language independent. Java RMI can be used for accessing remote services but since

it is tightly coupled to the Java language it is not suitable for interoperating between two

different languages. CORBA has been used since the 90’s as a technology to access

remote services. Though CORBA is platform independent and has high performance, it is

generally not suitable for web interfaces. Also, CORBA uses the IIOP protocol for

communication, which does not have a specific port. Security conscious network

administrators can install firewalls which can filter these IIOP messages. Also CORBA

needs the ORB object to be installed on both the client and the server to leverage remote

components. DCOM and its successor .NET Remoting can only be used for

homogeneous architectures, i.e., both the client and server need to be using the .NET

technology. Hence none of the above technologies are suitable for interoperating,

2.3.3 Web Services

With the advent of XML technology most of the problems discussed above are solved

by what is known today as a Web Service. Web services are building blocks for creating

6

open distributed systems, and allow companies and individuals to quickly and cheaply

make their digital assets available worldwide. They have the following advantages

Interoperability: Web Services can be consumed by clients on other platforms.

Internet friendliness: They work well for supporting clients that access the remote

service from the Internet.

Strongly typed interfaces: There is no ambiguity about the type of data sent to and

received from a remote service. Furthermore, data types map reasonably well to data

types defined by most procedural programming languages.

Ability to leverage existing Internet standards: Web Services leverage existing

Internet standards as much as possible and avoid reinventing solutions to problems that

have already been solved.

Support for any language: Web Services are not tightly coupled to a particular

programming language. Java RMI, for example, is tightly coupled to the Java language. It

would be difficult to invoke functionality on a remote Java object from Visual Basic or

Perl. A client can be able to implement a new Web service or use an existing Web service

regardless of the programming language in which the client was written.

Support for any distributed component infrastructure: They are not tightly

coupled to a particular component infrastructure. In fact, you need purchase, install, or

maintain a distributed object infrastructure to build a new remote service or consume an

existing service. The underlying protocols facilitate a base level of communication

between existing distributed object infrastructures such as DCOM and CORBA.

7

2.3.3.1 Web Services Technologies

Figure 3: Web Services Technologies [2]

The four main components of web services are:

1. Extensible Markup Language (XML)

XML happened to be the de facto language of Web Service technology. However, it also

has the more general purpose within the confines of Internet technology, of simply

making data portable. Like HTML, XML is a markup language and has its roots in

SGML; thus, it’s a specification for “tagging” documents in a meaningful way. Unlike

HTML, which provides means for visualizing data, XML allows data to be self-

describing and structured and so is meant primarily for the interchange of the data, not its

visualization. XML is human legible and is the language by which Web service requests

are issued and corresponding responses are delivered.

2. Simple Object Access Protocol (SOAP)

Simple Object Access Protocol, a lightweight XML-based messaging protocol used to

encode the information in Web service request and response messages before sending

them over a network. SOAP messages are independent of any operating system or

protocol and may be transported using a variety of Internet protocols, including SMTP,

MIME, FTP, and HTTP. By having a standard transport mechanism, heterogeneous

clients, and servers become interoperable.

8

3. Web Service Description Language (WSDL)

WSDL describes the public interface to the web service. This is an XML-based service

description on how to communicate using the web service; namely, the protocol bindings

and message formats required to interact with the web services listed in its directory. The

supported operations and messages are described abstractly, and then bound to a concrete

network protocol and message format.

WSDL is often used in combination with SOAP and XML Schema to provide web

services over the internet. A client program connecting to a web service can read the

WSDL to determine what functions are available on the server. Any special data types

used are embedded in the WSDL file in the form of XML Schema. The client can then

use SOAP to actually call one of the functions listed in the WSDL.

4. Universal Description, Discovery, and Integration (UDDI)

UDDI is one of the core Web Services standards. It is designed to be interrogated by

SOAP messages and to provide access to Web Services Description Language documents

describing the protocol bindings and message formats required to interact with the web

services listed in its directory. Business analysts and technologists use UDDI to discover

available web services by searching for names, identifiers, categories, or the

specifications implemented by the web service.

9

2.3.3.2 Web Service Invocation

Figure 4: Web Service Invocation [3]

The client querying the UDDI service initiates a typical invocation process between a

client and Web service. Once the UDDI service processes the client request, it returns a

URL to the Web service description file, which in this case would be a WSDL or service

contract file for that particular Web service. After the client receives the URL to the

service description, it sends in a request for the complete service description to the target

server where the Web service is hosted. Host Server returns the service description for

the Web service, which contains details about the available methods and the necessary

parameters to these methods along with their type information. Once the requesting client

has received the service description, it has the information needed to compose and send a

properly formatted SOAP request asking the target server to invoke the method and

return the results. Finally, client composes proper SOAP requests based on service

description and sends them over the wire using a transport protocol, which can be HTTP,

SMTP, or FTP.

10

CHAPTER 3 - TOOLS AND TECHNOLOGIES USED

3.1 Visual Studio.NET 2003:

I have used Visual Studio 2003 for the ASP.NET 1.1 framework installed on my system.

Visual Studio.NET is the only advanced IDE that can be used as a rapid application

development tool for ASP.NET. Though Microsoft introduced the free Web Matrix IDE

later, Visual Studio.Net remains far more advanced and vastly used IDE. . The IDE

makes creating attractive web pages a child’s play and provides built in support for

XML parsing. However, it does not have the advanced features like support for Ajax,

draggable content, RSS feeds etc. All these are available in ASP.NET 2.0 framework.

ASP.NET 2.0 comes with a built in support for Ajax called Atlas. I had to implement

these features using third party tools.

3.2 IIS 5.0 Server

IIS is the default server that comes with the XP professional operating system. Though

not robust, it is simple enough to manage because of the GUI support. However, it can

support only 10 simultaneous browser connections which can be a hindrance while

testing.

3.3 WebLogic 8.0 Application Server/WebLogic Workshop IDE

WebLogic is the application server developed by BEA which comes with a built-in IDE

which makes developing and building J2EE applications easy. WebLogic Workshop is an

integrated development environment for building enterprise-class J2EE applications on

the WebLogic Platform. WebLogic Workshop provides an intuitive programming model

that enables us to focus on building the business logic of the application rather than on

complex implementation details like deployment, creating jar files, writing deployment

descriptors etc.

WebLogic Workshop's intuitive user interface lets us design the application visually.

Controls make it simple to encapsulate business logic and connect to enterprise resources,

like databases and Enterprise JavaBeans, without writing a lot of code. Creating and

deploying web services is also made very easy.

11

“Based on the industry agreed upon standard for Java compatible application server

benchmark testing, BEA WebLogic Server currently holds the highest mark”. [6]

However it consumes a lot of memory and processor time and is a heavy weight

application and is not be suitable to be installed on a laptop.

3.4 Enterprise Java Beans

Enterprise JavaBeans (EJB) technology is the server-side component architecture for Java

Platform, Enterprise Edition (Java EE). EJB technology enables rapid and simplified

development of distributed, transactional, secure, and portable applications based on Java

technology. EJB’s are deployed in an EJB container within the application server. The

specification describes how an EJB interacts with its container and how client code

interacts with the container/EJB combination. I have used two types of beans for this

project

1. Stateless Session Beans: Stateless session beans are distributed objects that do not

have state associated with them thus allowing concurrent access to the bean. The contents

of instance variables are not guaranteed to be preserved across method calls.

3. Entity Beans: Entity beans are distributed objects having persistent state. The

persistent state may or may not be managed by the bean itself. Beans in which their

container manages the persistent state are said to be using Container-Managed

Persistence (CMP), whereas beans that manage their own state are said to be using Bean-

Managed Persistence (BMP). I have used CMP entity beans for the project. The

development of EJB’s was made easy by the advanced features of the WebLogic

Workshop IDE.

3.5 Web Services / XML

According to the W3C a web service is a software system designed to support

interoperable machine-to-machine interaction over a network. Web Services act as an

interface between the two heterogeneous platforms and provide a means of cross platform

access. Since the data types may be inconsistent across the different platforms, XML is

used to wrap the data that is being passed across the platforms. XML provides a text-

12

based means to describe and apply a tree-based structure to information. At its base level,

all information manifests as text, interspersed with markup that indicates the

information's separation into a hierarchy of character data, container-like elements, and

attributes of those elements. The XML data is then parsed on the client side using DOM

parsing and then displayed. As there is no direct means of passing record sets over a cross

platform network, I have used XML extensively to wrap the data in a record set. Images

are retrieved as a byte array which is converted as a string and passed over the network.

A total of 35 web services were used to expose the business logic to the client.

3.6 Ajax

Ajax, shorthand for Asynchronous JavaScript and XML, is a web development

technique for creating interactive web applications. The intent is to make web pages feel

more responsive by exchanging small amounts of data with the server behind the scenes,

so that the entire web page does not have to be reloaded each time the user makes a

change. This is meant to increase the web page's interactivity, speed, and usability. It

makes use of the XmlHttpRequest object to make asynchronous requests to the server

without the knowledge of the user. The data retrieved is then parsed using DOM and

JavaScript. Ajax can only be used for transferring small amounts of data as it affects the

response of the page. I have used Ajax for retrieving the city and state information and to

check the email availability for the registration module, the shopping cart, check out and

personalized home modules.

3.7 JavaScript / DOM

JavaScript is used for client side validation and to handle the data from the Ajax server

pages. DOM provides an object oriented application programming interface that allows

parsing HTML or XML into a well defined tree structure and operating on its contents.

The DOM is used extensively in the shopping cart module to update the shopping cart

and add buttons to remove and update the product in the cart.

13

3.8 Scriptaculous 1.6.1

ASP.NET 1.1 does not have support for built in draggable contents. So I had to use

Scriptaculous JavaScript library to achieve the drag drop effects in the shopping cart

module of the website. It is built on the Prototype JavaScript framework. Its development

is driven heavily by the Ruby on Rails framework, but it can be used in any environment.

It is a JavaScript library which has inbuilt functions for various effects, for example the

blinds effect which makes the contents of a ‘div’ slowly appear and disappear.

3.9 RSS 1.0

RSS which stands for Really Simple Syndication is a standard for publishing regular

updates to a web based system. It can be used for syndicating news and the content of

news-like sites, recent changes" page of a wiki, a changelog of CVS checkins, even the

revision history of a book. This project uses RSS feeds to know about the deals in various

websites and let the users have their personalized view of the feeds. The basic format of

an RSS feed has the structure of XML and it has a specific format.

14

Figure 5: Format of RSS feed [4]

The above RSS feed is taken from DHTML goodies. RSS feeds have the above structure

and the tags are not customizable unlike XML. Each RSS feed has a single channel which

has a number of items which are links to other web pages. Each item has a publication

date which allows the items to be sorted so that the latest item is displayed first in the

field. ASP.NET 1.1 does not have support for web parts which are built for RSS feeds.

Hence I had to use the JavaScript framework from DHTML goodies website. I had to

write an RSS parser for parsing the feed and display them in RSS boxes. The items are

sorted according to their publication date and then displayed. The publication date format

of an RSS feed is RFC 1123 which is not supported by ASP.NET 1.1, so I had to parse it

as a string and convert it into a date.

15

CHAPTER 4 - IMPLEMENTATION

The implementation part of the project is concerned with interoperability and primarily

focuses on the feasibility question of the report. i.e., if a company has the business logic

in J2EE, how easy is it to give it a presentation layer in a different platform. A fully

functional E-Commerce website which has a heterogeneous architecture (Figure 6) is

developed for this purpose. The testing part of the project answers how well this

architecture works in comparison with a homogeneous architecture.

4.1. System Architecture

The architecture of the cross platform website is shown below

Figure 6: System Architecture

The client can either contact the server by calling a C# function on the code behind file

(aspx.cs) causing a request to be sent to the server or contact the server asynchronously

using Ajax. The code behind file and the Ajax server pages call the corresponding web

service which resides on the WebLogic application server. The browser can also contact

the web service directly using Ajax. The web service in turn calls a function in the

session bean which interacts with the database using JDBC. The session bean sends a

request to the SMTP server to send emails. The ADO.NET component of the .NET

user session

user activity

BROWSER

Code behind

IIS 5.0 WEB SERVER

EJB’S

Web

Services

WebLogic

APPL SERVER

CIS

Oracle 9i

Database

KSU

SMTP

Server

Web Service call

Front

End

HTML

CSS

ADO.NET

Ajax server pages

AJAX

function call

Web Service call

JDBC

AJAX

function call

16

framework does not play any significant part as the business logic is entirely handled by

the EJB’s.

4.2 Use Case Diagram

The use case diagram from the customer’s perspective is shown below. The customer can

register and then login to the website. He can browse through various items and apply

filters, search for a product, sort the results and select items to buy. He can also browse

through previous transactions and create his own home page using RSS feeds.

Figure 7: Customer Use case diagram

The use case diagram from the system’s perspective is shown below. The system can

authenticate a user when he tries to logon to the website. It can validate the credit card

number entered by the user and encrypt the password and store it in the database. It can

check for user name conflicts while a user is registering to the website and send email to

the user if he forgets his password.

The system also calculates the shipping cost based on the total price of the items

purchased and the tax based on the zip code.

17

Figure 8: System use case diagram

4.3 Class Diagram

The customer class is the cardinal class giving details about the customer and what

actions he can perform. A customer is associated to one credit card and a credit card has

only one customer. A shopping cart contains 1 or more items while an item may appear

in more than a shopping cart. A customer can be associated with more than 1 shopping

cart but a shopping cart is associated with only 1 customer. Every transaction has a single

shopping cart and a shopping cart may or may not be in a transaction. Since the customer

may add items to the shopping cart but may not check them out.

18

Figure 9: Class diagram

19

4.4 Database Design

Figure 10: Database Relational Schema

I have used the Oracle 9i server of the department of CIS as the database server for this

project. I have used 11 tables to build the resource tier of the website. The information

about the main categories like men’s, women’s, kid’s, and accessories is stored in

msr_category. Each category has subcategories like Men’s running or Women’s tops

which are stored in msr_subcategory with a unique subcategory id. Every product is

stored in the table msr_items which gives the details of the product like brand, color, size,

and subcategory. Every product has three images (small, medium, and large) which are

stored in msr_subcat_image as blobs. The details of the customer are stored in

msr_customer_details and the credit card details are stored in msr_customer_card. The

table msr_shoppingcart captures the information related to a shopping cart like the items

and their quantity in the cart. If the customer purchases the items the transaction is

recorded in the table msr_transaction. The table msr_personalizedhome keeps track of

20

the RSS feeds the user has selected for his homepage. The tbl_zipcodes contains the zip

codes of 44,000 towns and cities in the United States. This is used to retrieve the city and

state information based on the zip code.

Apart from these tables I have used the following PL/SQL procedures embedded in

packages.

a) PKG_ITEMS contains

1. get_items: This procedure retrieves the products and their details based on the brand,

size, and color.

2. get_filters: This procedure retrieves the filters based on the subcategory id. For

example, it retrieves all the brands that are related to men’s running shoes.

3. get_product_details: Retrieves the product details based on the product id.

4. get_new_arrivals: This procedure retrieves the new arrivals based on the arrival date

and information like brand and subcategory.

5. get_max20sellers: Retrieved the top 20 selling items on the website. It utilizes the

view view_sales to retrieve this information.

b) PKG_PERSONALIZEDVIEW contains

1. insertfeed: This procedure inserts RSS feeds based on the username into the table

msr_personalized_home.

4.5 Web Services

The following is the list of web services that are used to expose the business logic written

in EJB’s for this website.

1. Registration web service:

This web service provides the interface to the registration functionality and exposes the

functions like authenticating the user, checking email availability, retrieving the city and

state information from zip code, inserting the user details in the database, and retrieving

the user details.

2. Shopping cart web service:

This web service provides the interface to the shopping cart functionality and exposes the

functions like adding, removing, updating items to shopping cart, calculating taxes and

21

shipping cost, retrieving cart details, selecting the maximum sellers, and retrieving details

about new arrivals.

3. Personalized home web service:

This web service provides the interface to the personalized home functionality and

exposes the functions like retrieving feeds based on email, inserting feeds into the

database, and updating the feeds.

4. Banner web service:

This web service provides the interface to miscellaneous functionalities of the web site

like retrieving product details, retrieving filter information, retrieving banner details and

other functions that are used to populate the menu bar.

Other web services include validating the credit card and resetting the password and

notification by email.

4.6 Functionality

BigBazaar is an online shopping website which includes the basic features that are

required by an E-Commerce website. The functions which require interaction with the

databases are written in EJB’s which are exposed as web services that the IIS server uses

to fulfill the users request.

4.6.1 Registration: Customers can register on the website using an Ajax equipped form

by providing details like name, address, and login information. The city and state

information is automatically fetched from the database upon providing the zip code by

sending an asynchronous request to the server. The server in turn calls the corresponding

web service which returns the city and state information to the server which populates the

textboxes using JavaScript. Customers provide their login username which is an email

address and a password. The username is checked for uniqueness in the database

asynchronously as he enters the information. If the username provided already exists in

the database the user is notified and if the user name does not exist, a new account is

created with that username and the password is stored in an encrypted format in the

database. The customers are also required to provide the credit card details which are

validated using the mod 10 algorithm.

22

4.6.2 Login and shop: After registering to the website customers can login by providing

their email and password and start shopping after a successful authentication.

4.6.3: Browse items: Customers can browse various items based on the category. For

example, the store assorts the items into categories like men’s apparel, women’s

footwear, accessories etc.

Customers can also browse by best selling items and new arrivals.

4.6.4 Search, Sort and filter items: Customers can search for a particular item by its

name or by its brand. They can sort items by their price and filter the displayed items by

brand, color, size, or price. These filters are dynamically populated from the database.

4.6.5 Shopping Cart: If the customer is interested in a particular item he can add it to the

shopping cart by simply dragging its image onto the shopping cart which is below the

displayed item. The shopping cart is updated with the new item and provides the options

of editing the quantity and removing the item completely. All these operations are

performed asynchronously using the Ajax technology along with DOM and XML. The

backend logic is handled using EJB’s. The user can navigate away from the page and

select other items to add to the cart. After the user is done with selecting items he can

check them out.

4.6.6 Check Out: The check out phase comprises of tax calculation and shipping cost for

the items in the cart. These are then added to the total cost of the items and displayed.

The user can still edit his shopping cart and the calculations are done asynchronously.

The user can edit his shipping address information and the shipping method at this stage

and confirm the order to complete the transaction.

4.6.7 View transaction history: Customers can view their past orders using this

functionality

4.6.8 Personalized home: This is a replica of Google’s personalized home. After logging

in, the customers can use this feature to add RSS feeds to their page which will enable

them to access deals other related websites and other interesting feeds of their own. Each

user has his/her own personalized view. Any changes to this view like adding feeds or

changing the positions of the displayed feeds are reflected in the database. So when the

user logs back in, the view of his homepage is persisted.

23

4.6.9. Locate a store: This feature which utilizes the Google map API can be used to

locate the stores in a particular city or town.

4.6.10: Reset password: Customers have an option of resetting their password if they

have forgotten it.

24

CHAPTER 5 - INTEROPERABILITY, A PROGRAMMER’S

PERSPECTIVE

This chapter deals with the issues that could occur while designing a cross platform

based web site from a programmer’s perspective, assuming that the programmer is

proficient in both the technologies. The entire business logic has to be exposed as web

services so that the .net client can access the functionality of the web site. As the

underlying platforms are different, a number of issues can arise while trying to make

them communicate and pass data between them.

1. Inability of web services to return complex data types. Since web services are

platform independent they can only return basic data types like Integer, Boolean and

String. These data types are uniform across both the platforms. However data types like

record set (J2EE) and data set (.NET) are frequently used while retrieving data from the

database. After retrieving the data as a record set a programmer needs to convert the

record set into xml string in the code and return the output as a string. Java does not have

a method of converting the record set into a string. The string returned from the web

service has to be parsed on the client side to retrieve the database values.

2. User defined XML tags. The popularity of XML is due to its user defined custom

tags. However, in the case of interoperability they pose a problem. For example, the EJB

retrieving the price and name of an item may embed these retrieved values in custom tags

like ‘<price>’ and ‘<itemname>’ when constructing the XML string. Now, to parse the

XML string on the client side, the developer must know how the values are embedded

i.e., he should know that price is embedded in ‘<price>’ tag. Here the abstraction

provided by the web service is lost as the WSDL file is of no use. The WSDL file only

talks about the parameters, their type which are to be passed to the web service, and the

type of the returned data which is string in this case.

3. Change in Business Logic: The original business logic in J2EE may return result sets

to the corresponding JSP client (presentation layer). But when the presentation layer is

changed to .NET the business logic has to be modified slightly to return strings instead of

25

record sets. Functions that return basic data types need not be modified and can be

exposed as web services.

4. Passing parameters. In the validation module, I had to pass a character value from

the .net client to the web service. However while retrieving the data at the EJB’s this

character is being interpreted as an integer. The reason for this is web services use ASCII

encoding of characters by default.

5. Use of a suitable IDE: I have used WebLogic IDE for coding the business logic

which has advanced features like automatic creation of entity beans, creation of web

services, generating WSDL file, automatic deployment of EJB’s and web services. If the

business logic is written in a not so advanced IDE, exposing the EJB’s as web services

would have been difficult as a number of steps are involved in this process. Fortunately,

we have a number of advanced IDE’s like WebLogic, NetBeans, IBM’s WebSphere

which abstract the deployment issues from the coding

To summarize, the easiness in exposing the business logic depends on the

complexity of the EJB’s, the IDE that is being used and the programmer’s proficiency.

The advanced tools have really made creating heterogeneous web sites simple and fast.

26

CHAPTER 6 - TESTING

Testing was performed on the same system which hosts the two web servers, IIS and

WebLogic. The database was accessed using wireless LAN. The configuration of the

system is shown below.

Table 1: Configuration of System

6.1 Unit Testing

The functionality of the website depends upon the correctness of the web services in

responding to the requests with a suitable and legitimate response. So in order to check

the functionality of the website black box testing of the web services is needed. The web

services could either be tested at the WebLogic application server using JUnit or at

the .Net Client using NUnit. Checking the correctness from the client is more accurate as

these services are invoked from the ASP.NET client. This would also check the cross

platform compatibility. Hence, I have used NUnit to test the web services. A total of 19

functions were checked for correctness and all of them were found to be responding

correctly.

1. AuthenticationTest : This test case tests the web service that takes the username and

password as input and verifies the authenticity of the user.

2. CardDetailsTest: The web service which returns the credit card details when the

username is provided is tested

Operating System Windows XP Professional

Processor Intel Pentium(M)

Memory 1 GB RAM

Clock Speed 1.86 GHz

27

3. EmailAvailabilityTest: This test case tests the web service which checks the database

for similar emailget2MaxSellersTest: This test case checks the web service that returns

the maximum sellers from the database.

4. getCartDetailsTest: This test case tests the web service that returns the cart details if

the cart number is provided.

5. getItemsbyFiltersTest: This test case tests the web service that returns the items based

on the filters like brand name, price range etc.

6. getShippinTaxesTest: This test case tests the web service that returns the shipping and

taxes information based on the total value of the shopping cart.

7. insertProductIntoCartTest: This test case tests the web service which inserts the

product into a shopping cart.

8. insertTransactionTest: This test case tests the web service which inserts the

transaction, into the database.

9. Retrieving information tests: Various tests were conducted to test the web services

that retrieve information from the database. These include retrieving category name, zip

code, filter information, brand information, user details, banner information etc.

10. validatingCreditCardTest: This test case is used to test the web service which

validates the credit card information provided.

28

Figure 11: Snapshot of NUnit testing

6.2 Performance Testing

As discussed earlier, the choice between migration and interoperability boils down to the

performance of the web server in responding to the requests. For testing interoperability I

have used the architecture of the BigBazaar website as a framework. To test the

migration option I have replaced the web service calls to J2EE with calls to ADO.NET

making the architecture homogeneous.

Testing tools:

Apache JMeter: I have used Apache JMeter to perform load testing for most of the test

suites. Its simple GUI and elaborative aggregate report make it an effective testing tool.

Microsoft Application Center Test: Since Apache JMeter does not support testing of

pages with Ajax I tried to use Microsoft ACT for some test suites.

29

AdventNet QEngine: QEngine is an advanced tool for functional, performance and

web service testing of web applications and web services. I used QEngine for testing the

Ajax pages.

Test Suite design. I have designed 9 test suites to simulate various real time scenarios

that could occur. Every test suite tests both architectures rigorously by varying the

parameters of server load, request length and complexity of the request and finding out

the page download time (ms). The load on the server is varied from 1 browser making

200 requests each to 10 browsers making 200 requests each. Since the IIS server supports

only 10 simultaneous browser connections, the number of browsers was restricted to 10

to minimize the socket errors. I have designed 2 pages for each test suite, one that has

homogeneous architecture and the other that has heterogeneous architecture. Each test

suite is run for 4 iterations and the mean values of the page download time are calculated.

The architecture of the 2 pages is shown below. I will refer to the pages as homogeneous

page and heterogeneous page.

Figure 12: Control flow of heterogeneous page

Figure 13: Control flow of homogeneous page

Summary of the test results

BrowserCodeBehind

CIS Oracle

Database

1

8

Web Service

EJB’s

2

7

3

64

5IIS Server

WebLogic

Server

Ajax

4

BrowserCodeBehind

CIS Oracle

DatabaseADO.NET

1

62

35

Ajax

30

The following table displays the mean page download time in milliseconds for all the test

suites.

Table 2: Summary of test results

Figure 12: Graphical view of the performance under heavy load

We can infer from the table that the performance of the heterogeneous pages is slower

when compared to the homogeneous pages. The homogeneous pages are less than twice

as fast as the heterogeneous pages while retrieving data from the database in the first

three suites and nearly 10 times faster in the suites 5, 6, and 7. The homogeneous pages

are thrice as fast as the heterogeneous pages in the 4th test suite. The performance of both

the pages is almost equal in the 8th test suite while the homogeneous pages are 5 times

31

faster than their counterparts in the last suite. A closer look at the test suites will enable

us to determine the cause of this low performance.

Test Suites 1, 2, and 3

These test suites were designed for testing normal pages that retrieve varying amounts of

data like 50KB, 200KB, and 1MB from the database. The tests are performed on two

pages, one that gets data through a J2EE web service and another which gets the same

data through ADO.NET. The homogeneous page has the bottle neck of accessing the

database while the heterogeneous page has the bottleneck of accessing the database and

returning the result to a different platform. Since the same data is retrieved in both the

pages, we would also be testing the performance of ADO.NET in accessing the database

vis-à-vis JDBC accessing the database.

Analysis for the above test suites:

In test suites 1, 2, and 3, the responsiveness of the heterogeneous pages is not far behind

the homogeneous pages. The overhead of the database access is equal on both the pages

and there is neither wrapping of xml data on the J2EE side, nor parsing of xml data on the

client side, thereby reducing the interoperability overhead. The low interoperability

overhead makes both the architectures equally responsive.

Test Suite 4

This suite was designed to test the scenario where heavy computation is done in the

business logic. One thousand numbers are retrieved from the database and we sort them

using bubble sort and then find the square root of the sum of the cosine’s, sin’s and log

values of all the thousand numbers and return the result.

Analysis of test suite 4:

The homogeneous pages were only thrice as fast as the heterogeneous pages in this case.

This can be attributed to the identical work done by both ADO.NET and EJB’s. There is

no xml wrapping overhead on the EJB’s which makes the heterogeneous pages more

responsive.

32

Test Suite 5

This suite is designed to test pages that retrieve data with very little logic overhead on the

database. These are pages that retrieve a name when an email is provided. The purpose of

the test is to minimize the overhead on the database so that the actual interoperability

overhead can be calculated. The homogeneous page will certainly perform better than the

heterogeneous page, but the real purpose is to test the tolerability of the heterogeneous

page.

Test Suite 6

This suite is designed to test pages that retrieve data with complex logic on the database.

A procedure which retrieves items based on the filters passed is used to generate the

complexity. This test analyses the ability of a heterogeneous website to handle the

complexity. The weight of each response is 19 KB.

Test Suite 7

This suite is designed to test pages that retrieve large amount of data (1000 records, 300

KB) from the database. It differs from suite 3 in that it converts the data into xml format

and passes it to the client. The client parses the huge xml string and loads them into a

table.

Analysis of test suites 5, 6, and 7:

On the average, the homogeneous architecture is 20 times faster than the heterogeneous

architecture in these test suites. This is due to the fact that a heterogeneous page has an

additional overhead of xml wrapping and unwrapping. Data is retrieved as a record set

from the database and wrapped up in xml format and passed to the client. The client then,

has to parse the xml string and load the elements. The low performance of the

heterogeneous page can be attributed to this overhead of xml wrapping/unwrapping.

Test Suite 8

33

This test is designed to check the response of Ajax equipped pages when retrieving small

amounts of data on both platforms. The Ajax overhead should not be considered as it is

equally significant in both homogeneous architecture and heterogeneous architecture.

Test Suite 9

This test is designed to check the response of the Ajax equipped pages when retrieving

large amount of data.

Analysis of test suites 8 and 9:

Test suite 7, which is tested for small amounts of data surprisingly went well for the

heterogeneous page. The response time was on par with its counterpart, especially for

heavy loads. However when large amount of data is passed the page lags behind in

performance. Since Ajax is generally used to transfer small amounts of data, the

heterogeneous architecture will work fine for such pages.

Overall analysis

The following table gives the number of times the homogeneous page if faster than the

heterogeneous pages.

Table 3: Overall analysis of the test suites

From the above table we can infer that for file transfers both heterogeneous and

homogeneous architectures perform equally well, and the difference in the performance

of both decreases as the size of the file increases. This may be due to the fact that

DataAdapter in ASP.Net 1.1 is not optimized to handle large number of records. This

drawback was addressed in the latest version of ASP.NET 2.0.

The performance of a heterogeneous architecture is lower than the homogeneous

architecture when large amounts of data are retrieved from the database due to the

additional overhead of wrapping the data in xml format. The difference in the

performance decreases with increased data size due to the fact that the homogeneous

34

platform gets the data from the database in a DataAdapter which is not optimized for

performance. However, we cannot conclude that heterogeneous pages are poor in

performance since the server tested is not a powerful one and more number of

simultaneous browser connections is required.

An important point to note is that both the web servers reside on the same machine. So

for the cross platform testing there is no real network bottleneck. A real time scenario

testing is required to really predict the performance of the web service as opposed to the

similar platform business logic.

CHAPTER 7 - EXPERIENCES AND PROJECT METRICS

7.1 Problems faced

The main hurdle for this project was the learning curve of J2EE and the WebLogic IDE.

As this is my first application in J2EE I had to learn about EJB’s and how they are

developed in WebLogic. I had to go through all the tutorials in WebLogic on Entity

beans, Session beans and Web services. As I was using ASP.NET 1.1 which does not

have support for Ajax or dragdrop elements, I had to rely on third party tools like

Scriptaculous and code from DHTML goodies. Though I had the framework from

DHTML goodies, the RSS parser was in PHP. I had to customize the JavaScript and then

write a parser in .net for RSS. The date format was encoded in RFC1123 format which is

not supported for parsing in .net. So I had to extract the date information from the string

by parsing it manually. Frequently getting disconnected to oracle server was also a major

problem. I used to get a lot of TNS time out errors while implementing the project. I had

tried various tools for testing this website. JMeter could not test Ajax pages, so I had to

look for an alternative. I have tried Microsoft ACT but was getting socket errors while

testing heavy loads. So I had to use AdventNet’s QEngine to do Ajax testing. I had to run

the tests many times to get a valid result as some of them resulted in socket errors and

35

HTTP errors. Often JMeter used to choke and shutdown while testing heavy load

applications.

7.2 Overall Experience

This project gave me an insight into the development of a cross platform based website

and exposed me to the J2EE architecture for the first time. Working with EJB’s,

especially the entity beans was a challenging task. The drag drop effects by the

Scriptaculous framework held me in awe of the power of JavaScript and the plethora of

things it can do along with DOM. I got to know the working of RSS feeds and their use

in day to day life. Implementing the replica of Google’s personalized home appeased my

thirst for achievement. Courtesy of the rigorous testing of the website, I realized that

interoperability is fruitful in cases of file transfers from the database and tolerable in case

of normal data transfer. To summarize, doing this project was a very good learning

experience and made me realize how well people come up with ideas to tackle issues

which were once a major concern.

7.3 Project metrics

Lines of Code

Table 4: Lines of code/ number of classes

ASP.NET User controls 1600 / 17

ASP.NET Code Behind files 4000 / 12

EJB’s 3000 / 10

Web Services 400 / 5

JavaScript 1041

Time spent

Table 5: Time spent on the project

System setup and installation 3 hrs

Learning WebLogic IDE 12-15 hrs

Implementation 65-80 hrs

36

Testing 30-40 hrs

Documentation 10-15 hrs

CHAPTER 8 - CONCLUSION AND FUTURE WORK

8.1 Conclusion

The objective of the project was to determine the feasibility in accessing the business

logic in J2EE from an ASP.NET platform and then test the performance of a

heterogeneous architecture vis-à-vis a homogeneous architecture. This would enable us in

choosing the right choice between migration and interoperability. From a programmer’s

perspective interoperability doesn’t seem to be any complex than migration just because

of the advanced IDE’s that are provided today. It all boils down to how the server

performs in both architectures when subjected to heavy load.

The performance of the heterogeneous architecture is impressive in some cases like file

transfers. It is on par with the performance of the homogeneous architecture as the file

size increases. However, the heterogeneous architecture lags behind when large amounts

of data is to be passed due to the additional overhead of xml wrapping. The report

provides the results of various tests that simulate situations that could occur in real world

and the choice between migration and interoperability really depends on the complexity

of the application and what it does.

8.2 Future work

The following are some of the enhancements that could be made in the future.

37

8.2.1 Implementation

Customers can have the option of reviewing the products and the products can be

rated by the feedback.

Customers can have the option of choosing multiple credit cards from a single user

account.

Every product can be classified by a style number and customers should be able to

search by the style number.

8.2.3 Testing

Both the servers should have a communication bottleneck between them to match up

with the real time scenario.

The load on the server can be increased drastically up to 200 simultaneous browser

connections to simulate real time scenarios and the performance of both the architectures

should be monitored.

The testing should be carried on powerful servers that are used by organizations for

their applications. The results of the tests would be similar to real time performance of

their applications.

38

REFERENCES

[1] Simon Guest, “ASP.NET and J2EE Interoperability toolkit”, 2003

[2] Scott Short, “ Building XML Web services for the Microsoft platform”, 2002

[3] David Muldrow, Understanding Web Service Invocations. April 2002

http://www.research.ibm.com/journal

[4] DHTML Goodies, Draggable RSS boxes, http://www.dhtmlgoodies.com

[5] Scriptaculous, Java Script Effects, http://script.aculo.us

[6] BEA Web Logic Workshop Help, Documentation,

http://edocs.bea.com/workshop/docs81/doc/en/core/index.html .

[7] Jonathan Fenocchi, How to develop web applications with Ajax, Pt.1, March

2003, http://www.webreference.com/programming/javascript/jf/column12/

[8] DOM tutorial, DOM nodes and trees, June 2006

http://www.howtocreate.co.uk/tutorials/javascript/dombasics

[9] Mondial Database, Zip codes database,

http://www.dbis.informatik.uni-goettingen.de/Mondial/#Oracle

[10] Builder.com, Introducing the ASP.NET XmlDocument Object, Oct 2004

http://builder.com.com/5100-6371-5406817.html#Listing%20A

[11] Finishline, User Interface and functionality, http://www.finishline.com

.

39

40