Friday, August 26, 2005

Comparison between J2EE and .NET

A Comparison between J2EE and .NET from Software Architecture’s

This paper compares two competing software technologies, J2EE and .NET from the
perspective of software architecture. Both technologies aim at moving the software
complexity away from the developers and letting them focus on the business logic. To
achieve this end, both technologies provide a managed execution environment, a rich set
of libraries, a method for uniform access to data, and an in-built support for backward
compatibility. However, these two technologies take different approaches to meet these
goals. This paper discusses the two approaches and their effect on non-functional
requirements. In software architecture, the non-functional requirements are used to select
the architecture that best suits the constraints of the application among different ones.
This paper compares these two technologies based on the following non-functional
requirements: Usability (how easy to use the technology), Security, Performance,
Stability, Reusability, Comprehensibility, and User Documentation. Based on the
discussion, it has been concluded that neither of the two is a clear winner. Hence that if
one has a team of skilled programmers, with an existing business system using one
technology, realistically it will be better to continue using that system, be it J2EE based
or .NET based.

1. Introduction

Large software systems are inherently complex. Developing and maintaining such large
systems has always been a monumental task. With the advent of Internet, e-business
became an indispensable aspect of a company’s success. Developing e-business solutions
poses a new set of challenges for software development. Enterprise applications or ebusiness
solutions generally run on heterogeneous networks and have to run on top of
software developed by different vendors. They also involve the use of different network
protocols. Under these constraints, enterprise applications have to satisfy the key
requirements: High availability, Security, Reliability, and Scalability. It is easy to see the
need for a managed environment or run time and a rich set of libraries to support
development of enterprise applications.
The two software giants, Microsoft and Sun, have come up with their own solution
architecture to aid the development of enterprise applications. Microsoft’s .NET is a
framework with a rich set of libraries, a common language runtime and a more powerful
and unified development environment. The alternative from Sun is J2EE. It is actually an
open specification that specifies a set of technologies to solve the problems that arise in
the development of enterprise applications. However, J2EE can also refer to all the
technologies developed using Java. This paper discusses the runtime provided and their
support for enterprise applications by these two technologies. Then it presents a
comparison between these two technologies based on the following non-functional
requirements: Security, Performance, Stability, Reusability, Comprehensibility and User
This paper is organized as follows. Section II and III provides a brief overview of .NET
and J2EE respectively. Section IV discusses the support for runtime in these two
technologies .Section V presents the e-business architecture of .NET and J2EE. Based on
the non-functional requirements, each important aspect of .NET and JAVA are compared
in Section VI. The conclusion is presented in Section VII.
Keywords: .NET, J2EE, Comparison, Non functional Requirements
2. .NET Overview
.NET delivers the infrastructure which can be leveraged to assemble solutions ranging
from the desktop to the enterprise..NET is the amalgamation of the .NET framework, the
basic building block services known as .NET My Services, which includes development
tools such as Visual Studio.NET and infrastructure services provided by the .NET
Enterprise Servers.

2.1. .NET Framework
.NET Framework is the backbone of .NET. It can be broken down into three parts:
Common Language Runtime (CLR), Class libraries, and Web Services and Internal
System Services. It is a one-stop framework to build and deliver applications to any
.NET Framework
.NET My Services or Third
Party Web Services
.NET Enterprise Servers
(SQL Server, Biz Talk, …)
Web Services
Class Libraries
Common Language Runtime (CLR)
Operating System
.NET Solutions
Figure 1: .NET Overview
device. The framework components provide various services to the applications. Some of
the important services include providing I/O, providing UI elements for building web
pages or traditional windows forms-based interfaces, handling data from disparate data
sources using ADO.NET, ensuring application and system security, improving system
stability by run time garbage collection and so forth. We will look at CLR, web services
and .NET enterprise servers in detail in later sections.

