View
7
Download
0
Category
Preview:
Citation preview
FEASIBILITY OF POINT-TO-POINT INTEROPERABILITY FOR
INTEGRATING .NET WITH J2EE APPLICATIONS
By
VENUMANOHAR REDDY MODUGU
Bachelor of Engineering, Osmania University, India, 2004
A REPORT
Submitted in partial fulfillment of requirements for the degree
MASTER OF SCIENCE
Department of Computing and Information Sciences
College of Engineering
KANSAS STATE UNIVERSITY
Manhattan, Kansas
2007
Approved by:
Major Professor Dr. Daniel Andresen, Ph. D
ABSTRACT
In the present World Wide Web system, numerous web-applications that are in
use are developed using .NET, J2EE or similar client-server technologies. At some point
of time in the web-application’s existence, it may require to modify the architecture of
the entire application, for example, to migrate from J2EE to .NET, or to add additional
features, improve existing features, for example, to improve the look and feel of the
interface for a good browsing experience to the user, etc. The .NET framework, a
framework developed by Microsoft helps in easy and efficient development of web-
applications. Both ASP.NET and J2EE have their own advantages and disadvantages.
ASP.NET provides easy and attractive user interface and makes the pages easy to
maintain while J2EE offers flexible business tier for the applications. Businesses that
want to shift from J2EE to ASP.NET have to either migrate completely by rewriting the
existing code or build services that use the advantages of ASP.NET and build only the
presentation tier, retaining the business tier. The latter is generally known as
Interoperability, meaning that the application has components in different platforms or
architectures that inter-operate with each other, the former is known as Migration. The
choice between Interoperability and Migration has to be done carefully as it influences
the time frame for the conversion of the web-application. Migration process spans a long
software development life-cycle and time frame because everything has to be developed
from scratch, whereas interoperability techniques save a great deal in factors such as
time, money, workforce, etc. as it uses the existing components to develop new
components.
The purpose of this project is to determine that if an organization needs to incorporate
new technologies into their existing web-application, then how feasible it is to adapt
interoperability techniques to make web-application architecture heterogeneous i.e. to
enable components of different architectures inter-operate. The integration of ASP.NET
presentation tier with the existing J2EE business tier is considered as the problem for this
project. We analyze the feasibility, which depends on the server’s response time by
combining two different architectures to achieve a heterogeneous architecture for a
university library web-application. The report is written in detail with the descriptions of
the implementation, tools used, along with the details of testing, results obtained and
conclusions drawn. I also briefly describe the future work that can be conducted in this
area.
iv
TABLE OF CONTENTS
LIST OF FIGURES ........................................................................................................... vi
LIST OF TABLES............................................................................................................ vii
ACKNOWLEDGEMENTS............................................................................................. viii
CHAPTER 1 – INTRODUCTION ..................................................................................... 1
CHAPTER 2 – PLATFORMS USED ................................................................................ 3
2.1 J2EE.......................................................................................................................... 3
2.2 ASP.NET .................................................................................................................. 5
CHAPTER 3 - INTEROPERABILITY TECHNOLOGIES .............................................. 8
3.1 Microsoft DCOM...................................................................................................... 8
3.2 CORBA / JAVA RMI............................................................................................... 8
3.3. Webservices ............................................................................................................. 9
3.3.1 Webservice Technologies ................................................................................ 10
3.3.1.1 Extensible Markup Language (XML)....................................................... 10
3.3.1.2. Simple Object Access Protocol (SOAP).................................................. 11
3.3.1.3 Webservice Description Language (WSDL) ............................................ 11
3.3.1.4. Universal Description, Discovery, and Integration (UDDI).................... 12
3.3.2 Webservice Invocation..................................................................................... 12
CHAPTER 4 - TOOLS AND TECHNOLOGIES USED................................................. 14
4.1 ASP .NET 2.0 and Microsoft Visual Studio 2005.................................................. 14
4.2 IIS 5.0 Server .......................................................................................................... 15
4.3 Sun Java System Application Server Platform Edition 9 ....................................... 15
4.4 Enterprise Java Beans 3.0 ....................................................................................... 16
4.4.1 Session Beans................................................................................................... 16
4.4.2 Entity Beans ..................................................................................................... 16
4.5 NetBeans IDE 5.5 ................................................................................................... 17
4.6 Webservices and XML ........................................................................................... 17
4.7 AJAX ...................................................................................................................... 18
4.8 JavaScript / DOM ................................................................................................... 19
4.9 Microsoft SQL Server 2005.................................................................................... 19
v
CHAPTER 5 – IMPLEMENTATION.............................................................................. 20
5.1 System Architecture................................................................................................ 20
5.2 Use Case Diagram .................................................................................................. 21
5.3 Class Diagram......................................................................................................... 22
5.4 Database Schema .................................................................................................... 24
5.4.1 Database tables................................................................................................. 25
5.4.2 Intermediate Datasets....................................................................................... 27
5.5 Functionality ........................................................................................................... 27
5.5.1 User .................................................................................................................. 27
5.5.2 Administrator ................................................................................................... 29
5.6 J2EE Webservices................................................................................................... 30
CHAPTER 6 – WEB-APPLICATION TESTING ........................................................... 31
6.1 Unit Testing ............................................................................................................ 31
6.2 Performance Testing ............................................................................................... 34
6.2.1 Load testing using Web Server Stress Tool 7 .................................................. 34
6.2.1.1 Analysis of test results .............................................................................. 35
6.2.2 Web Performance Testing using QEngine Server ........................................... 39
6.2.2.1 Test suites.................................................................................................. 40
6.2.2.1.1 Test suite 1 ............................................................................. 40
6.2.2.1.2 Test suite 2 ............................................................................. 41
6.2.2.2 Analysis of Test results............................................................................. 41
6.2.2.3 Reasons for low performance of the .NET-J2EE application................... 44
6.2.2.4 Summary of Test results ........................................................................... 47
CHAPTER 7 – PROBLEMS FACED AND PROJECT METRICS ................................ 49
7.1 Problems Faced....................................................................................................... 49
7.2 Overall Experience ................................................................................................. 50
7.3 Project Metrics........................................................................................................ 50
CHAPTER 8 – CONCLUSION AND FUTURE WORK ................................................ 52
8.1 Conclusion .............................................................................................................. 52
8.2 Future Work............................................................................................................ 53
REFERENCES ................................................................................................................. 54
vi
LIST OF FIGURES
Figure 1: J2EE Architecture [4].......................................................................................... 4
Figure 2: .NET Architecture [7].......................................................................................... 6
Figure 3: Webservice Components [7] ............................................................................. 10
Figure 4: Webservice Invocation [6] ................................................................................ 13
Figure 5: System Architecture .......................................................................................... 20
Figure 6: Use Case Diagram. ............................................................................................ 22
Figure 7: Class Diagram ................................................................................................... 23
Figure 8: Database Schema............................................................................................... 24
Figure 9: NUnit test results screenshot. ............................................................................ 33
Figure 10: Data transfer rate (in Kbits/s) for .NET - .NET application............................ 38
Figure 11: Date transfer rate (in Kbits/s) for .NET – J2EE application ........................... 38
Figure 12: Comparison for light load simulation (Data Vs Download time in ms) ......... 43
Figure 13: Comparison for heavy load simulation (Data Vs Download time in ms) ....... 43
Figure 14: Comparison showing effect of Thrashing during a webservice call ............... 46
vii
LIST OF TABLES
Table 1: System Configuration ......................................................................................... 31
Table 2: Average click time (in milliseconds) per user for .NET - .NET application...... 36
Table 3: Average click time (in ms) per user for .NET – J2EE application ..................... 37
Table 4: Test suite configuration for each of the applications.......................................... 40
Table 5: Mean Page download time for requesting 100 KB of data................................. 41
Table 6: Mean Page download time for requesting 500 KB data ..................................... 41
Table 7: Mean Page download time for requesting 1.3 MB data ..................................... 42
Table 8: Time spent on the project ................................................................................... 50
Table 9: Lines of code....................................................................................................... 51
viii
ACKNOWLEDGEMENTS
My special acknowledgements go to my major professor Dr. Daniel Andresen for
giving me timely advice, encouragement and guidance through out the project. I am
grateful for his patience in listening to my ideas and giving his valuable inputs.
I would also like to thank Dr. Torben Amtoft and Dr. Mitchell L. Neilsen for graciously
accepting to serve on my committee.
I would also like to thank Dr. William J. Hankley for his observation as proxy for Dr.
Torben Amtoft, during my Master’s defense.
I would also like to thank my friend, Tejaswi Pydimarri for helping me fix the registry
entries of trial versions of various tools used for the project.
Finally, my special thanks to my dearest friend, Susmitha Pabbaraju for her words of
encouragement that kept my spirits high.
1
CHAPTER 1 – INTRODUCTION
During the past few years, organizations recognized both the need and the
benefits of .NET and JAVA platforms, recognized that each has specific costs and
benefits, and built applications that run on both. Because of the powerful and cool
interface features offered by ASP.NET many organizations that develop and maintain
web based applications are moving their presentation tier from Java based technology to
.NET. During this change they have to deal with a number of issues, time being a major
constraint. Not surprisingly, given that mix of platforms, they're now finding an
increasing need for interoperability, and are starting to consider the best approach for
achieving that interoperability [1]. Webservices provide Interoperability between various
web-applications running on disparate platforms/operating systems. Interoperability
provide organizations with a choice of moving from J2EE technology to .NET
technologies by retaining the existing business logic and changing the client logic to
ASP.NET. This helps them to provide clients the features of .NET without entirely
rewriting the code when compared to migration where the entire code needs to be
rewritten.
Both interoperability and migration have there own advantages and disadvantages.
Interoperability allows heterogeneous architecture without the necessity to rewrite the
entire code but requires complete understanding of the business logic of the web-
application that is being modified. Migration on the other hand, is homogenous
architecture but requires sufficiently large time frame, resources and requires the
2
programmer to have sufficient experience in programming in both the platforms to
rewrite from scratch. The main question that has to be considered for interoperability is
the compatibility between the two technologies and their effect on the performance of the
web-applications.
The purpose of this project is to study the feasibility to adapt interoperability techniques
to merge a J2EE platform based university library application with an ASP.NET interface
tier. The interface and other functionalities of this application are inspired from the
website of KSU Libraries [2]. To pin-point the performance issues in a heterogeneous
architecture, the application is tested for various metrics such as mean page download
time, data transfer rate, load testing, etc. and compared with those of the corresponding
homogeneous application. The homogeneous application comes from an already
developed web-application having both the presentation tier and business logic in .NET,
having exactly the same functionality as the heterogeneous one. The heterogeneous
architecture is referred to as .NET-J2EE application and the homogeneous architecture is
referred to as .NET-.NET application, through out this report. The next two chapters
introduce the various tools and technologies needed to build a heterogeneous web-
application. In the following chapter the details of implementation, architecture, and
functionality of the web-application are explained while in Chapter 5 the programmer’s
perspective in developing an interoperable web-application is explained. Chapter 6 talks
about the testing and compares the performance of the web-application in both the
architectures. The following chapters discuss the conclusions drawn and future work.
3
CHAPTER 2 – PLATFORMS USED
To achieve interoperability we need to combine tiers of a program developed in
different platforms. In this chapter, the two frameworks that are used for developing the
interoperable web-application, J2EE and Microsoft’s .NET are introduced. These
frameworks are evolutions of application server technologies used to build enterprise
applications.
2.1 J2EE
Java 2 platform, Enterprise Edition is used to develop portable, scalable, secure server-
side Java applications [4]. It was basically developed to introduce the concept of “write
once, run anywhere” concept. It is a programming platform for developing and running
distributed multi-tier architecture Java applications [4]. The most important feature of
J2EE is its substantial support for webservices that enable webservice endpoints based on
servlets and Enterprise JavaBeans. J2EE has several API’s JDBC, RMI, XML, etc. and
also includes Enterprise JavaBeans (EJB), servlets, JSP which allows the creation of
enterprise applications. J2EE which can be used to develop traditional web-applications,
packaged applications has the features that support XML based services which can
interoperate with other webservices written in either J2EE or other platforms.
J2EE applications are nothing but assembled functional software units called components
with their related classes and files and communicate with other components. The
components of a J2EE application can be broadly classified into client components, web
or business components and data components. The J2EE architecture is shown in Figure
4
1. Client components comprises of application clients or web browsers, applets and
optional bean classes. The type of the application being developed determines the client
component; the application client is either run directly on the client machine or the web
browser downloads the web-pages and applets to the client machine. Its main function is
providing a way to the users to handle tasks like application administration, etc.
Application clients and web browsers can directly access enterprise beans without using
web components.
Figure 1: J2EE Architecture [4]
Web components of J2EE are JSP pages or servlets. Servlets are classes that process and
construct responses dynamically while JSP pages are text documents that contain statistic
content and snippets of Java code to generate dynamic content. Business components are
the code that meets the specification of particular domain application. These components
communicate between components of database tier and the web tier. Business
components mainly comprise of Enterprise Java Beans which can be classified into
Webservices
XML
beans
5
session beans, entity beans and message-driven beans. These beans are used to
implement the business logic for a specific domain application.
2.2 ASP.NET
Microsoft has introduced a platform, .NET technology that provides the ability to quickly
build, deploy, manage, and use connected security-enhanced solutions with Webservices
[3]. ASP.NET, a framework developed by Microsoft allows rapid development of
powerful web-applications. It has many advantages for both the users of the application
as well as the programmers. ASP.NET and the .NET framework simplify the process of
development by separating the application logic and presentation logic making it easier to
maintain the code. The .NET architecture is shown in Figure 2.
The most distinguishing and important feature of .NET framework is the Common
Language Infrastructure. This helps in developing the program on any language
compatible with the framework being used. .NET framework provides this feature with
the help of a run-time environment called Common language runtime (CLR) which is a
multi-language execution environment. This allows the programmers to write their code
in most of the .NET languages like VB.NET, C#.NET, giving them the option to choose
the language they are comfortable with. In .NET framework we have Common Type
System (CTS) which consists of .NET Class Library that ensure the consistency of the
object model of all the different .NET languages. These define a common set of types
that can be used with any .NET language and have no particular syntax or key words.
They enable cross-language interactions, high performance code execution. Common
Language Infrastructure (CLI) is a specification that defines an environment that allows
6
multiple high-level languages to be used on different computer platforms without being
rewritten for specific architectures. .NET framework also has a set of class libraries
ADO.NET and XML which support the work in XML and other environments on the
.NET framework. This makes it possible to design classes that can be used from any
environment that is enabled with .NET framework.
Figure 2: .NET Architecture [7]
.NET framework apart from providing better interface, automatically recovers from
memory leaks and errors which makes the application available to the users continuously.
Visual Basic
.NET
C# Jscript.NET …….
Common Language Specification (CLS)
C++
ASP.NET Windows Forms
XML and ADO.NET
Classes of .NET Framework
Common Language Runtime (CLR)
Windows COM+ Services
7
It can recover from errors as it compiles the web-page when it is accessed for the first
time into an intermediate language and then recompiles it into native code every time it is
accessed. This compiling-caching feature of .NET helps in developing robust web-
applications.
8
CHAPTER 3 - INTEROPERABILITY TECHNOLOGIES
Interoperability is defined as the capability of different programs to exchange data
over a common set of business procedure, use same protocols, etc. [6]. To allow this a
technology is needed that can act as a communication bridge between the two platforms
that are being used. There are many interoperability technologies available to allow two
heterogeneous platforms to communicate. A few technologies and their advantages and
disadvantages are discussed in this chapter.
3.1 Microsoft DCOM
DCOM (Directive Component Object Model), a Technology of Microsoft that enables
software components to communicate across the network boundaries is an extension of
Component Object Model. The mechanism of DCOM is similar to the mechanism of
remote procedure call and uses this for communication between the client and server.
COM allows the reusability of the component developed without the knowledge of their
internal implementation. Although it can be applied to several platforms, it was generally
used with Windows and has never gained acceptance as it rarely communicated between
Windows and Non-Windows platform.
3.2 CORBA / JAVA RMI
CORBA is an acronym for Common Object Request Broker Architecture, an open
vendor-independent architecture. It is similar in functionality with JAVA RMI. It helps
software components written in multiple languages to run over multiple systems to allow
interoperability [4]. A CORBA based program from one vendor can communicate with a
9
CORBA based program from the same or different vendor irrespective of the knowledge
of the environment in which they were developed.
Though CORBA, JAVA RMI, Microsoft DCOM were developed earlier they have
certain disadvantages which hindered them from gaining wide acceptance. DCOM and
the initial versions of .NET need both the communicating components to be of the same
platform, which can be used only with homogeneous architecture and hence cannot be
used for Interoperability. Although CORBA is a vendor independent standard it limits the
implementation due to complex nature of standard and interoperability requirements it is
hard to achieve seamless integration of components. Also CORBA uses IIOP protocol
which is not port-specific making it difficult to be implemented. When using JAVA RMI
we face with the issues of lack of security, poor performance, etc. which make them
unpopular.
3.3. Webservices
XML technology has solved most of the problems that were caused with the use of the
interoperable technologies used. These are popularly known as Webservice, building
blocks for creating open distributed systems. Webservices has become very popular due
to the advantages it provides the users over other interoperable technologies. Unlike
CORBA and JAVA RMI webservices are not tightly coupled to a particular language or
component structure there by enabling easy usage. It not only supports interoperability
but also provides services that support the client in accessing remote services through
internet. Also it ensures that there is no ambiguity between the data that is sent or
received from a remote service.
10
3.3.1 Webservice Technologies
Webservices are composed of mainly four components, Extended Markup language
(XML), Simple Object Access Protocol (SOAP), Webservice Description Language
(WSDL) and Universal Description, Discovery and Integration (UDDI). A brief
description of these components and the invocation of webservices are discussed in the
rest of this chapter. The components of a webservice are described as layers in Figure 3.
Figure 3: Webservice Components [7]
3.3.1.1 Extensible Markup Language (XML)
XML is a simple and flexible format designed to meet the challenges of large scale
electronic publishing [5]. It contains the descriptions of classes called XML documents
Service Discovery
UDDI
Service Description
WSDL
Service Invocation
SOAP
Encoding
XML
Transport
HTTP
11
and behavior of the computer programs that process them. The documents in XML
contain parsed or unparsed data called Entities which also contains some form of
“Markup” which define the layout of the application. XML imposes constraints on
layout and logical structure of the data. XML allows data to be structured and self
describing. This helps in interchanging the data over different platforms.
3.3.1.2. Simple Object Access Protocol (SOAP)
SOAP is a simple XML based protocol that helps people to interchange data over HTTP
or computer based network. SOAP is a platform-independent protocol and can be used to
send messages of various internet protocols. There are several different types of
messaging patterns in SOAP, while the most popular pattern is Remote Procedure Call
(RPC). This feature of webservice makes it more feasible for interoperability.
3.3.1.3 Webservice Description Language (WSDL)
WSDL is XML based format to that is used for describing network based webservices
and how to access them. It is used in combination with SOAP and XML format to
provide webservices over the internet. It specifies the location of the service and the
operations that the service exposes. The supported operations and messages are described
abstractly, and then bound to a concrete network protocol and message format. Any
special data types that are used are embedded in WSDL as XML schema. Client can then
actually use SOAP to call one of the functions listed in WSDL [6].
12
3.3.1.4. Universal Description, Discovery, and Integration (UDDI)
UDDI is a platform-independent, XML based registry for businesses worldwide to list
themselves on the internet. A UDDI business registration consists of three components:
White Pages, Yellow Pages and Green Pages which makes it one of the core webservices
standards. Each component contains different essential information about the webservice.
White Pages contain address, contact, and known identifiers, Yellow Pages contain the
information about industrial categorizations based on standard taxonomies; and Green
Pages contain the technical information about services exposed by the business. It is
designed to be interrogated by SOAP messages and to provide access to Webservices
Description Language documents describing the protocol bindings and message formats
required to interact with the webservices listed in its directory [6]. Business analysts and
technologists use UDDI to discover available webservices by searching for names,
identifiers, categories, or the specifications implemented by the webservice.
3.3.2 Webservice Invocation
We have to first find a Webservice that meets our requirements. We do this by contacting
a UDDI registry which tells us what servers can provide this service. Once the location of
the service is known, we then request for the information of how to invoke the service.
The webservice replies a WSDL document which contains information about how to
contact the webservice, the format of request messages in XML schema, available
methods and the necessary parameters for these methods. The client has to then create a
SOAP message according to the XML schema and sends the request to the service with
the help of transmission protocols like HTTP, SMTP or FTP. The entire process of
webservice invocation is shown below in Figure 3.
13
Figure 4: Webservice Invocation [6]
14
CHAPTER 4 - TOOLS AND TECHNOLOGIES USED
To develop the web-application as well as to integrate ASP.NET presentation tier
with J2EE business tier, the following tools and technologies were used: Microsoft
Visual Studio .NET 2005, J2EE, IIS 5.0 server, Sun Java System Application Server 9.0,
Enterprise Java Beans 3.0, Microsoft SQL server 2005, Net Beans IDE 5.5, XML,
Webservices, AJAX and JavaScript.
4.1 ASP .NET 2.0 and Microsoft Visual Studio 2005
ASP.NET 2.0 with VB.NET was used as the language to develop the presentation tier
and some part of the business tier. Microsoft Visual Studio 2005 was the tool used for
programming in VB.NET. Visual Studio 2005 which is an advanced integrated
development environment (IDE) developed by Microsoft for building applications that
run on Microsoft Windows and the World Wide Web helps in building attractive web
pages faster and easier, and also provides built in support for XML parsing. ASP.NET 2.0
is a technology for building powerful, dynamic web-applications and is part of the .NET
framework 2.0. It makes web-programming a lot easier when compared to programming
with technologies like ASP, JSP, and PHP etc. ASP.NET 2.0 introduces several new
server controls that enable powerful declarative support for data access, login security,
wizard navigation, menus, tree-views, etc. It also provides a new feature called Master
Pages where we can have the ability to define common structure and interface elements
for your site such as page header, footer, or navigation bar in a common location called a
“master page”, to be shared by many pages in your site. This improves maintainability of
your site and avoids unnecessary duplication of code for shared site structure or behavior.
15
Besides, ASP.NET also provides features like Themes and Skins, Personalization and
Localization and has improved caching, performance and scalability. In fact, web-
applications can be built easily with ASP.NET 2.0 than with ASP.NET 1.1. It has built in
support for AJAX.
4.2 IIS 5.0 Server
The web-application uses IIS 5.0 as the web server. Internet Information Services (IIS) is
a set of Internet-based services for servers using Microsoft windows. It provides a highly
reliable, manageable infrastructure for web-applications. It is a high-performance, secure
and extensible Internet server provided by Microsoft. IIS 5.0 is built on features and
capabilities needed to deliver web-applications required in an increasingly Internet-
centric business environment [3]. It is easy to install, maintain and has features that make
it reliable and better performing. The disadvantage with IIS server is that it can handle
only limited number of browser connections which can make testing difficult.
4.3 Sun Java System Application Server Platform Edition 9
Sun Java System Application Server, part of the Solaris Enterprise System provides a
platform for developing and delivering server-side Java applications and Webservices. It
enables developers to rapidly deploy secure SOA and Web 2.0 applications [5]. It is
compatible with JAVA EE 5 which can help improve developer’s efficiency and is also
EJB 3.0 compatible server which reduces the amount of coding that has to be done by
approximately 30%-90%. It has extensible and flexible framework that simplifies the
building of interfaces for user-based web-applications. It also extends the ease of
deployment with an option for startup using on-demand initialization. It is derived from
16
Glass Fish open source project, and has additional features that make building robust. I
have used this server for hosting the EJB’s and Webservices of the web-application.
4.4 Enterprise Java Beans 3.0
EJB 3.0 was mainly developed to ease the development of Java EE 5 platform and has
many simplified API’s. EJB provides us with the benefits of automatic management of
transactions, security, scalability, concurrency, distribution, portable environment access,
persistence, and so on [5]. Java Persistence API provides a light-weight persistence API
and incorporates features that include support for improved object modeling, inheritance,
polymorphism, expanded query language and rich metadata for the specification of
object/relational mapping. EJB 3.0 has two components namely: Session beans and
Entity beans.
4.4.1 Session Beans
A Session Bean is a type of enterprise beans which is created by a client and usually
exists only for the duration of a single client-server session. It performs operations for the
client. Session bean objects either can be stateless or can maintain state across methods
and transactions. Although they can be transactional, it is not recoverable should a system
crash occur.
4.4.2 Entity Beans
An entity bean is a type of enterprise beans which represents persistent data maintained in
a database. Beans which can manage their own persistent state are said to be using Bean
Managed Persistence (BMP) and beans which manage persistence with the help of the
17
container are said to be using Container Managed Persistence (CMP). An entity bean is
identified by a primary key and is superseded by Java persistence API in EJB 3.0.
4.5 NetBeans IDE 5.5
NetBeans IDE is an open-source IDE developed in Java using NetBeans platform, which
is a reusable framework used for simplifying other desktop applications. It provides
developers with all the tools they need to create professional cross-platform desktop,
enterprise, web and mobile applications. NetBeans IDE 5.5 extends the existing Java EE
features. It supports the Java Enterprise Edition 5 platform, and most notably the Java
Persistence, EJB 3 and JAX-WS 2.0 specifications. NetBeans5.5 has support for
Enterprise Java Beans 3 session beans and facilitates for simplified development of
session beans and message driven beans. It has enhanced Java source editor with code
completion, error checking, and hints specifically targeting EJB 3 [7].
4.6 Webservices and XML
A webservice acts as an interface between two different platforms. It is a software system
designed to support interoperable machine-to-machine interaction over a network. As the
data may not be consistent, XML is used to wrap the data that is being sent across the
platforms and provides a text-based support for application of tree-based structure to the
information. All information manifests as text, combined with markup that indicates the
information's separation into a hierarchy of character data, container-like elements, and
attributes of those elements [6]. Data is 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, we use XML extensively to wrap the data.
18
4.7 AJAX
AJAX is an acronym for Asynchronous JavaScript and XML, which is used to design
interactive and responsive web-applications. It provides client the ability to communicate
with server asynchronously, thereby freeing the user experience from the request-
response cycle. With AJAX, when a user clicks a button, you can use JavaScript and
DHTML to immediately update the UI, and spawn an asynchronous request to the server
to perform an update or query a database. When the request returns you can use the
JavaScript and CSS to update UI accordingly without refreshing the entire web page.
This increases the web page's interactivity, speed, and usability. Most importantly, users
don’t even know that your backend logic is communicating with the server.
Communication between client and server is done through XML. It is not a technology
all by itself but a group of technologies. The basic technologies are
XHTML and CSS for Standards- based presentation.
DOM (Document Object Model) for dynamic display and interaction.
XMLHttpRequest for Asynchronous server communication.
JavaScript for binding client-side data together.
It is used in the project for making some of the functionalities more responsive
and interactive. To implement AJAX, I installed Atlas, a free plug-in provided by
Microsoft. By tagging the Visual Studio 2005 Toolbox to Microsoft.Web.Atlas.dll we get
full features of Atlas inside the Visual Studio IDE. In my project, AJAX was used to
display the cover page images of Books available with the library.
19
4.8 JavaScript / DOM
JavaScript is the popular Netscape – developed object scripting language used in millions
of web pages and server applications worldwide to improve the design and client-side
validation of forms, etc. It works in most of the browsers such as Internet Explorer,
Mozilla Firefox, Opera and Netscape. DOM allows parsing HTML or XML into a well
defined tree structure and operating on its contents by providing an object oriented
application programming interface. I have used JavaScript to do some client side
validation and alert the user in a pop up message box wherever necessary.
4.9 Microsoft SQL Server 2005
Microsoft SQL Server is a relational database management system provided by
Microsoft. Its primary query language is Transact-SQL, an implementation of the
ANSI/ISO standard SQL. It can hold large amounts of data needed for real world web-
applications. It provides a GUI which makes it easy to play with the data. It also has
inbuilt Query Designer where we can debug and execute our SQL syntax and queries.
.NET framework 2.0 provides SQL Server with features like SqlCacheDependency,
membership, role and session state providers etc.
20
CHAPTER 5 – IMPLEMENTATION
The main purpose of this project is to evaluate the feasibility of the
interoperability for integrating a web-application’s existing business logic in Java EE
platform with a .NET presentation tier. For this purpose, a fully functional library web-
application was first developed in Java EE platform and then its presentation tier is later
developed in ASP.NET.
5.1 System Architecture
Figure 5: System Architecture
Browser
User
User Activity
Front
End
HTML
CSS
IIS Server 5.0
Code Behind
AJAX Server Pages
ADO. NETSun Java
System
Application Server
XML
Webservice
EJB’s
SQL
Server
2005
JDBCFunction call
Webservice call
Webservice call
21
The heterogeneous architecture of the web-application is shown in Figure 5. The user
contacts the server through the browser, by invoking a VB.NET function in the code
behind which causes a request to be sent to the server. Alternatively, the browser can call
the AJAX Server Pages directly. Both these invocations result in a call to the
corresponding webservice that resides on the Sun Java System Application Server. The
enterprise session bean which was called by the webservice uses JDBC connection to
connect with the database, fetches data from the database and converts into XML string.
The webservice then returns the XML string to the control that invoked the webservice.
At the IIS server end, the data is processed using a dataset and displayed to the user. The
EJB does entirely handle the business logic without any role for ADO.NET.
5.2 Use Case Diagram
The use case diagram for the application is shown in Figure 6. The user can register with
the website and then login to the website. The user can do some basic and advanced
search for finding the library material he needed. The user can place a hold on an item so
that the item would be reserved exclusively for him/her for a certain period of time. The
user can login to his account, check the list of items checked out and held with his
account and update his profile.
The administrator can login to the website and has specific permissions to add, edit or
delete items in the library material information database. The administrator can perform
actions on user accounts such as delete a user account, make changes to the transactions
of an account, etc.
22
Basic/Advanced Search
User Admin
Login
Register
View/Update Profile
View Account History
Place item hold
Add/Edit/Delete Items
Modify User Accounts
Figure 6: Use Case Diagram.
5.3 Class Diagram
In the class diagram shown in Figure 7, the Database class is the main class that has
operations that different users with differing roles perform on it. A user, with his
username and password, can register, login, edit/update profile, search items and place
item holds. Similarly the administrator has permission to do various operations on the
database like insert new items into the database, edit or delete items, modify account
23
activity. The Database class performs all the above operations on the classes that actually
hold the data, Books, Journals, Media, etc.
Database
SearchQuery()InsertNewItems()CreateNewUser()ModifyAcctActivity()EditProfiles()EditItems()DeleteItems()PlaceItem_holds()DisplayCoverPage_Images()
Books
Item_IDISBNTitleAuthorPublisherPublication_YearLocationAvailability
Journals
Item_IDISSNTitlePublisherPublication_YearLocationAvailability
Media(CD,DVD)
Item_IDTitleArtistRelease_YearLocationAvailability
Search
FindItems()GetCoverImage_IfBook()
Administrator
User_IDPasswordEmail
Login()ManageUser_Account()Add/Edit/Delete_Items()
User(Student/Staff)
User_IDPasswordDegreeEmail
Login()Register()Edit/Update Profile()Search_Items()PlaceItem_holds()
Figure 7: Class Diagram
24
5.4 Database Schema
Artist_detailsartist_id
artist_lastname
artist_firstname
artist_middleinitial
Artist_listitem_id
artist_id
Author_detailsauthor_id
author_lastname
author_firstname
author_middleinitial
Author_listisbn
author_id
BookCopiesitem_id
isbn
Booksisbn
title
subject
pub_year
pub_id
image_link
Ebooksisbn
title
subject
year
url
Ejournalsissn
title
subject
year
pub_id
url
Items_chkdoutitem_id
student_id
issue_date
due_date
Mediaitem_id
title
year
category
Myaccountstudent_id
first_name
last_name
middle_init
user_id
pwd
degree
email_id
pwd_hint
hint_ans
fines
Papercopiesitem_id
issn
Papersissn
title
subject
year
pub_id
pub_detailspub_id
pub_name
Ebooks_auth_listisbn
author_id
Ebooks_auth_detailsauthor_id
author_lastname
author_firstname
author_middleinit
Item_holdsitem_id
student_id
hold_date
expiry_date
Locationsitem_id
location
Figure 8: Database Schema
25
The database schema for the web-application is given in the Figure 8 above. All the
relations between tables are also shown in the figure. The primary keys for each table are
shown with a symbol of “key” beside that particular column in the table. The primary
tables in a foreign key relation can be easily identified with the “key” symbol i.e. if a
table having a relation with another table has the “key” symbol pointing to it, is called a
primary table, and others are child or secondary tables.
5.4.1 Database tables
There are around 15 tables in the database and the total records in the database are around
30,000. Each table in the database is described below:
a. The “Books” table has the data of all the books available with the library. Each book is
referenced by a unique value for “isbn”. Each book has a cover page image associated
with it.
b. The “Papers” table has the data of all the journals available with the library. Each
journal is referenced by a unique value for “issn”.
c. The “Media” table has the data of all the electronic media items i.e. CDs, DVDs, and
Tapes. Each media item in the table is associated with a unique value for “item_id”.
d. The “BookCopies” table holds the data of all the duplicate copies of books in the
“Books” table, each referenced with a unique “item_id”.
e. The “Papercopies” table has the data of all the duplicate copies of journals in the
“Papers” table, each copy having a unique “item_id”.
f. The “Author_list” table has the data of list of IDs of the list of authors for each book in
the “Books” table.
26
g. The “Author_details” table holds the data for names of each author of each book in the
“Books” table.
h. The “Pub_details” table has the data of all the names of the publishers for each book
and journal in the “Books” and “Papers” table respectively.
i. The “Artist_list” table has the data of list of IDs of list of artists for each media item in
the “Media” table.
j. The “Artist_details” table has the data of the names of each artist of each media item in
the “Media” table.
k. The “EJournals” table has the data of all the journals available online through web
supplied with their URLs.
l. Similarly, the “EBooks” table holds the data of all the books available online through
web provided with their URLs.
m. The “EBooks_Auth_List” table is similar to the “Author_list” table except the
EBooks are available only online.
n. The “EBooks_Auth_Details” table is similar to the “Author_details” table with the
author details of the each EBook.
o. The “My Account” table has the data of all the users registered with the online account
system of the library. Each user is distinguished by a unique “student_id”. Each user has
some unpaid dues if any incurred due to late returns or damage of the items.
p. The “Item_holds” table has data of all the items held by different students for future
check-out. Each item in this table has a hold expiry date until which the user can hold the
item.
27
q. The “Items_chkdout” table holds the data of all the items checked-out by different
students associated with a student id. Each item in this table has due date, after which the
user is incurred with some amount of fine if not returned.
5.4.2 Intermediate Datasets
A middle tier between SQL server database and the IIS server is implemented using
datasets for intermediate processing of the data fetched by the IIS server. The advantage
of using datasets is that we can reduce the communication between the IIS server and the
database server to a minimum so that we don’t have to query the database every time an
event in the business logic is triggered. Fetching the data at once and storing in datasets
makes it easier to reuse the same data for other triggered events. Since the datasets reside
on the IIS web server there is no extra communication between the web server and the
SQL database server, there by increasing the performance of the website. This is a simple
strategy from the programmer point of view for increasing the performance on the base
level. Advanced performance improvements can be done with enhancing the design of
database and other technologies.
5.5 Functionality
From the home page the user can access different functions through the links provided on
the page. Following are some of them:
5.5.1 User
The following are the functionalities of a user browsing the web-application. The user has
limited permissions respective to the whole functional unit of the web-application:
28
Search Items: User can navigate to the search page where he can input some search
arguments and configure the search by search indicators like title, author, publisher, etc.
For example, user may wish to search for a book or journal available in the online library
database. He can select the options of searching by title, isbn, author, publisher or
location, etc. He may also wish to search for media items based on similar search
indicators.
Ajax bound search results: Whenever a user searches for a particular item, all items
similar to the searched item are displayed in the search results. By saying similar, I mean
items with some resemblance in title, author, publisher, etc. User is provided with a nice
feature of grouping the search results so that user may not have to navigate back and forth
between pages to identify the item he is looking for, in the search results.
At this point, we may want to make things easier for user in identifying the item he
wants. So in addition to the details of the item, we give the user an option of looking at
the cover page image of the item (for books only). This feature is implemented with
AJAX so that user doesn’t even know the interface is communicating with the web
server. Only a partial update of the page is done with sending information to the server
behind the scene. This reduces numerous navigations back and forth between the web
pages.
Item hold requests: After finding the item user has been looking for, he can place a hold
on it for future check-out. By doing this user would be ensured with guaranteed
29
availability during check-out at the library. For this user needs to log in with his library
account.
Electronic resource access: User might want to refer electronic resources publicly
available like EBooks, EJournals, etc. on web by searching in e-resource library. In
addition to the normal search described above, user has the option of exclusively
searching with the starting letter of the title of the resource i.e. the user need not give any
search argument, can instead click the alphabet links available on the page. Each alphabet
stands for resources with title starting with that alphabet.
User Account: As described earlier, each user has to register with the website in order to
utilize the functionality of the online library. In order to perform certain actions like
placing and removing hold on an item, edit and update his/her profile the user need log in
first.
5.5.2 Administrator
The following are the responsibilities of the administrator with all permissions to access
and modify the database, user accounts, etc:
Add/Edit/Delete Items: The administrator has exclusive rights to add, edit, and delete
items into the database. For example, if a new edition of a book is available with the
library, then the administrator adds it to the Books table in the database. Similarly, if a
book is lost then that has to be removed from the database. The admin functionality
works in such a way that user doesn’t really see the admin page. Only when the
30
administrator logs in with his user id and password he will be able to see the page with
functionality defined for him.
Modify User Accounts: The administrator would be able to modify user accounts like
adding fines and dues to a user account, removing items from the checked-out list of the
user, send email notifications to user, etc.
5.6 J2EE Webservices
All the business logic residing in the Sun Application Server is exposed as webservices
that can be accessed from the .NET client. Following are those:
Search Items Webservice: The webservice provides the web methods that implement
the functionality of querying the database with the search criterion selected by the user.
The user’s search criterion is given as inputs to the web methods in this service and these
web methods build queries retrieves data from the database.
ESearch Items Webservice: The webservice provides the web methods that retrieve
data from the database for electronically available items in the library such as online
books, journals, etc.
Item details Webservice: The webservice retrieves the details of each item selected by
the user from the search results display grid. The initial search results only display certain
attributes of an item like title, ISBN, etc. But to look at the details of the item and place a
hold on it this webservice is invoked by the client.
User Authentication Webservice: The webservice has web methods that implement the
user authentication verification logic and user account retrieval logic. When a user logs in
to the website, this webservice is invoked.
31
CHAPTER 6 – WEB-APPLICATION TESTING
Since the two web servers- IIS and Sun Java Server and the SQL Server database
are hosted on a local machine, testing is done on the same machine. The configuration of
the system is shown below:
Processor Intel Pentium(M)
Processor Speed 1.66 GHz
Physical Memory 1.0 GB RAM
Operating System Windows XP Professional
Table 1: System Configuration
6.1 Unit Testing
The performance of a web-application mainly depends on how well the business logic
provides the requested services to the client. To test whether the business logic satisfies
the requests of the client, functional testing shall be performed on the business logic.
Testing the webservices can be done in two ways: testing them at the Java Server end
using JUnit or testing them at the client side using NUnit. We consider testing at the
client side because the webservices are consumed at the client side. I have used NUnit 2.2
for testing the webservices at the client side. NUnit 2.2 is an excellent unit-testing
framework for all .NET languages. It is written in C# and has been completely redesigned
to take advantage of many .NET language features, for example custom attributes and
other reflection related capabilities [8]. For NUnit testing, we have to create test cases for
the functions to test in our web-application. We have to compile our project once we are
32
finished writing test cases and load the project DLL file into NUnit GUI. The NUnit GUI
shows all the test cases we have written for our web-application, in a hierarchical view.
We can then run these test cases and check for running or failing test cases. A total of 11
test cases are written using C# in ASP.NET.
a. TestLoginWebService: Verifies the authentication of the user given username and
password as inputs.
b. TestValidAuthorWebservice: Tests the webservice if it returns the corresponding
author name of a book correctly from the database.
c. TestValidChkdItemsWebservice: Tests the webservice that returns the details of the
checked out items from a user account.
d. TestValidDuesWebservice: Verifies the correctness of the amount that was due as fines
for a user account, returned by the webservice.
e.TestValidEBookAuthorWebservice: Tests the webservice if it returns the corresponding
author name of an online book, given the title as input.
f.TestValidEBookSubjectWebservice: Tests the webservice if it returns the corresponding
title of an online book correctly from the database, given the subject as input.
g. TestValidJournalISSNWebservice: Tests the webservice whether it returns a valid
ISSN for a journal from the database, given title as the input.
h. TestValidHoldItemsWebservice: Tests the webservice of it returns a valid list of items
temporarily held by a user account on a given a username.
i. TestValidISBNWebservice: Tests the webservice whether it returns a valid ISBN for a
book, given title as the input.
33
j. TestValidItemIDWebservice: Tests whether the webservice returns the corresponding
itemid of a particular item, title as the input.
k. TestValidTitleWebservice: Tests whether the webservice returns the corresponding
title of a particular item, given itemid as the input.
The test results for the above test cases are shown below in Figure 9:
Figure 9: NUnit test results screenshot.
34
6.2 Performance Testing
Performance of a web-application under various loads and user traffic is critical for
efficient functioning of any web-application. Indirectly the performance of the web-
application is proportional to the performance of the web server in responding to the user
requests without a bottleneck. For evaluating the performance of the .NET – J2EE
integrated web-application we need to focus on the Sun Application Server response
when any of its webservices are invoked. The performance of the .NET -.NET web-
application depends on the performance of the ADO.NET calls to the SQL Server
database from the IIS Server.
6.2.1 Load testing using Web Server Stress Tool 7
WebServer Stress Tool is a powerful HTTP-client/server test application designed to
pinpoint critical performance issues in your web-application or web server that may
prevent optimal experience for users. WebServer Stress Tool simulates many numbers of
users accessing web-application at the same time. This quickly and easily demonstrates
the performance capabilities of the infrastructure. By simulating the HTTP requests
generated by hundreds or even thousands of simultaneous users, we can test our web
server performance under normal and excessive loads to ensure that critical information
and services are available at speeds our end-users can expect [9].
The test is simulated with 10 clients virtually making a maximum of 10 requests (or
clicks) to the web-application. Both the .NET -.NET and .NET – J2EE applications are
tested to pinpoint performance issues that make one better than the other.
35
6.2.1.1 Analysis of test results
The test results and their analysis of both .NET - .NET and .NET – J2EE applications are
given below:
Average click time per user: The terms- Click, Hit, and Click-time to be used in this
section are defined below:
a. Click – A simulated mouse click of a user sending a HTTP request, for example,
clicking a URL, to the server and immediately requesting any necessary redirects,
frames and images.
b. Hit – A completed HTTP request i.e. request sent to the server and got response
completely. Hits can be a Page request of a “click” or its frames, images, etc.
c. Click-time – The time a user had to wait until his “click” was finished including
redirections, frames, images, etc.
The test is simulated with a maximum of 10 users each making a certain number of
requests (or clicks) to the web-application. The simulation starts with 1 user making
around 10 requests and the number of active users ramp up to 10 where each make
multiple number of requests at a time. Average click time is then calculated in
milliseconds. The test is simulated for both .NET - .NET and .NET – J2EE applications.
The test results for the application having .NET - .NET architecture are shown below in
Table 2:
36
.NET - .NET application
User No. Clicks Hits Errors Avg. Click
Time [ms]
Bytes kbit/s Cookies
1 10 9 0 15 94,239 5,480.84
2 10 9 0 15 92,502 5,415.80
3 9 8 0 20 129,664 6,479.06
4 8 7 0 20 113,925 6,514.35
5 7 6 0 17 66,390 5,246.53
6 6 5 0 15 52,355 5,432.13
7 6 5 0 13 51,390 6,142.33
8 5 4 0 20 64,832 6,480.82
9 4 3 0 22 48,825 6,026.80
10 3 2 0 17 22,130 5,066.26
Table 2: Average click time (in milliseconds) per user for .NET - .NET application
The test results for the application having .NET – J2EE architecture are shown in the
Table 3 below. As we observe the average click-times of both the applications, we see
that .NET - .NET application has a good response time when compared to the .NET –
J2EE. But .NET – J2EE response time is not worse as compared to the homogeneous
architecture. The heterogeneous architecture responded as good as the homogeneous one.
37
.NET – J2EE application
User No. Clicks Hits Errors Avg. Click
Time [ms]
Bytes kbit/s Cookies
1 13 12 0 45 123,648 1,819.66
2 12 11 0 16 115,610 5,262.41
3 11 10 0 25 162,470 5,116.92
4 10 9 0 18 146,826 7,120.69
5 9 8 0 29 23,174 790.28
6 8 7 0 13 72,128 6,118.83
7 7 6 0 16 63,060 5,365.97
8 6 5 0 20 81,235 6,661.21
9 5 4 0 18 65,256 7,206.02
10 4 3 0 17 9,831 1,548.36
Table 3: Average click time (in ms) per user for .NET – J2EE application
Transferred data between client and server: The operations between client and server
include data transfer between them when a client sends requests to the server. To analyze
the performance of a web-application, a critical performance metric would be to measure
the data transfer rate between client and server. The data transfer rates between both
client and server in both the architectures are shown below in Figure 10 & 11:
38
.NET - .NET application
Transferred Data & System Memory & CPU Load
User Simulation: ramp test with up to 10 simultaneous users - 20 seconds between clicksTest Type: RAMP (run test for 3 minutes)
System Memory [MB] Network Traffic [kbit/s] Local CPU Load [%]
Time since start of test [s]170160150140130120110100908070605040302010
Active Users0 1 1 2 2 2 3 3 3 4 4 5 5 5 6 6 6 7 7 7 8 8 9 9 9 10 10 10 10 10 10 10 10 10 10
Ava
ilabl
e Sy
stem
Mem
ory
[MB
]
500
499
Transferred Data [kbit/s]
70
60
50
40
30
20
10
0
Local CPU
Load [%]
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
Figure 10: Data transfer rate (in Kbits/s) for .NET - .NET application
.NET – J2EE application
Transferred Data & System Memory & CPU Load
User Simulation: ramp test with up to 10 simultaneous users - 15 seconds between clicksTest Type: RAMP (run test for 3 minutes)
System Memory [MB]������ Network Traffic [kbit/s]������ Local CPU Load [%]������
Time since start of test [s]170160150140130120110100908070605040302010
Active Users0 1 1 2 2 2 3 3 3 4 4 5 5 5 6 6 6 7 7 7 8 8 9 9 9 10 10 10 10 10 10 10 10 10 10
Ava
ilabl
e Sy
stem
Mem
ory
[MB]
238
237
236
235
234
Transferred Data [kbit/s]
1301201101009080706050403020100
Local CPU
Load [%]
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
Figure 11: Date transfer rate (in Kbits/s) for .NET – J2EE application
39
The above results show that in the .NET - .NET application the data transfer rate was
little lower than that of the .NET – J2EE web-application. This is due to the additional
XML tags that the J2EE server needs to build and transfer to the client in SOAP format.
Even though the J2EE server has the additional burden of composing the XML tags and
encapsulating data in them, user’s wait time is reduced by transferring the data at a higher
transfer rate.
6.2.2 Web Performance Testing using QEngine Server
To extensively test the performance of a web-application, we also need to test the
application about how it behaves on varying amount of load on the server and varying
amount of data transferred or downloaded from the server. The performance of the
application is critical when the number of users rise by time and the time a user need to
wait for each request to be satisfied by the server should also be considered.
Advent Net QEngine Server provides such kind of testing of web-applications. Advent
Net QEngine is a complete automated testing tool for functional testing, performance
testing, webservices testing and regression testing of web-applications and webservices
[10]. With QEngine we can also test the functionality of webservices, but we already
dealt with it in Unit testing. So lets focus on the web performance testing of both our
.NET - .NET and .NET- J2EE applications.
40
6.2.2.1 Test suites
Two set of test suites are prepared for testing both the applications, compare and pinpoint
the performance issues. Each test suite varies in terms of the amount of load on the
server, amount of data requested by the client, etc. To simulate the amount of data
requested by each client, a test page has been created which requests 100 KB, 500KB,
and 1.3 MB of data from server. Each test suite simulates the load on the server using the
number of simultaneous users and iterations setting available in the tool. The load on the
server is configured as light load and heavy load. Light Load on the server is simulated as
5 users, each making simultaneous requests to the server and carried on up to 5 iterations.
Heavy Load is simulated as 10 users, each making simultaneous requests and carried on
up to 10 iterations. For each business case, the mean page download time is calculated
6.2.2.1.1 Test suite 1
This test suite is used to test the performance of .NET - .NET application. The test suite
has 6 business cases where each differ in the amount of data requested or the amount of
load on the server. The following table describes the configuration of each business case:
Business case 1 Light Load 100 KB
Business case 2 Light Load 500 KB
Business case 3 Light Load 1.3 MB
Business case 4 Heavy Load 100 KB
Business case 5 Heavy Load 500 KB
Business case 6 Heavy Load 1.3 MB
Table 4: Test suite configuration for each of the applications
41
6.2.2.1.2 Test suite 2
This test suite is used to test the performance of .NET – J2EE application. The test suite
has 6 business cases with same configuration given in the above table. The client requests
data and the IIS server calls the EJB webservices from the Sun Application server. There
is an exchange of data from server to server. The data that is transferred between the Sun
server and IIS server is XML wrapped and the IIS server unwraps the data from the XML
and presents it to the client. So there is an additional over head of accessing the data from
the SQL server database and then wrapping it in XML. This is the key factor which
affects the performance of the .NET – J2EE application.
6.2.2.2 Analysis of Test results
The values for mean page download time for each business case are summarized in the
table below:
Mean Page download time for requesting 100 KB of data (in milliseconds)
Application Light Load Heavy Load
.NET Client - .NET business tier 441 1398
.NET Client – J2EE Webservices 7735 7935
Table 5: Mean Page download time for requesting 100 KB of data
Mean Page download time for requesting 500 KB of data (in milli seconds)
Application Light Load Heavy Load
.NET Client - .NET business tier 813 2332
.NET Client – J2EE Webservices 8072 8540
Table 6: Mean Page download time for requesting 500 KB data
42
Mean Page download time for requesting 1.3 MB of data (in milli seconds)
Application Light Load Heavy Load
.NET Client - .NET business tier 1484 6886
.NET Client – J2EE Webservices 9066 9575
Table 7: Mean Page download time for requesting 1.3 MB data
From observing the tabular results above, we see that the .NET - .NET application
perform well than that of the .NET – J2EE application. The .NET – J2EE application
performs 2 to 5 times slower than the .NET - .NET application. The reason for .NET –
J2EE application being slower than the other is that there is an overhead of wrapping the
data in XML tags by EJB’s. The EJB’s has to make a database access and then convert
the retrieved data to XML using the XML DOM Transformer. This XML is sent to the
IIS server and the XML is unwrapped by using the XML Document class. Another factor
that degrades the performance of the heterogeneous application is the fact that the test is
simulated on a machine having limited amount of physical memory. Running the .NET-
J2EE application requires VS.NET 2005 and NetBeans IDEs, IIS & Sun Application
servers to be on run. So eventually the physical memory of the machine is occupied to its
full capacity, in this case 0.99GB of 1 GB memory is occupied. The processor therefore
uses part of the hard-disk of the machine as virtual memory. This results in frequent
read/write actions back and forth between physical memory and hard-disk, which causes
the application to take longer time for downloading data than it usually takes in abundant
resource scenarios This whole process in fact degrades its performance. A clear
comparison of both loads can be drawn from the Figures 12 & 13 given below:
43
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
100 KB data 500 KB data 1.3 MB data
.NET - .NET .NET - J2EE
Figure 12: Comparison for light load simulation (Data Vs Download time in
ms)
0
2000
4000
6000
8000
10000
12000
100 KB data 500 KB data 1.3 MB data
.NET - .NET .NET - J2EE
Figure 13: Comparison for heavy load simulation (Data Vs Download time in
ms)
44
Interestingly the page download time for the .NET- J2EE application does not vary much
unlike the .NET-.NET application when the amount of the data to be downloaded
increases. This type of behavior may depend on the functioning of JDBC database
connection components used in EJB’s.
6.2.2.3 Reasons for low performance of the .NET-J2EE application
From the test results and analysis above, we observed that though .NET-J2EE application
does the same task as that of the .NET-.NET application it is not sufficient to state that
interoperability is always a good choice for migrating the application to another platform.
We need to consider certain factors that influence an interoperable design before
choosing adapt it on our design.
A webservice call from IIS server to Sun Application server in the heterogeneous
application can be visualized as follows: the server code in IIS server invokes a
webservice for a certain action, the webservice calls the enterprise bean that does this
action providing to it the inputs obtained from the webservice call. The enterprise bean
connects to the database and fetches the requested data. The enterprise bean then converts
this data into XML by wrapping it in XML tags and sends the XML string to the server
code that called the webservice. The server code un-wraps the data from XML tags and
does the processing. Since the .NET-J2EE application requires more physical memory as
discussed in the previous section, it occupies most of the memory available and therefore
the processor has to use virtual memory. As a result some part of the webservice call also
includes thrashing where very frequent read/write actions are to be done back and forth
45
between the physical memory and machine’s hard-disk, during fetching data from the
SQL server database and also while converting data to XML.
To identify the effect of thrashing on the application’s performance, the webmethods in a
webservice residing in the Sun Application server are benchmarked during data fetch
from database and converting the fetched data to XML. To analyze the behavior of a
webservice when the amount of data fetched from database increases, three different
inputs are given that make the webmethod to fetch approximately 100KB, 500KB and
1.3MB of data from the database. The webservice is tested under two conditions:
sufficient resources available on the machine and a condition which leads to thrashing i.e.
the available resources are very scarce. Figure 14 shows the results of the testing which
identifies how much execution time of a webservice call is affected due to thrashing.
The webservice call is tested in the contexts of both interoperability i.e. .NET-J2EE
application and as a standalone EJB method where the latter scenario occupied only one-
fourth of the physical memory to that of the former. The latter scenario requires less
memory because the webservice is tested as a standalone java method which fetches data
from the database and converts it into XML. It does not require any of the IIS or Sun
Application servers, or VS.NET 2005 IDE to run. In the former context, thrashing occurs
due to less memory available on the machine. As we observe the above chart, a
significant percentage time of a webservice call is wasted because of thrashing. For
example while fetching 500KB of data from the database, 10% of the webservice
execution time is wasted due to thrashing. Also 30% of the webservice execution time for
XML conversion is affected by thrashing. As a result the page download time increases
steeply for the .NET-J2EE application when compared to the .NET-.NET application.
46
0
250
500
750
1000
1250
1500
1750
2000
2250
2500
2750
3000
3250
3500
3750
100KB 500KB 1.3MBAm ount of data querie d in the w ebservice call
w ebservice execution tim e (in m illiseconds)
Database access Thrashing during data fetch XML Conversion Thrashing during XML conversion
Figure 14: Comparison showing effect of Thrashing during a webservice call
It is therefore needed to consider the resources available to decide the need of an
interoperable solution to incorporate .NET features into an existing J2EE based web-
application.
47
6.2.2.4 Summary of Test results
From the discussion and analysis above we see that .NET-.NET application performs
better than .NET – J2EE application in terms of mean page download time because it
requires less amount of computing resources as compared to the .NET-J2EE application.
But there are certain factors which reason why .NET–J2EE application has poor
performance metrics than its counterpart. Some of these are the additional overhead of
data wrapped into XML by the EJB’s in a webservice and unwrapping at the .NET side.
Also, IIS server and Sun Application server both reside on the same local machine and
occupy the RAM of the machine to its full capacity. The .NET - .NET application needs
only the IIS server to be functional whereas .NET –J2EE application requires both IIS
and Sun Application Server to be active. As a result the processor would not have enough
physical memory available and so has to use the virtual memory from the hard drive of
the machine. This forces the processor to do very frequent read/write actions on the data
back and forth between physical memory and hard drive. Hence a significant percentage
of the mean page download time for a particular amount data download or search query is
consumed totally due to thrashing.
Though .NET - .NET application performs better than its alternative, it is not on par with
that of .NET-J2EE application when amount of data retrieval increases enormously. In
cases where the amount of data retrieval increases, .NET – J2EE application performance
shows very little deviation when compared to .NET - .NET application. We might predict
the reason for this behavior to be that the ADO.NET data connection components used in
.NET for database access might not be optimized for large amounts of data retrieval as
compared to JDBC connectivity components in Java.
48
Since the test simulation is done on a local machine where both IIS, Sun server, Visual
Studio 2005 and other testing tools were running, during which the amount of physical
memory available for processing is scarce, resource availability plays an important role in
the performance of a heterogeneous web-application developed using interoperable
techniques. Moreover, the .NET-J2EE application has an additional overhead of
wrapping XML data at the Sun server end and unwrapping at the IIS server end. This
might seriously account to the performance of the application under scarce resources.
Considering these factors, we cannot just conclude that .NET - .NET application is
always better than the .NET – J2EE application. Given enough resources and based on
the complexity of the application the interoperable solution could be far better feasible
than going through the painful task of migrating the entire application to a single
platform, for integrating cross-platform applications i.e. .NET and J2EE.
49
CHAPTER 7 – PROBLEMS FACED AND PROJECT METRICS
7.1 Problems Faced
The very big task that I had to face while doing this project was to learn J2EE
concepts and webservices. Since I haven’t been introduced to Enterprise Java Beans
before, I really had a hard time learning the concepts of EJB’s and how they work. I had
to refer to lot of online tutorials with some programming examples. Writing and
deploying EJB’s as webservices is a very painful task. Lot of command line arguments
need to be supplied in order to build and deploy EJB’s onto the Java server. NetBeans 5.5
IDE was used to make this task easy. But a lot of effort is kept in learning how to use this
tool. This tool is very slow and consumes around 320 MB of RAM. This affected the
speed of my computer drastically.
While doing the project the Sun Application Server used to end its session automatically
after a certain amount of time. Due to this I always had to restart the server every time I
run the application.
For testing the performance of the web-application, I have used QEngine Server. But I
had to run each test case many times as the server used to get valid results.
50
7.2 Overall Experience
By doing this project I have learnt a totally new platform i.e. J2EE which I have a very
little knowledge about it in the past. This project exposed me to working with EJB’s,
writing complex session beans and entity beans. I got to know what are webservices and
how they are helpful in designing the data transfer format between cross platforms.
During the course of this project, I have learnt using various tools and technologies such
as Web Server Stress Tool, QEngine Server, NetBeans IDE which would be very useful
through out my career. I also have learnt various ways of rigorous testing of a web-
application and how performance issues can be pinpointed from the results. Overall, I
have realized the role of interoperability in building or integrating cross platform
applications.
7.3 Project Metrics
The tables given below are the metrics showing the time I have spent on this project and
the amount of programming I have done through out the project.
Sun Server and Net Beans IDE setup 3 -5 hrs
Learning EJB’s 80 – 100 hrs
Learning Net Beans IDE 7 – 10 hrs
Implementation 50 – 70 hrs
Testing 25 – 35 hrs
Documentation 15 – 20 hrs
Table 8: Time spent on the project
51
ASP.NET server side code 1400 lines
ASP.NET XML parsing 300 lines
EJB’s and webservices 2000 lines
Table 9: Lines of code
52
CHAPTER 8 – CONCLUSION AND FUTURE WORK
8.1 Conclusion
The aim of this project is to study the feasibility of an interoperable solution in
building or integrating cross platform applications. In this project, methods to consume
J2EE webservices from .NET presentation tier are implemented and evaluated the
performance against the homogeneous application i.e. .NET presentation tier and .NET
business tier. Performances of both applications are evaluated by rigorously testing them
against various test cases and under various resource availability scenarios by using
certain web-application testing tools.
From observing the performance results, the .NET – J2EE application is no less efficient
than the .NET-.NET application in terms of functionality. But performance is a key issue
for the heterogeneous application considering the fact that it occupies most of the
resources available for processing. The main overhead in the .NET-J2EE application is
that the data needs to be wrapped in XML tags before sending it to the .NET presentation
tier and then unwrap it from the XML tags at the client side and present to the user.
Though the comparison between both shows a significant difference in terms of
performance metrics such as page download time, server response time, there is one
encouraging factor that opens doors to some research work. When the amount of data
retrieval increases enormously, .NET - J2EE application shows less deviation in
performance than .NET - .NET application. Based on the discussion from the previous
section, this might be because the ADO.NET connections components used is .NET for
53
accessing database might not be optimized for large amount of data retrievals as
compared to JDBC connectivity components used in Java.
We therefore need to consider certain factors that might affect the performance of the
heterogeneous web-application before we make a choice of interoperability. Given
sufficient resources and depending on the complexity of the application, interoperability
would be a good choice for integrating cross platform applications, which is in fact less
time consuming and cheaper than the traditional method of migrating the entire
application to a whole new platform.
8.2 Future Work
Since both the IIS and Sun Application Server run on a single machine for this
project, it would be a good idea to run these servers on different machines which
saves a lot of system memory and improves the performance of the application
considerably.
A complete package of testing tools is required to test these applications as the
trial versions do not produce satisfactory results.
More rigorous testing should be done in order to simulate heavier user load on the
application. Trial versions of testing software only allow a limited number of
simultaneous users to the system.
54
REFERENCES
[1] Microsoft .NET and Java: Achieving Interoperability
http://www.devx.com/interop/Article/19928
[2] KSU Library Home page
http://www.lib.k-state.edu
[3] Basics of .NET and Webservices
http://www.microsoft.com/net/basics.mspx
[4] J2EE definition and Architecture
http://en.wikipedia.org/wiki/J2EE
[5] Sun Developer Network (SDN) home page
http://www.java.sun.com
[6] David Muldrow, Understanding Webservice Invocations. April 2002
http://www.research.ibm.com/journal
[7] NetBeans Home page
http://www.netbeans.org
[8] NUnit Home Page
http://www.nunit.org
[9] Web Server Stress Tool Home Page
http://www.paessler.com/webstress
[10] Advent Net QEngine Server download page
http://www.adventnet.com/products/qengine/index.html
Recommended