a choice between interoperability and migration - People - Kansas ...

tastefallInternet and Web Development

Feb 2, 2013 (4 years and 4 months ago)

125 views




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




Departm
ent 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
Mi
crosoft.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 bo
und 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
que
stion 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 h
eterogeneous 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.



iii

TABLE OF CONTENTS

LIST OF FIGURES

................................
................................
................................
............

v

LIST OF TABLES

................................
................................
................................
.............

vi

ACK
NOWLEDGEMENTS

................................
................................
..............................

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


iv

4.5 Web Services

................................
................................
................................
..........

21

4.6 Functionality

................................
................................
................................
...........

22

CHAPTER 5
-

INTEROPERABILI
TY, 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 Implementatio
n

................................
................................
................................

37

8.2.3 Testing

................................
................................
................................
..............

37

REFERENCES

................................
................................
................................
.................

39


v


LIST OF FIGURES

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

................................
....................

3

Figure 2: Architecture of J2EE

................................
................................
.....................

5

Figure 3: Web Services Techno
logies [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 diagr
am

................................
................................
.............

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


vi


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


vii


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 st
aff of the
department

of CIS

for their support throughout my graduate study.


1

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
techno
logy 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.

Exp
ose 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 a
rchitecture 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 platf
orm.

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 compare
s the

2

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.



























3

CHAPTER 2
-

KEY TECHNOLOGIES INVOLVED

This chapter discu
sses 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, w
hich 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 feature
s 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 requ
ests 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]



4

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 .N
ET 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

e
nvironment. 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 langu
age 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
sol
utions. 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 tradition
al 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 J2E
E standard.












5



















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 b
oth 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)
Presentation Tier

Database/ Message Queues



STRUTS


JSP’s

††
teb


pe牶楣es


X
ML
Bea
ns

Local/ Remote

Stateless Session EJB’s

䵥獳sge
䑲楶敮i
Bea湳

g

j

u

Services Tier

JDBC

Row Sets

JMS

Java Mail

Local CMP

Entity Beans

Integration
Tier



WebLogic/J2EE Component

Open Source/ 3
rd

Party Component



6

components installed on another server, has been ported to a number of non
-
Windo
ws
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 w
ith the back
-

end system via a proprietary protocol.

2.3.2 CORBA
/Java RMI

CORBA

is the acronym for
C
ommon
O
bject
R
equest
B
roker
A
rchitecture,
OMG's open, vendor
-
independent architecture and infrastructure that computer
applications use to work together ove
r 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 oth
er 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 independ
ent
and language independent. Java RMI can be used for accessing remote services but since
it is tightly coupled to the J
ava 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

homogeneo
us 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 sol
ved
by what is known today as a Web Service.

Web services are building blocks for creating

7

open distributed systems, and allow companies and individuals to quickly and cheaply
make their digital assets available worldwide. They have the following advantage
s



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 o
f 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 standard
s 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 lan
guage. 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 writte
n.



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.








8

2.3.3.1 Web Services Technologies


Figu
re
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 purpo
se 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 visu
alizing 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 respons
es are delivered.

2.
Simple Object Access Protocol (SOAP)

S
imple
O
bject
A
ccess
P
rotocol
, 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 message
s 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.



9

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 wit
h 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 Des
cription 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, ide
ntifiers, categories, or the
specifications implemented by the web service.



















10

2.3.3.2 Web Service Invocation




Figure
4
: Web Service Invocation [3]



The client querying the UDDI service initiates a typical invocat
ion 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 c
lient 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 abou
t 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 as
king 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.



11

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 introd
uced 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 featur
es 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
testin
g.


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 env
ironment 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 de
tails 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.


12

“Based on the industry agreed upon standard for Java compatible application server
benchmark testing, BEA WebLogic Server cu
rrently 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 co
ntainer 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
:

Statele
ss 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 d
istributed 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 t
heir 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 we
b 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
-

13

based means to describe and apply a tree
-
based structure to information. At its base level,
all information manifest
s 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 display
ed. 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

A
synchronous
Ja
vaScript and
X
ML
, is a web development
technique for creating interactive web applications. The intent is to make web pages feel
more respon
sive 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 u
se 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
resp
onse 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 clien
t 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 extensi
vely in the shopping cart module to update the shopping cart
and add buttons to remove and update the product in the cart.


