J2EE & .NET, similarities and differences

Published 15 November 05 05:28 PM | makif 

About this posting: This post discusses the high-level similarities and differences between the J2EE and .NET programming models and provides some insight about future postings

Hello,

There are many similarities between .NET and J2EE. I am taking some liberty with the official definitions of these models but in the real world, J2EE is a programming model based on the Java language, having a concept of a container (typically application server) that provides services like lifecycle management and support for declarative transactions. J2EE is based on object oriented design principles; it is a specification owned by Sun Microsystems, however, Sun does involve the community in building the specification through the Java Community Process. The core J2EE specification is supported by multiple vendors most notably Sun Microsystems, BEA and IBM and other vendors build applications that run on J2EE applications servers. In addition to the 'write once, deploy on multiple operating systems' feature of Java, J2EE also defines layers of abstractions in the forms of APIs that provide some level of decoupling between your application and the underlying infrastructure and resources e.g. as in case of JMS and JDBC APIs.

In the real world, .NET is a programming model that supports multiple languages; it provides services like lifecycle management, sand box security and garbage collection and is based on object oriented design principles. The .NET specifications and the core APIs are developed by Microsoft, however, Microsoft involves the community by actively getting feedback through multiple channels and uses that feedback to decide the new features of the framework, the .NET frame work is supported by a large ecosystem of ISVs that develop solutions that utilize the .NET APIs. The applications developed using the .NET model are typically deployable on the Windows platform only, however, they can interoperate with applications running on other platforms using a variety of mechanisms that I will be discussing in my future posts. The new version of .NET, .NET 2.0, introduces the concept of ‘providers’ which decouples your application from the underlying resources like the database and security-credential provider. Both J2EE and .NET have concepts of Virtual Machines and Just-in-time compilation, J2EE has a Java Virtual Machine (JVM) that facilities platform choice and .NET has Common Language Runtime (CLR) that facilitates choice of programming languages, the conceptual architecture for both the models looks quiet similar. I will be willing to provide a mapping for those who are interested in a more detailed comparison.

Keeping all the prejudices aside, it is possible to develop good IT solutions using either model of programming, there is nothing inherently wrong with .NET or J2EE, those who claim that a reliable system cannot be developed in Java or that it is not possible to develop a highly secure and reliable system in .NET have not done their homework or are not current in their research. It is true that both J2EE and .NET have had their set of issues in the past years, however both programming models have passed through radical changes and many of the issues have been resolved some time ago, e.g. I recently corresponded with someone that was concerned about the inherent capability of .NET to support his enterprise mission critical application consisting of 100 transactions per second in a system where a 150 million dollars exchanges take place in an year. It came as news to him that their are many absolutely mission critical applications running on .NET, including applications that support 3000 transactions per second with over 5 trillion dollars changing hands (at a stock exchange). Similarly, I have seen a very complex and large airline reservation system successfully developed and running on J2EE. In my humble opinion, the inherent capability of the programming models is only one of the factors and the architects and technical decision makers need to look at other criteria for making an objective decision,   I will talk about some of the decision criteria in my future posts, stay tuned and please do provide feedback so I may learn from you.

Best regards,

Mohammad

 

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# Babulal said on December 2, 2005 12:13 AM:
Hi

I am working on Microsoft technologies for the last 3 years. and more than 2 years on the .Net.

i would like u to comment on the security issues on dot net assemblies. i belive that the there are lot of possiblities to do the reverse engineering with .NET assemblies and that i feel ..... a big drawback ....
# makif said on December 2, 2005 11:31 AM:
Hello Babulal,

Good question, the reverse engineering potential is a consequence of language independence in .NET and platform independence in Java. There are a number of mechanisms and tools through which you can obfuscate your code to protect your intellectual property. For example, one of the tools that can be used to obfuscate Java and .NET code can be found at http://www.preemptive.com/

