Distributed Web Application Development:

A Comparison of .Net and J2EE

Author A. Maddox and Staff Supervisor T. Roberts

Department of Electrical and Electronic Engineering

Manukau Institute of Technology
Auckland
E- mail: A.Maddox@xtra.co.nz, T.Roberts@manukau.ac.nz

Abstract
The purpose of this study is to compare the performance and code size of a distributed web application as
implemented in Microsoft .Net and Java 2 Enterprise Edition (J2EE). The defining feature of this
comparison is the common architecture that the .Net and J2EE applications share. The architecture used
follows a traditional three tier pattern that consists of Presentation logic, Middleware components, and
back -end persistence. The realization of a common architecture enables an “apples to apples”
comparison of the competing technologies that will reflect the performance of the platform, independent
of the implementation. In addition, the study compares and contrasts the .Net and J2EE blueprint
application known as the.Net Pet Shop amd Java Pet Store. The comparison considers the technologies
employed and the proposed architecture.

Keywords: Distributed, Web Application, .Net, J2EE, C#, Java, Software Architecture.

1. Introduction • Develop a distributed web application for

the .Net and J2EE platform that implements
Sun’s J2EE technology has arguably been the the same architecture and uses equivalent
leading platform for the development of web technologies.
based solutions. Now Microsoft has made a bid o Provide performance data reflecting
with its .NET programming platform. Both the applications ability to handle user
technologies provide the same function; a loads.
platform to facilitate distributed application o Compare the code size of each
development. implementation, as a measure of
This study compares distributed web application developer efficiency.
development on the .Net and J2EE platform, o Evaluate the applications dependency
focusing on the following objectives: on the underlying language
compilation and execution
• Compare and contrast the reference environment.
implementation for the .Net and J2EE
platform, detailing architectural
perspectives and technologies.

