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 Sciences
College of Engineering
KANSAS STATE UNIVERSITY
Manhattan, Kansas
2006
Approved by:
Major Professor
Dr. 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 ECommerce 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 .................................................................. 36
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
Presentation Tier
JSP’s
Web
Services
STRUTS
Services Tier
Local/ Remote
Stateless Session EJB’s
Message
Driven
Beans
XML
Beans
J
M
X
Integration Tier
Local CMP
JDBC
Entity Beans
Row Sets
JMS
Java Mail
Database/ Message Queues
WebLogic/J2EE Component
Open Source/ 3rd Party Component
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
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 selfdescribing 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 BeanManaged 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
user session
Front
End
BROWSER
KSU
HTML
user activity
SMTP
CSS
Server
AJAX
AJAX
function call
function call
Web
Web Service call
Code behind
Ajax server pages
IIS 5.0 WEB SERVER
ADO.NET
Web Service call
Services
EJB’S
WebLogic
CIS
JDBC
Oracle 9i
Database
APPL SERVER
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
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
Operating System
Windows XP Professional
Processor
Intel Pentium(M)
Memory
1 GB RAM
Clock Speed
1.86 GHz
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
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.
27
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.
Figure 11: Snapshot of NUnit testing
28
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.
 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.
29
1
Browser
Ajax
2
Code
Behind
8
7
IIS Server
Web
Service
3
6
WebLogic
EJB’s
Server
4
CIS Oracle
Database
5
Figure 12: Control flow of heterogeneous page
1
Browser
Ajax
Code
Behind
CIS Oracle
6
5
2
3
Database
ADO.NET
4
Figure 13: Control flow of homogeneous page
Summary of the test results
The following table displays the mean page download time in milliseconds for all the test
suites.
Table 2: Summary of test results
30
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
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.
31
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.
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
32
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
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
33
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
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.
34
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
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
35
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
Testing
30-40 hrs
Documentation
10-15 hrs
36
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.
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.
37

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