Binary Spectrum Geeks at work

Here are some similarities, differences, advantages and disadvantages of architecting/developing applications in .NET over J2EE.To summarize these 2 technologies for a layman to understand would be:

 .NET – Relates to Productivity, Simplicity and “Out-of-the-box”.

J2EE – Relates to Flexibility, Complexity and “Do-it-yourself”.

1. To bring about a comparison with respect to the Architectural Philosophy, below are some of the points that have been identified:

            J2EE

 J2EE was created to give something better and more scalable than CGI or CORBA and to help standardize pervasive enterprise technologies such as message oriented middleware (MOM). As such, J2EE had some - great hits in Servlets instead of CGI,
- lackluster - EJBs instead of CORBA Hence the J2EE is a result of a powerful but also very complex framework.

Some of the big architectural advantages that one can enjoy when working on J2EE are the flexibility and the extensibility rendered by the J2EE API’s, which leaves ample room for open source innovations. Another noted feature is that J2EE can run on any platform.

Amidst all this a major concern would be the need for expensive application server to run its applications where they often add very little value relative to its license cost.

J2EE has limitless options for implementation of domain models backed by object-relational and cross-enterprise integration tools.

            .NET

            The major architectural additions to the .NET Framework were:

<!--[if !supportLists]-->·         <!--[endif]-->The "adoption" of the Java language as C#.NET

<!--[if !supportLists]-->·         <!--[endif]-->S.O.A.P. (Simple Object Access Protocol) and its native support for OO-to-XML

<!--[if !supportLists]-->·         <!--[endif]-->Re-design of VB into a VB.NET to make it, as Java/C# was, fully object oriented.

The architectural advantages identified here is that the focus is on the developer and hence is easy to work with, it follows a simplified transition path from the client-server to the enterprise development model. But unlike J2EE where it is platform independent, .NET is restrained to just one platform.

.NET has a harder time supporting database independent implementation of the domain model because of its less mature or mapping tools.

1. To bring about a comparison with respect to the Framework Components, below are some of the points that have been identified:

            .NET

 The major architectural components of the .NET framework that most of the developers use are ASP.NET pages, plain objects written in some .NET language, ADO objects and Web Services.

            J2EE

 J2EE design is heavily based on design and architectural patterns such as "MVC - Model View Controller", Facade, Factory, Layers which makes it somehow more complex to understand to the uninitiated.

In general, the most commonly used core components in J2EE are Servlets, JSP and JDBC for database access. These roughly correspond to "code behind", ASP.NET and ADO.NET components in .NET.

J2EE defines one or more sets of components for enterprise tasks that are not even defined in .NET. So in J2EE we have:

<!--[if !supportLists]-->·         <!--[endif]-->EJB for object remoting, message (as in MOM) processing and relational persistence

<!--[if !supportLists]-->·         <!--[endif]-->JMS for Message Oriented Middleware (MOM) abstraction

<!--[if !supportLists]-->·         <!--[endif]-->JDO for relational persistence

<!--[if !supportLists]-->·         <!--[endif]-->JCA for non-relational enterprise access

<!--[if !supportLists]-->·         <!--[endif]-->JAAS for security services and SSO abstraction and so on.

Not very many people write their web apps using Servlets and JSP only. Most of the J2EE developers use either aging but widely popular Struts framework, official J2EE JSF web framework, more recent and innovative Spring MVC or WebWork, etc.

1. To bring about a comparison with respect to the Web Components, below are some of the points that have been identified:

            .NET

 In general, ASP.NET is easy to work with; the tool support through Visual Studio product line is very good. There is also a very good set of components available for the common web development tasks.

Its code behind concept is easy to understand and it is flexible enough to extend through smart use of design patterns. I like how ASP.NET manages to keep configuration files and application settings under control. Unlike J2EE, there are no verbose xml files for every little component you want to use. You specifically configure only special cases and exceptions.

Another attractive feature is how Microsoft incorporated Atlas (their AJAX frameworks) into ASP.NET. Deployment of ASP.NET applications is very easy.

            Some of the concerns that have been identified with ASP.NET are:

<!--[if !supportLists]-->·         <!--[endif]-->The increased risk of code replication which in other terms increases code duplication and could create a significant maintenance burden.

<!--[if !supportLists]-->·         <!--[endif]-->Addition of data binding objects, including query definitions into the ASP.NET pages itself.

            J2EE

Servlets came as a better, faster, more expressive replacement for then popular CGI-BIN. They are very POST/GET and HTTP parameters oriented. API is easy to work with but it is very bare. It could be categorized in the following procedural format:

            Request, Response, Session and Context.

            The advantages that are seen in its use are:

<!--[if !supportLists]-->·         <!--[endif]-->Portability

<!--[if !supportLists]-->·         <!--[endif]-->Extensibility

<!--[if !supportLists]-->·         <!--[endif]-->Richness and Sophistication of available Value Add Open Source Frameworks

            Some of the issues that have been identified with J2EE are:

<!--[if !supportLists]-->·         <!--[endif]-->Complexity of the deployment model

<!--[if !supportLists]-->·         <!--[endif]-->Bareness of the core API

<!--[if !supportLists]-->·         <!--[endif]-->Over-saturation with choices

<!--[if !supportLists]-->·         <!--[endif]-->Need for application server.

 The Author Hermon Peter is a Software Engineer at Binary Spectrum.