.net versus J2EE

 

There are currently two major platforms for enterprise development. They are J2EE (Java 2 Enterprise Edition) and Microsoft’s .net platform.

 

By Riley T. Perry

 

Overview

 

J2EE is a set of non-vendor specific standards for developing “fat” and “thin” applications and services, J2EE is mainly directed at “thin” clients. These standards are the collaborative effort of more than 400 companies.

.net is a tangible set of software and services designed to run on the Windows platform. The .net software and services also allow the design and implementation of enterprise and non-enterprise applications. Equal emphasis has been given to “fat” and “thin” clients. .net was developed exclusively by Microsoft.

 

Virtual Machines

 

Both .net and J2EE use a Virtual Machine to interpret intermediate code. With J2EE this intermediate code is called “Byte Code”. With .net the code is called the “Intermediate Language”. When Java or .net code is written and compiled it compiles to intermediate code.

 

With J2EE the JVM (Java Virtual Machine) interprets its byte code line by line into the machine’s native language. J2EE byte code can be compiled directly to native machine code or JIT (Just In Time) compiled, but the vast majority of J2EE applications are interpreted.

The .NET virtual machine, the CLR (Common Language Runtime) uses a JIT compiler to compile blocks of IL code into native machine code at run time. Visual Studio.net can also compile directly to native code.

 

Programming Languages

 

Both platforms have the option of using multiple programming languages for an enterprise application, although this is a much easier task to achieve with the .net platform.

 

The J2EE standard is based on Java, so applications are mainly developed in Java. Interoperability is possible through JNI (Java Native interface) and CORBA (Common Object Request Broker Architecture). The latter is almost never done as the APIs are complicated and time consuming.

.net supports the seamless integration of over 20 languages, this is done via strong typing, common interfaces and a concept called “managed code”. On the down side, the language differences are largely semantic (VB.NET vs. C#). Also, languages like C++ require extra imports (managed extensions).

 

Operating Systems

 

Both .NET and J2EE have pretensions to having portable source code.

 

J2EE is by far the best for portability, the whole specification is designed as to be non-vendor specific. In practice though, Java source is often not portable without modifications.

.net has promised that the CLR and core languages like C# will eventually be portable. At present .net only runs on Windows.


 

J2EE versus .net at Each Tier

 

An enterprise application can be logically separated into 3 tiers - Presentation, Business Logic, and the Data tier.

 

Presentation Tier

 

 Both .net and J2EE use a scripting language at the presentation tier for “thin” clients or “Web Applications”. They also have similar ways of generating this tier for “fat” client applications.

 

For “thin” client applications J2EE uses Java Servlets and a derivative of ASP (Active Server Pages) called JSP (Java Server Pages), which intermingles HTML with Java based script. Calls to Business logic components (EJB - Enterprise Java Beans) are made from these JSP pages. Coding the page to render on a number of different “thin” clients must be done manually. For “fat” clients there is the Java Swing API, with a set of standard java beans and a number of different GUIs to build applications with.

 

.net uses Visual Studio.net for both “thin” and “fat” clients. .net “thin” client applications use the ASP.NET scripting language. ASP.NET can be used in the traditional script based way, but Microsoft encourages the use of a “Code Behind Page”. One simply drags and drops various “Web Controls” onto an ASP.NET (.aspx) page and then uses the code behind page to adjust those controls programmatically. When an .aspx page is requested by a “thin” client the page is rendered automatically by the .net runtime which checks the type of “thin” client and adjusts each control accordingly. The result is that an .aspx page can render on any supported “thin” client without any extra work. This has a down side, that being that the look n’ feel of each page is limited by the controls offered. Microsoft’s IIS server also has legacy support for ASP, so ASP.NET and ASP can be used in conjunction with each other. For “fat” clients the process is the same except that there is a different set of controls for a “Windows Form” (as opposed to a “Web Form”).

 

Business Logic Tier 

 

The two technologies are very similar on this level with each borrowing concepts from the other.

 

Java Beans are the basic components (defined properties, event handling and persistence). EJB are the distributed equivalents that have extra functions for application level security, distributed transactions, life cycle management and resource pooling. The java runtime handles the life cycle of each component, deciding when to destroy a component (garbage collection) and what memory it can access (sandbox security).

 

.net uses an enriched version of COM+ (assemblies) which gives its components all of the above functions with the addition of newer concepts like extensible meta-data for each assembly. Like J2EE the “registration” of components is much easier with a new deployment model and .net projects also support traditional COM and COM+ components. Perhaps the biggest difference is the ability to go into “unmanaged mode” which allows the application to access areas of memory normally inaccessible via the CLR Sandbox.

 

Data Tier

 

For relational database access J2EE uses JDBC (Java Database Connection) – which is based on Microsoft’s ODBC (Open Database Connectivity). At a higher level it is conceptually the same as ADO (ActiveX Data Objects - which sits on top of ODBC) with connections, statements and Result sets. JDBC does perform better than ADO. For Naming and Directory Services J2EE uses JNDI (Java Naming and Directory Interface) and JDBC does not support hierarchical Database access.

 

.net uses ADO.NET , it has all the ADO functionality and more. All data transmission from source to component is now done via XML (eXtensible Markup Language). This means that ADO.NET can use ANYTHING that emits XML data in the ADO.NET schema as a data source. ADO.NET supports hierarchical data access, and naming and directory services are accessed via ADSI (Active Directory Services Interface).

 

XML, Web Services, and Remoting

 

Web services and remoting are web and TCP/IP based remotely callable functions that sit on top of a predetermined protocol.

 

J2EE’s web services run with a host of different protocols. They run with HTTP, RMI/JRMP (Remote Method Invocation / Java Remote Method Protocol) or IIOP (Internet InterORB Protocol).

.net web services run exclusively on HTTP with a SOAP (Simple Object Access Protocol) wrapper. All data interchange is done with XML. Web services in .net are all standardised with XML interfaces. Remoting uses either SOAP or TCP/IP directly. The entire .net framework is very XML centric.

 

Performance

 

In an enterprise environment .net outperforms J2EE. Benchmarks show that it is more scalable, efficient, faster to run and develop, easier to use and cheaper - sometimes by a factor of five. .net is designed to work just as well in a non-enterprise environment (pointers, unmanaged code, etc.). J2EE is rarely used in a non-enterprise environment to write graphically or numerically intensive code for executables.

 

References