Difference between .NET & J2EE

Question Posted / kirti

1 Answers
1932 Views
I also Faced
E-Mail Answers

Difference between .NET & J2EE..

Answer / kirti

Differences between J2EE and the .NET Platform

Vendor Neutrality

The .NET platform is not vendor neutral, it is tied to the Microsoft operating systems. But neither are any of the J2EE implementations

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. (ref : Java 2 Platform Enterprise Edition Specification, v1.3, page 2-7 available at http://java.sun.com/j2ee/)

Overall Maturity

Given that the .NET platform has a three year lead over J2EE, it should be no surprise to learn that the .NET platform is far more mature than the J2EE platform. Whereas we have high volume highly reliable web sites using .NET technologies (NASDAQ and Dell being among many examples)

Interoperability and Web Services

The .NET platform eCollaboration model is, as I have discussed at length, based on the UDDI and SOAP standards. These standards are widely supported by more than 100 companies. Microsoft, along with IBM and Ariba, are the leaders in this area. Sun is a member of the UDDI consortium and recognizes the importance of the UDDI standards. In a recent press release, Sun's George Paolini, Vice President for the Java Community Development, says:

"Sun has always worked to help establish and support open, standards-based technologies that facilitate the growth of network-based applications, and we see UDDI as an important project to establish a registry framework for business-to-business e-commerce

But while Sun publicly says it believes in the UDDI standards, in reality, Sun has done nothing whatsoever to incorporate any of the UDDI standards into J2EE.

Scalability

Typical Comparision w.r.t Systems and their costs

J2EE

Company System Total Sys. Cost

Bull Escala T610 c/s 16,785 $1,980,179

IBM RS/6000 Enterprise Server F80 16,785 $2,026,681

Bull Escala EPC810 c/s 33,375 $3,037,499

IBM RS/6000 Enterprise Server M80 33,375 $3,097,055

Bull Escala EPC2450 110,403 $9,563,263

IBM IBM eServer pSeries 680 Model 7017-S85 110,403 $9,560,594

.NET platform systems

Company System Total Sys. Cost

Dell PowerEdge 4400 16,263 $273,487

Compaq ProLiant ML-570-6/700-3P 20,207 $201,717

Dell PowerEdge 6400 30,231 $334,626

IBM Netfinity 7600 c/s 32,377 $443,463

Compaq ProLiant 8500-X550-64P 161,720 $3,534,272

Compaq ProLiant 8500-X700-64P 179,658 $3,546,582

Compaq ProLiant 8500-X550-96P 229,914 $5,305,571

Compaq ProLiant 8500-X700-96P 262,244 $5,305,571

Compaq ProLiant 8500-700-192P 505,303 $10,003,826

Framework Support

The .NET platform includes such an eCommerce framework called Commerce Server. At this point, there is no equivalent vendor-neutral framework in the J2EE space. With J2EE, you should assume that you will be building your new eCommerce solution from scratch

Moreover, no matter what [J2EE] vendor you choose, if you expect a component framework that will allow you to quickly field complete e-business applications, you are in for a frustrating experience

Language

In the language arena, the choice is about as simple as it gets. J2EE supports Java, and only Java. It will not support any other language in the foreseeable future. The .NET platform supports every language except Java (although it does support a language that is syntactically and functionally equivalent to Java, C#). In fact, given the importance of the .NET platform as a language independent vehicle, it is likely that any language that comes out in the near future will include support for the .NET platform.

Some companies are under the impression that J2EE supports other languages. Although both IBM's WebSphere and BEA's WebLogic support other languages, neither does it through their J2EE technology. There are only two official ways in the J2EE platform to access other languages, one through the Java Native Interface and the other through CORBA interoperability. Sun recommends the later approach. As Sun's Distinguished Scientist and Java Architect Rick Cattell said in a recent interview.

Portability

The reason that operating system portability is a possibility with J2EE is not so much because of any inherent portability of J2EE, as it is that most of the J2EE vendors support multiple operating systems. Therefore as long as one sticks with a given J2EE vendor and a given database vendor, moving from one operating system to another should be possible. This is probably the single most important benefit in favor of J2EE over the .NET platform, which is limited to the Windows operating system. It is worth noting, however, that Microsoft has submitted the specifications for C# and a subset of the .NET Framework (called the common language infrastructure) to ECMA, the group that standardizes JavaScript.

J2EE offers an acceptable solution to ISVs when the product must be marketed to non-Windows customers, particularly when the J2EE platform itself can be bundled with the ISV's product as an integrated offering.

If the primary customer base for the ISV is Windows customers, then the .NET platform should be chosen. It will provide much better performance at a much lower cost.

Client device independence

The major difference being that with Java, it is the presentation tier programmer that determines the ultimate HTML that will be delivered to the client, and with .NET, it is a Visual Studio.NET control.

This Java approach has three problems. First, it requires a lot of code on the presentation tier, since every possible thin client system requires a different code path. Second, it is very difficult to test the code with every possible thin client system. Third, it is very difficult to add new thin clients to an existing application, since to do so involves searching through, and modifying a tremendous amount of presentation tier logic.

The .NET Framework approach is to write device independent code that interacts with visual controls. It is the control, not the programmer, that is responsible for determining what HTML to deliver, based on the capabilities of the client device.. In the .NET Framework model, one can forget that such a thing as HTML even exists! Contd ....

Conclusion

Sun's J2EE vision is based on a family of specifications that can be implemented by many vendors. It is open in the sense that any company can license and implement the technology, but closed in the sense that it is controlled by a single vendor, and a self contained architectural island with very limited ability to interact outside of itself. One of J2EE's major disadvantages is that the choice of the platform dictates the use of a single programming language, and a programming language that is not well suited for most businesses. One of J2EE's major advantages is that most of the J2EE vendors do offer operating system portability.

Microsoft's .NET platform vision is a family of products rather than specifications, with specifications used primarily to define points of interoperability. The major disadvantage of this approach is that if is limited to the Windows platform, so applications written for the .NET platform can only be run on .NET platforms. Their are several important advantages to the .NET platform:

* The cost of developing applications is much lower, since standard business languages can be used and device independent presentation tier logic can be written.

* The cost of running applications is much lower, since commodity hardware platforms (at 1/5 the cost of their Unix counterparts) can be used.

* The ability to scale up is much greater, with the proved ability to support at least ten times the number of clients any J2EE platform has shown itself able to support.

* Interoperability is much stronger, with industry standard eCollaboration built into the platform.