2.2 .NET Enterprise Servers
There are many enterprise servers written to help the development of enterprise
applications. Some of the important enterprise servers are SQL Server 2000, BizTalk
Server 200, Exchange Server 2000 and Internet Security and Acceleration Server 200.

3. J2EE Overview
J2EE stands for Java 2 Enterprise Edition. It is the main competitor to .NET. J2EE is an
open specification that defines a multi-tier architecture for developing enterprise
applications. The enterprise architecture is described in section 5 and the other
technologies are shown in the figure.

3.1 J2EE Technologies

The J2EE provides the APIs for integrating different applications and accessing
databases. The following are the different APIs and their functionality.

3.1.1 HTTP
The Http client-side API is defined by the package. The http server-side API is
defined by the servlets and JSP interfaces. These application-programming interfaces are
used for establishing an http connection between the client and the server.
J2EE Solutions
J2EE Technologies
JSP, Servlets JTA Java Mail
Java Beans J NDI Java IDL
Enterprise Java Beans JAAS JavaRMI
Operating System
Figure 2: J2EE Overview

3.1.2 Java Transaction API (JTA)

This application programming interfaces are used for creating, and maintaining a secured
transaction between the client and the server.

3.1.3 Java IDL
JavaIDL allows J2EE application components to invoke external CORBA objects using
the IIOP protocol. These CORBA object may be written in any language.

3.1.4 Java Database Connectivity (JDBC)
The java database application interface provides connectivity to different relational
databases. They provide excellent features to connect to different databases.

3.1.5 Java Message Service (JMS)
The Java Message Service is a standard API for messaging that supports reliable point-topoint

3.1.6 Java Naming and Directory Interface (JNDI)

The JNDI API is the standard API for naming and directory access. The JNDI API
provides interfaces to the application components to access naming and directory

3.1.7 Java API for XML-based RPC (JAX- RPC)

J2EE uses the Java API for XML-based RPC (JAX-RPC) to support web services. Web
services can be implemented as a separate Java application using JAX-RPC or it can be
an enterprise java bean (EJB) wrapped using JAX-RPC.

4. Runtime
Runtime is an execution environment upon which software runs. Runtime generally
makes operating system services such as starting up and stopping threads available to the
programs executed. Depending on the runtime, it might also manage memory, enforce
security policies, manage file access and determine how programs behave and interact
with each other.

4.1 .NET
One of the more technical aspects of .NET by definition is the Common Language
Runtime (CLR). The various components of CLR include the common type system
(CTS), common language specification (CLS), the garbage collector, just-in time
compiling and security. The common type system and the common language
specification are the two parts of the two-pronged attack of .NET for making crosslanguage
compatible. The CLR is capable of executing programs written using any
language that meets its common language specification. There are many .NET compliant
languages already available in the industry. Some of them are, C#, Managed
C++,, and The security features will be discussed in a separate section.

4.2 J2EE
The runtime in J2EE is the Java Virtual Machine (JVM). Java is the only high-level
language supported by J2EE. Java is compiled to Java Byte Code which the JVM (Java
Virtual Machine) interprets. The JVM also does garbage collection and security
checking. JVM makes J2EE platform neutral since JVM is available on almost all
platforms. Thus the Java code once written can be executed on any platform. This is one
of the important reasons behind Java’s success.

5. Enterprise Application Development
Building an enterprise application has come a long way from the days of writing static
HTML pages to complex online transaction management. Enterprise computing has a
reputation for complexity .The complexity stems from the fact that enterprise applications
run on heterogeneous networks and have to run on top of software developed by different
vendors and also involves the use of different network protocols.