25
2. Analysis
To better understand the whole, one must look to
the constituent parts. This section decomposes
the reference implementation for the .Net and
J2EE platform, detailing architectural
perspectives and technologies.
2.1 J2EE Platform
The Java 2 Platform Enterprise Edition (J2EE) is
an industry standard for Java technology based
enterprise application development. Pertinent
technologies include Enterprise JavaBeans
components, Java Servlets API, JavaServer
Pages and XML technology.
To promote a consistent architectural vision
among the java developer community Sun
Microsystems have developed J2EE Blueprints.
The J2EE Pet Store is Sun’s blueprint for
implementing best practices in building web
applications. The architectural concept that is
central to this blueprint is the Model-View-
Controller (MVC) design pattern. This pattern
separates data presentation, data representation,
and application behaviour. Relating this to the
J2EE Pet Store; the Model is implemented as the
EJB components that represent the structure of
the data and the logic that governs access. The
View renders the data through presentation logic
in JSP, while the Controller defines the
application behaviour in the controller servlet.
The primary advantage of the MCV pattern is the
ability to support multiple views from the same
model.
JSP EJB Container
Oracle 9i
Custom EJB
Tags
EJB
Control EJB
Servlet
WEB TIER MIDDLE TIER DATA TIER
Figure 1: J2EE Blueprint Architecture
A Java Server Page (JSP) is an extensible web
technology, which provides a mechanism for
creating server-side web applications that
produce HTML content in response to a browser
client request. The content is generated through
the server side scripting language contained in
the requested JSP. This scripting language is a
combination of HTML and embedded
26
application logic. The HTML serves as a
formatting medium to specify the layout of the
page and provide static content. While dynamic
content is generated by the Java code embedded
in XML like tags and Scriptlets. Generally the
application logic is displaced from the JSP to
Java Beans.
The Java Bean component architecture provides
a mechanism to easily encapsulate the work
flow, data and page navigation logic associated
with a given JSP. The Java Bean is a simple
component model that conforms to the naming
and design conventions detailed in the JavaBeans
component architecture specification.
The JSP tag library facility allows developers to
introduce Custom Tags into their web
applications, providing better packaging over
traditional Scriptlets. A custom tag is realized as
a java class that implements a specialized
interface, generally an extension of the tag
interface. A tag library is defined by the
accompanying Tag Library Descriptor XML
document, which details the available tags. The
individual tags are then implemented in the JSP
through an XML based syntax that includes tag
library name the tag name and any parameters.
JSP technology includes an XML based
templating mechanism that allows for the
encapsulation of page layout. The concept is
similar to that of a layout manager used in
traditional swing based java applications. The
implementation uses a controller servlet to
respond to incoming HTTP requests and
construct the page based on the layout defined in
a template.
Finally, the client interaction with a JSP follows
a request response model where the initial
request results in the JSP being compiled into a
Java Servlets that renders the HTML. Any
additional requests will be served by the
compiled servlet.
An Enterprise JavaBean (EJB) is a distributed
object that contains properties and methods to
implement a unit of business logic. The EJB is
hosted in an EJB container that manages the state
of the Bean and its associated events at runtime.
The runtime events handled by the container
include: transactions, security and remote access.
While managing the state of the bean requires
persistence management and resource pooling.
Resource pooling refers to the management of a
Beans lifecycle and pooling instances to increase
performance. There are two basic types of
enterprise beans:
• Entity Beans represent the data in a
database in an object orientated manner,
hiding the complexity of the database. An
active entity bean will at any given time
persist the state of a row in a table of the
database.
• Session Beans represent processes; the
session bean generally acts as an agent for
the client performing operations on an
Entity Bean. Database interaction is
contained in the Session, where query
strings or prepared statements are
construction and subsequently executed
through Java Database Connectivity
(JDBC).
2.2 .Net Platform
Microsoft’s .Net initiative is realized in the .Net
framework, a programming model for building,
deploying, and running XML Web services and
applications. The .NET Framework consists of
two main parts: the Common Language Runtime
and a unified set of class libraries including
ASP.NET for Web applications and XML Web
services, Windows Forms and ADO.NET for
loosely coupled data access.
Web Services Web Forms Win Forms
Forms
Data / XML Classes
Base Framework Classes
Common Language Runtime
Base Framework Classes
System Services
Base Framework Classes
Figure 2: .Net Framework
Microsoft’s architectural vision for n-tier web
application development is promoted in their best
practices blueprint known as the .Net Pet Store.
The blueprint was developed to contrast the
architecture, programming logic and overall code
size of the J2EE implementation. Unlike its java
counterpart the .Net Pet Store doesn’t employ the
MVC design pattern as prescribed in the J2EE
blueprints. .Net promotes a light weight
componentized design based on stored
27
procedures and .Net managed components. This
allows for a significantly smaller middleware
footprint and clean encapsulation of database
access logic on the database. The .Net Pet Store
is distributed across the following tiers:
Presentation logic, Middleware components, and
back-end persistence.
Web Logic
Forms SQL Server
Components
2000
(C# Class
Library)
User
Controls
ADO.NET for Stored
Procedures
Data Access
WEB TIER MIDDLE TIER DATA TIER
Figure 3: .Net Blueprint Architecture
ASP.Net provides the presentation medium,
consisting of two modules one to render the
HTML the second provides a user interface
façade implementing workflo w and page
navigation logic in Code-Behind classes. The
middleware is implemented as .Net managed
components, which consist of manager and data
classes. A manager class contains functions that
wrap the stored procedure calls while the thin
data classes provide a loose binding between the
data and presentation tier.
The Common Language Runtime (CLR) is the
base of the framework, providing a code-
execution environment. Code that is run from
this environment is considered managed code;
this managed code is afforded the following
facilities through the runtime: Memory, Thread,
Security and Remoting management also
included is Code verification enforcing strict
safety and accuracy of the code Compilation.
The most promising feature of the CLR is its
ability to accommodate a multitude of
development languages. This is achieved through
the Common Type System (CTS) which defines
a pattern for managed code that basically
specifies a way in which types are created and
used. Language compilers that are targeting the
runtime are required to conform to this type
pattern.
The .NET Framework class library provides a
common set of classes that can be used in any
programming language targeting the CLR. The
library provides base functionality for IO,
Threading, Serialization, Remoting etc. The Data
/ XML classes extend the functionality of the
base classes to support data management and applications. A summary of the equivalent
XML manipulation. technologies is presented in figure 4, where an
equivalent technology is considered as that
Active Server Pages .NET (ASP.NET) is a server which is based on the same premise. This
side scripting environment much like its Java concept can be illustrated by contrasting the JSP
counterpart; JSP. It provides a mechanism for and ASP.Net frameworks; both provide a means
developing dynamic web content which is to develop a web application.
generated in response to an HTTP browser
request. The ASP.Net platform supports the Feature J2EE .NET
development of web forms and web services. Interpreter JRE CLR
Web Tech JSP ASP.NET
Web Forms employ a component based, event-
Base Web JSTL Web Form Controls
driven programming model that introduces
Custom Web Custom Tags User Controls
traditional form-based development to web
Middle Tier EJB Managed Components
applications. The notion of components is DB Access JDBC ADO.NET
introduced with web from controls, which wrap
Figure 4: .Net and J2EE Feature Summary
the underlying HTML form based constructs
such as <input type=”Radio”> into a more
consistent object model e.g. <asp: RadioButton>. 3. Results
Web controls serve as the building blocks for
web form development, with Visual Studio .Net With the emergence of Microsoft’s .Net
developers can simply drag web controls onto a platform, the .Net Pet Shop was developed to
form then write an event handler. The .Net contest the J2EE reference implementation
framework also supports custom controls that known as the Java Pet Store. “After
enable developers to extend control functionality benchmarking the .NET Pet Shop against
beyond the scope of the standard controls. Oracle's published performance results for its
Finally the performance of ASP.Net is greatly own J2EE Pet Store implementation, Microsoft
improved through simple page directives that pronounced the .NET implementation to be
enable simple and fragment caching. Simple or superior in terms of performance,
fragment caching refer to the storage of implementation costs, and developer efficiency
frequently used pages or user controls [1]”.
Response Time vs. User Load
respectively.
1400 J2EE Response Time
Per Page Avg. Response