Best regards,
Mohammad
# Srinivas Polani said on August 2, 2006 3:22 PM:
Similarities between J2EE and the .NET Platform
A full listing of equivalencies between J2EE and the .NET platform is given in Figure 5. As you can see, many of the .NET platform functional areas have no counterpart in J2EE. In some of these cases, it is considered to be an implementation specific decision as to whether or not to support the functionality, and if so, how. Note: for unfamiliar abbreviations, see the glossary.
Figure 5. Technology equivalences
Technology .NET J2EE
Support technologies
Distribution protocol DCOM, SOAP RMI/IIOP
Firewall ISA* not specified
HTML page caching ISA*, ASP.NET not specified

Presentation tier technologies
Infrastructure IIS not specified
Programming model ASP.NET Servlets, JSP
High availability NLBS*, ACS*, other not specified
Load balancing NLBS*, ACS*, other not specified
Management ACS* not specified

Middle tier technologies
Infrastructure COM+ EJB
Programming tool Visual Studio.NET not specified
High availability ACS* not specified
Load balancing ACS* not specified
Security API COM+ Security Call Context JAAS
Message Queue API MSMQ JMS 1.0
Asynchronous components Queued (COM+) Message driven beans (EJB 2.0)
Naming and Directory Service ADSI JNDI

Data tier technologies
Distributed transaction MS-DTC JTS
Relational DB API ADO.NET JDBC 2.0
Hierarchical DB API ADO.NET -
Database storage SQLServer** -
Mainframe DB connectivity HIS* Java Connectors

Framework technologies
eCommerce framework Commerce Server* -
Business to business orchestration BizTalk Server* -
* Optional add-ons services for the .NET platform.
** SQLServer is the official .NET platform database technology, but any ADO.NET compliant database, which includes most major databases, can be used.
Differences between J2EE and the .NET Platform
You can see that there is tremendous overlap between the J2EE and .NET platform technologies. How, then, does one choose between them? In this section I will discuss what I see as the main differences.
Vendor Neutrality
Many companies buy into J2EE believing that it will give them vendor neutrality. And, in fact, this is a stated goal of Sun's vision:
A wide variety of J2EE product configurations and implementations, all of which meet the requirements of this specification, are possible. A portable J2EE application will function correctly when successfully deployed in any of these products.  
In fact, few non-Sun J2EE proponents believe this is achievable. One of the most prominent independent J2EE spokespersons is Paul Harmon, a principal consultant for the Cutter Consortium and the writer of the widely read Architecture/e-Business E-Mail Advisory. While Harmon is usually very pro-J2EE, he recently wrote this unusually frank assessment of J2EE vendor portability
Has the EJB model reached the point where I can move EJB components from one EJB application server to another?  Not in most cases.  The EJB specification isn't comprehensive enough.  EJB application server vendors have "filled in" by providing proprietary solutions to complete the model and to guarantee that their clients can build production systems.  
Harmon summarizes the vendor neutrality situation today, as do many, with this assessment:
The reality, at the moment, is that if you want to develop an EJB application, you should stick with a single vendor.
The reality today is that there is no such thing as vendor neutrality. Of course, the .NET platform is not vendor neutral, it is tied to the Microsoft operating systems. But neither are any of the J2EE implementations. The best advice I can give is to choose some vendor, plan on staying with that vendor, and leverage the heck out of the platform that vendor provides.
# Biplab Banerjee said on June 10, 2008 6:02 AM:

Hi Mohammad,

I am planning for a presentation on .NET and J2EE interoperatibility to highlight the best practices and came across different resources/webcasts shared by you.

It would be great if you can provide a link to the PPT for webcast "Best Practices for J2EE and .NET Interoperability in Financial Services".

Also, can you provide me with the mapping between J2EE and .NET stacks in a more detailed comparison.

Kind Regards,

Biplab Banerjee

# No Spin Architecture J2EE amp NET similarities and differences | debt solutions said on June 19, 2009 1:42 PM:

PingBack from http://debtsolutionsnow.info/story.php?id=5574

Leave a Comment

(required) 
(optional)
(required) 

  
Enter Code Here: Required

Search

This Blog

Syndication

Page view tracker