5.1 .NET
.NET provides an evolutionary step toward building Web-based applications with the
introduction of ASP.NET. This is an enhancement of Active Server Page (ASP)
technology and, among other things, it introduces a new way to create Web forms. The
most significant change to ASP is the technique called Code Behind, which makes it
possible to separate user interface and business logic. The access to data is through a set
of classes called ADO.NET. This provides a uniform access to the data from enterprise
servers. The technologies ASP.NET and ADO.NET have simplified the development of
enterprise applications. A simple architecture diagram is shown in the figure below.
Client Tier
Web Clients such as browsers
Presentation Tier
ASP.Net, Web forms
Business Tier
Data Tier
Enterprise Servers such as SQL Servers, Exchange Servers

5.2 J2EE
J2EE architecture contains client tier, web tier, business tier and EIS tier. The figure 2
below gives the complete details of each tier. Note that this figure shows the logical
relationships of the elements. It is not meant to imply a physical partitioning of the
elements into separate machines, processes, address spaces, or virtual machines.
The J2EE application is divided into client tier, web tier, and enterprise information

5.2.1 Client Tier

The client tier is the application that is located on the client machine and it provides the
user interface. The client can be Applet Client or Application Client. The applet is a GUI
application that typically executes in web browsers. The applet client can provide a GUI
to the user. Note that applet client can also be a simple HTML page that is presented to
the user. The application client is an independent client application program that is
developed using more sophisticated GUI environments like swing and awt of JAVA.

5.2.2 Web Tier
Client Tier
Applet Client
Web Tier
Business Tier
Enterprise Java Beans
EIS Tier
JSP Servlets
Information System
This uses JSP / Servlets to generate HTML pages to the client tier. This tier takes care of
presentation of information. This tier occasionally uses Java beans for computations.
5.2.3 Business Tier
The business tier consists of the business logic of the application. This tier combined with
web tier acts as the middle ware of the application. This provides the J2EE the flexibility
to integrate with legacy systems. This serves multiple clients using multithreading.
5.2.4 Enterprise Information Systems
These are the legacy systems of the enterprise. They contain the entire data of the
enterprise. Any request from the client goes through the middleware and where it is
passed to the enterprise information systems.

6. Comparison based on Non-Functional Requirements

6.1 Usability

In the development of enterprise applications, J2EE has many advantages compared to
.NET as J2EE was developed for that purpose. The containers available in the J2EE
manage most of the system issues. Some of the important system issues that are worth
mentioning are accessing data from DBMS, managing distributed system issues like
Naming(JNDI), and remote method invocation(RMI ).This lets the application developers
concentrate on the business logic. One more advantage of J2EE is the GUI based
deployment tool which helps in packaging and deploying the enterprise java beans. .NET
has one distinct advantage over J2EE. ASP.NET provides a way to separate code and
user interface components. This is not possible using JSPs and Servlets.
In the development of GUI applications, .NET is easier to use compared to J2EE. Visual
Basic.NET (VB.NET) is a language which aids in rapid development of GUI
applications. Moreover it is easy to use and does not require a highly skilled developer. In
J2EE, Java Swing is used to develop GUI .Though it is a powerful package, it is not as
easy as VB.NET and it requires highly skilled developers.
The cross language compatibility of .NET offers users a variety of languages from which
they can choose a language that best suits their application development. Even a single
application can be written using multiple languages. Although this is a significant
advantage, it has a downside too. Maintaining an application using multiple languages is
difficult. If a person who developed a part of the application in a particular language
leaves the company/project, then it might require high cost to replace that person. In
J2EE, currently only Java is supported. Java is considered the pure language which can
be used for developing all kinds of applications. Since all applications are developed in
Java, it does not have the disadvantage mentioned for .NET. It is also possible to make
J2EE cross language compatible. The Java byte Code is general enough and that a
compiler can be written to convert any language to Java Byte code which can then be
executed by a JVM.
JVM is available in almost all different platforms. .NET is available only for windows
related platforms. However, efforts are made to implement .NET in other platforms,
especially Linux.
6.2 Security
In the world of Internet, Security is a paramount issue. The success of enterprise
computing and web services depends on how secure the application is. Both J2EE and
.NET have strong mechanism for security. Both support HTTPS secure transactions. Both
have the notion of identification, authentication of the user and access control associated
for each user. Both have two types of security: one can be specified external to code and
the other is specified in the code. We will see in detail how it is actually implemented in
each technology.
In .NET there are two types of security used by the run time (CLR): Code Access
Security and Role Based Security.
The Code Access Security means that the runtime performs security checks before code
is executed by analyzing the metadata and comparing the access requests to the system
settings and during JIT compilation. For example, one important component of code
access security is verifying that code is type-safe.
The Role based security is similar in idea to the security used in Windows today. One can
create roles and assign permissions to them.
In addition, we can have different security policies. A security policy is the set of rules
that the CLR follows when determining if it should grant permission to code.
In J2EE, there are two types of security control: Programmatic Access Control and
Declarative Access Control. To disallow an operation based on role or identification is
called the declarative access control. Sometimes, it may be required to decide whether or
not an operation can be allowed based on the data being manipulated. This can be
handled by programmatic access control. In addition, JVM supports byte code
verification and policy based security