The .Net framework manages database 1200 .NET Response Time

interaction through the class collection known as 1000

Time (ms)

800
Active Data Objects .NET (ADO.NET). To
600
improve scalability ADO.NET employs a
400
disconnected data model. This means that the
200
data retrieved from the database is isolated from
0
the database connection and is cached on the 0 500 1000 1500 2000 2500 3000 3500 4000
local computer. ADO.NET consists of two class User Load

categories: Data Provider and Dataset. The Data
Provider classes are tied directly to the database,
providing a means to establish database
connections, execute commands, read data and
populate data sets. The second class group
enables the disconnected model through the data
set and related classes.
2.3 Summary
Decomposing the .Net and J2EE technologies
has exposed common and contrasting attributes,
including the differing architectural visions
behind the development of the blueprint
Figure 5: Blueprint Performance Comparison [2]
The performance and developer efficiency deficit
that Microsoft identified is illustrated in figures 5
and 6 respectively. Subsequent to the publication
of Microsoft’s benchmark results several
contentious issues have arisen from the Java
developer community. In general the basis of the
controversy is the alternate perspectives on how
the technologies should be implemented.
Reflecting on the Blueprint Pet Store
comparison; “the .NET implementation was
performance-optimized for SQL Server through
the use of stored procedures, while Sun actively

28
discourages database tuning in the J2EE requests that are generated by recording a session
implementation in the interest of portability [1]”. of activities performed on the site.
16000 dotNET J2EE
14,273 The data from the user load benchmark indicates
14000 Lines of Code Required that the .Net Pet Store responds 1.8 times faster
12000 that J2EE implementation at the 450 user load
10000 level. Initially this appears to be a considerable
performance deficit, however in considering the
8000
5,891
5,404
time scale this represents just over 0.5 seconds.
6000
The performance benefits have been attributed to
3,484
4000 2,566 the use of Output caching in the.Net application.
1,881
2000 863 684412
The caching mechanism provides local storage of
56
0
dynamic content that does not need to be re-
Total Lines Web Tier Middle Tier Data Tier Config executed on every request.
of Code
Response Time vs. User Load
Figure 5: Blueprint Lines of Code Comparison [2] 2500
J2EE Response Time

Per Page Avg. Response

To address these issues this section presents the 2000 .NET Response Time
evaluation of the .Net and J2EE application,

Time (ms)
1500
which were developed to establish a benchmark
on a common architecture. In addition, the 1000

underlying language compilation and execution

500
environment of the .Net and J2EE platforms was
evaluated. For the details of the test system used 0
0 100 200 300 400 500 600
refer to Appendix 1. User Load

Figure 8: Performance Comparison

