25

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

Sun’s J2EE technology has arguably been the leading platform for the development of web based solutions. Now Microsoft has made a bid with its .NET programming platform. Both technologies provide the same function; a platform to facilitate distributed application development. This study compares distributed web application development on the .Net and J2EE platform, focusing on the following objectives: • Compare and contrast the reference

implementation for the .Net and J2EE platform, detailing architectural perspectives and technologies.

• Develop a distributed web application for

the .Net and J2EE platform that implements the same architecture and uses equivalent technologies. o Provide performance data reflecting

the applications ability to handle user loads.

o Compare the code size of each implementation, as a measure of developer efficiency.

o Evaluate the applications dependency on the underlying language compilation and execution environment.

26

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.

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

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

DATA TIER

Oracle 9i

WEB TIER

JSP

Custom Tags

Control Servlet

MIDDLE TIER

EJB Container

EJB

EJB

EJB

Figure 1: J2EE Blueprint Architecture

27

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.

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

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.

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

Web Services

Data / XML Classes

Base Framework Classes

Web Forms Win Forms

Forms

Common Language Runtime Base Framework Classes

System Services Base Framework Classes

Figure 2: .Net Framework

DATA TIER

WEB TIER Figure 3: .Net Blueprint Architecture

MIDDLE TIER

SQL Server 2000

Stored Procedures

Web Forms

User Controls

Logic Components

(C# Class Library)

ADO.NET for Data Access

28

Figure 5: Blueprint Performance Comparison [2]

Response Time vs. User Load

0

200

400

600

800

1000

1200

1400

0 500 1000 1500 2000 2500 3000 3500 4000User Load

Per

Pag

e A

vg. R

esp

on

se

Tim

e (m

s)

J2EE Response Time

.NET Response Time

base classes to support data management and XML manipulation.

Active Server Pages .NET (ASP.NET) is a server side scripting environment much like its Java counterpart; JSP. It provides a mechanism for developing dynamic web content which is generated in response to an HTTP browser request. The ASP.Net platform supports the development of web forms and web services. Web Forms employ a component based, event-driven programming model that introduces traditional form-based development to web applications. The notion of components is introduced with web from controls, which wrap the underlying HTML form based constructs such as <input type=”Radio”> into a more consistent object model e.g. <asp: RadioButton>. Web controls serve as the building blocks for web form development, with Visual Studio .Net developers can simply drag web controls onto a form then write an event handler. The .Net framework also supports custom controls that enable developers to extend control functionality beyond the scope of the standard controls. Finally the performance of ASP.Net is greatly improved through simple page directives that enable simple and fragment caching. Simple or fragment caching refer to the storage of frequently used pages or user controls respectively.

The .Net framework manages database interaction through the class collection known as Active Data Objects .NET (ADO.NET). To improve scalability ADO.NET employs a disconnected data model. This means that the data retrieved from the database is isolated from the database connection and is cached on the local computer. ADO.NET consists of two class 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

applications. A summary of the equivalent technologies is presented in figure 4, where an equivalent technology is considered as that which is based on the same premise. This concept can be illustrated by contrasting the JSP and ASP.Net frameworks; both provide a means to develop a web application.

3. Results

With the emergence of Microsoft’s .Net platform, the .Net Pet Shop was developed to contest the J2EE reference implementation known as the Java Pet Store. “After benchmarking the .NET Pet Shop against Oracle's published performance results for its own J2EE Pet Store implementation, Microsoft pronounced the .NET implementation to be superior in terms of performance, implementation costs, and developer efficiency [1]”.

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

Figure 4: .Net and J2EE Feature Summary

Feature J2EE .NETInterpreter JRE CLRWeb Tech JSP ASP.NET

Base Web JSTL Web Form ControlsCustom Web Custom Tags User Controls

Middle Tier EJB Managed ComponentsDB Access JDBC ADO.NET

29

discourages database tuning in the J2EE implementation in the interest of portability [1]”.

To address these issues this section presents the evaluation of the .Net and J2EE application, which were developed to establish a benchmark on a common architecture. In addition, the underlying language compilation and execution environment of the .Net and J2EE platforms was evaluated. For the details of the test system used refer to Appendix 1.

3.1 Common Architecture Benchmark

To provide an “apples to apples” comparison of the competing platforms, benchmarking must be preformed on applications that employ a common architecture and implement equivalent technologies. The architecture used in the development of the new .Net and J2EE Pet Store’s discards the notion of portability, instead employing a simple design pattern that uses stored procedures and Logic components.

The testing procedure used to determine the response time for a given user load was adopted from the procedure used by Microsoft and Oracle. The procedure employed is conducted on the Benchmark Factory by Quest Software; this application is a multi threaded client driver that emulates client interaction with the site. The client interaction is defined by a series of http

requests that are generated by recording a session of activities performed on the site.

The data from the user load benchmark indicates that the .Net Pet Store responds 1.8 times faster that J2EE implementation at the 450 user load level. Initially this appears to be a considerable performance deficit, however in considering the time scale this represents just over 0.5 seconds. The performance benefits have been attributed to the use of Output caching in the.Net application. The caching mechanism provides local storage of dynamic content that does not need to be re-executed on every request.

The comparison of the lines of code required to implement the solution provides an objective measure of developer productivity. The code size is relatively equal; the differences are due to minor implementation details. Illustrating this point; the web control implementation for J2EE requires that associated Meta data be defined in a configuration file while .Net web controls exist as standalone files depending only on the .Net framework.

3.2 Language Comparison

Many of the components that constitute a J2EE or .Net solution derive their performance from

DATA TIER

WEB TIER Figure 7: Common Architecture

MIDDLE TIER

Database

Stored Procedures

Web Technology

Web Controls

Logic Components

Data Access

Figure 5: Blueprint Lines of Code Comparison [2]

3,484

14,273

1,881

5,891

863

5,404

684412 56

2,566

0

2000

4000

6000

8000

10000

12000

14000

16000

Total Linesof Code

Web Tier Middle Tier Data Tier Config

Lines of Code Required

dotNET J2EE

Figure 9: Comparison of Lines of Code Required

3,479

3,806

1,9711,914

533

910 940804

35178

0

500

1000

1500

2000

2500

3000

3500

4000

Total Linesof Code

Web Tier Middle Tier Data Tier Config

Lines of Code Required

dotNET J2EE

Figure 8: Performance Comparison

Response Time vs. User Load

0

500

1000

1500

2000

2500

0 100 200 300 400 500 600User Load

Per

Pag

e A

vg. R

esp

on

se

Tim

e (m

s)

J2EE Response Time

.NET Response Time

30

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.

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.

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.

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.

Appendix 1

Test System Processor: Pentium III 866 MHz @ 871 MHz Ram: 512 MB SD Motherboard: ASUS Cusl-2 815EP Hard Drive: IBM DLTA 307303 ATA 100 OS: Windows XP Professional v2002

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

Figure 10: Language Comparison Results

7.45 7.40

0.900.41

6.79

0.00

0

1

2

3

4

5

6

7

8

Simple Object Struct

Performance Index

C# Java