14

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 l
ibrary 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 JavaScri
pt 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
R
eally
S
imple

S
yndication is a standard for publishing regular
updat
es 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 vario
us
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.


15



Figure
5
: Format of RSS feed [4]


The above RSS feed is taken from D
HTML 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.



16

CHAPTER 4
-

I
MPLEMENTATION

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 prese
ntation 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 homo
geneous 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# funct
ion 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 se
rver. 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.N
ET component of the .NET

user ses
sion

user activity


BROWSER

Code behind

IIS 5.0
WEB SERVER

EJB’S

teb

pe牶楣es

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


17

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 pas
sword 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
pu
rchased and the tax based on the zip code.




18




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 associ
ated 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 w
ith 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.


19


Figure
9
: Class diagram










20

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 websit
e. 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 a
re 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

21

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 ba
sed 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 ba
sed 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_sa
les 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 e
xpose 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, retrievi
ng 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

22

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 fun
ctionalities 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 passw
ord 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
informa
tion 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 a
re
validated using the mod 10 algorithm.


23

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 variou
s 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 an
d 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
: Cust
omers 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 b
ack in, the view of his homepage is persisted.


24

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.





























25

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 pro
grammer 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 un
iform 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 stri
ng 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
. T
he 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 ‘<it
emname>’ 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 i
s 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

26

record sets. Functions that return basic d
ata 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 be
ans, 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 i
n 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.


















27

CHAPTER 6
-

TESTING

Testing was performed on the same system which hosts the two web servers, IIS and
W
ebLogic. 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 tes
ting 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 A
SP.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 ret
urns the cart details if
the cart number is provided.

Operating System

Windows XP Professional

Processor

Intel Pentium(M)

Memory

1 GB RAM

Clock Sp
eed

1.86 GHz


28

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 r
eturns 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 ser
vice 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, br
and 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



29

6.2
Perfo
rmance 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 fr
amework. 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 o
ccur. 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 reques
ts 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
ho
mogeneous 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 hom
ogeneous
page and heterogeneous page.




30


Figure 12: Control flow of heterogeneous page



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




4

Browser

Code

Behind

CIS Oracle
Datab
a
se

ADO.NET

1

6

2

3

5

Ajax

Browser

Code

Behind

CIS Oracle
Datab
a
se

1

8

Web
Service

EJB’s

2

7

3

6

4

5

IIS Server

WebLogic

Se
r
ver

Ajax


31


Figure
12
: Graphical view of the performance under heavy load


We can infer from the table that the p
erformance 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 faste
r in the suites 5, 6, and 7. The homogeneous pages
are thrice as fast as the heterogeneous pages in the 4
th

test suite. The performance of both
the pages is almost equal in the 8
th

test suite while the homogeneous pages are 5 times
faster than their counte
rparts in the last suite. A closer look at the test suites will enable
us to determine the cause of this low performance.


Test Suite
s

1
, 2, and 3

These test suites were designed for testing normal pages that retrieve varying amounts of
data like 50KB, 20
0KB, 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 heterog
eneous 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 acce
ssing the database.



32

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 t
est 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 thous
and 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 over
head 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. T
he 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 tolerabil
ity 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

33

complexity. This test analyses t
he 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 hetero
geneous
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 clien
t. 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 respons
e 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 counterpar
t, especially for
heavy loads. However when large amount of data is passed the page lags behind in

34

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 tra
nsfers 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
addi
tional 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 th
e 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.






35

CHAPTER 7
-

EXPERIENCES AND PRO
JECT 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 tu
torials 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 f
ramework 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 infor
mation 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 res
ult 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 ca
n 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
inter
operability is fruitful in cases of file transfers from the database and tolerable in case

36

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

10
41


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










37

CHAPTER 8
-

CONCLUSION AND FUTURE WORK

8.1 Conclusion

The objective o
f 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 c
hoice 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 ar
chitectures 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 heteroge
neous 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 migrat
ion 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.


38



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 application
s.


























39

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 applic
ations 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]

Finishlin
e, User Interface and functionality,
http://www.finishline.com

.