3.1 Common Architecture Benchmark
The comparison of the lines of code required to
To provide an “apples to apples” comparison of implement the solution provides an objective
the competing platforms, benchmarking must be measure of developer productivity. The code size
preformed on applications that employ a is relatively equal; the differences are due to
common architecture and implement equivalent minor implementation details. Illustrating this
technologies. The architecture used in the point; the web control implementation for J2EE
development of the new .Net and J2EE Pet requires that associated Meta data be defined in a
Store’s discards the notion of portability, instead configuration file while .Net web controls exist
employing a simple design pattern that uses as standalone files depending only on the .Net
stored procedures and Logic components. framework.
3,806
4000 dotNET J2EE
Web Logic 3,479
Technology Components Database 3500 Lines of Code Required
3000
Web 2500
Controls Stored 1,971 1,914
Data Access 2000
Procedures
1500
WEB TIER MIDDLE TIER DATA TIER 910 940
804
1000
533
Figure 7: Common Architecture
500 178
35

The testing procedure used to determine the 0

Total Lines Web Tier Middle Tier Data Tier Config
response time for a given user load was adopted of Code

from the procedure used by Microsoft and Figure 9: Comparison of Lines of Code Required
Oracle. The procedure employed is conducted on
the Benchmark Factory by Quest Software; this
3.2 Language Comparison
application is a multi threaded client driver that
emulates client interaction with the site. The Many of the components that constitute a J2EE
client interaction is defined by a series of http or .Net solution derive their performance from

29
the underlying language compilation and
execution environment. To evaluate the effects
of this dependency an application was developed
to determine the speed at which a Java and C#
implementation is capable of manipulating
simple and complex data types. Where Java and
C# are respectively the languages used to
implement J2EE and .Net solutions. Notably
both languages exhibit the same compilation and
execution model, where the compiled
intermediate code is executed in a managed
environment.
4. Conclusions
The performance results indicated that .Net
performed better than the Java implementation
by a factor of 1.8. This was attributed to the
output caching facility employed in the .Net
application. In contrasting the code size as a
measure of developer efficiency, .Net and J2EE
appeared equal. In conclusion; the performance
and ease of development of a distributed web
application is dependant on the architecture.

The test application populated an array with the
given data type then traversed the array totalling
the contents. The number of operations
performed was divided by the time take to
determine the performance index.
Reflecting on the results presented in figure 10,
the C# programming language has a substantial
advantage when applied to complex operations
involving many objects or structs. A Struct is a
user defined value type that can be considered as
a lightweight alternative to a class (a reference
type). The Struct is stored on the stack and thus
proves to be considerably more efficient in the
use of memory. This accounts for the substantial
increase in performance over the Object. It
should be noted that Structs have not been used
in the web application comparison. Finally the
difference in performance observed for the
simple data types is minor, and as such the
language will be considered equal for simple
operations.
8
7.45 7.40
C# Java
6.79
Performance Index
7
4.1 Future Developments
The proposed developments focus on improving
the performance and scalability of the .Net and
J2EE web applications, which form the
foundation of this study.
• Extend the programming model of the .Net
and J2EE applications to include support
for asynchronous workflow. Asynchronous
programming provides a request response
approach to method calls. This results in
faster response times and better scalability.
• Distribute the application to three physical
tiers and introduce the concept of web
farming. Web farming is an implementation
of load balancing that uses a redundant
array of servers to service Http requests. A
routing server redirects incoming requests
to the server experiencing the least load,
thus improving the applications response
times.

6 Appendix 1
5

4 Test System
Processor: Pentium III 866 MHz @ 871 MHz
3
Ram: 512 MB SD
2 0.90
0.41
Motherboard: ASUS Cusl-2 815EP
1 0.00 Hard Drive: IBM DLTA 307303 ATA 100
0 OS: Windows XP Professional v2002
Simple Object Struct

Figure 10: Language Comparison Results

7. References
[1] L.Adams, “The Creator of .Net Pet Shop defends imp lementation”, Builder.com, 2002.

[2] “Implementing Sun Microsystems’s Java Pet Store J2EE Blueprint Application using Microsoft
.NET”, Version 1.5, Microsoft Corp, 2001.
Available: http://www.gotdotnet.com/team/compare/petshop.aspx

30