6.3 Performance
In .NET, intermediate language (IL) is just-in-time (JIT) compiled to native code and
executed. In J2EE, the Java byte code is interpreted by the JVM. Since interpreting is
slower than executing native code, applications written on .NET perform better than
J2EE applications. This result is published in the website ( based on
some experiments. It has been said at various Java related websites that if Java byte code
is just-in-time compiled, it performs better than C++ implementations.

6.4 Stability
The stability of an application is improved if it does not lose memory due to memory
leaks. Memory leak refers to a chunk of memory that has no reference in the code and
was not freed. Both runtimes CLR and JVM include a garbage collector. A garbage
collector removes memory leaks and thus increasing the stability of the application.
6.5 Reusability
Both technologies are based on Object Oriented methodologies. .NET framework has an
in-built support for object orientation. Similarly since Java is an object oriented language,
J2EE also supports object orientation. Object oriented methodology facilitates the reuse
of code to a large extent. Hence both technologies are equally powerful with respect to

6.6 Comprehensibility
Understanding the architectures of both J2EE and .NET involves a steep learning curve.
This is because of the fact that they are huge and are composed of multiple different

6.7 User Documentation
Excellent documentation and tutorials for all technologies related to J2EE are available at
Sun’s website. Microsoft also has a host of information about .NET on its developer’s
Since the comprehensibility of these technologies is difficult, it is prone to misuse. This
can be avoided by providing the recommendations to utilize the technology in the best
way. Sun has created Java Blueprints that contains recommendations for Java

7. Conclusion
This paper compared J2EE and .NET based on the non-functional requirements. From the
discussion above, it is obvious that there is no clear winner. Each technology has its own
advantages and disadvantages. Both technologies have support for backward
compatibility. So, it is concluded that if one has a team of skilled programmers, with an
existing business system using one technology, realistically it will be better to continue
using that system, be it J2EE based or .NET based.

Tuesday, August 23, 2005

Saving an embedded resource xml file at runtime in C#

I couldn't find a cut & dry solution to this (probably b/c it's too simple for anyone to think they would need an example) so here's how I got an xml file embedded as a resource in a vs2003 project written to the filesystem.

First, you just add an xml file with some default information you want for it to your project and change its build action to Embedded Resource. Then, you find the name of the resource (it can be tricky if you have a few folders) by opening up ildasm and double clicking the MANIFEST node. Using that resource name, you would do something like this:

using System;
using System.IO;
using System.Xml;
using System.Reflection;
string path = Path.Combine(
path = Path.Combine(path, Application.ProductName);
path = Path.Combine(path, subFolder);
path = Path.Combine(path, "fileName.xml");
Assembly thisAssembly = Assembly.GetExecutingAssembly();
Stream rgbxml = thisAssembly.GetManifestResourceStream(
XmlDocument doc = new XmlDocument();
doc.PreserveWhitespace = true;