Differences Between J2EE and .NET

For those who are particularly interested in the differences between .NET and J2EE, let's take a look at the pros and cons of each development environment from a market-positioning perspective.

A third-party professional services company, the Middleware Company (www.middleware-company.com), recently wrote a white paper that fairly objectively evaluates the differences between .NET and J2EE as development environments. From Middleware's perspective, here are the differences:

Arguments Supporting Both Platforms

Regardless of which platform you pick, new developers will need to be trained (Java training for J2EE, OO training for .NET).

You can build Web services today using both platforms.

Both platforms offer a low system cost, such as jBoss/Linux/Cobalt for J2EE, or Windows/Win32 hardware for .NET.

Both platforms offer a single-vendor solution.

The scalability of both solutions is theoretically unlimited.

Arguments for .NET and Against J2EE

.NET has Microsoft's A-team marketing it.

.NET released their Web services story before J2EE did, and thus has some mind-share.

.NET has a better story for shared context today than J2EE

.NET has an awesome tool story with Visual Studio.NET

.NET has a simpler programming model, enabling rank-and-file developers to be productive without shooting themselves in the foot

.NET gives you language neutrality when developing new eBusiness applications, whereas J2EE makes you treat other languages as separate applications.

.NET benefits from being strongly interweaved with the underlying operating system

Arguments for J2EE and Against .NET

J2EE is being marketed by an entire industry.

J2EE is a proven platform, with a few new Web services APIs. .NET is a rewrite and introduces risk as with any first-generation technology.

Only J2EE lets you deploy Web services today.

Existing J2EE code will translate into a J2EE Web services system without major rewrites. Not true for Windows DNA code ported to .NET.

.NET Web services are not interoperable with current industry standards. Their BizTalk framework has proprietary SOAP extensions and does not support ebXML.

J2EE is a more advanced programming model, appropriate for well-trained developers who want to build more advanced object models and take advantage of performance features.

J2EE lets you take advantage of existing hardware you may have.

J2EE gives you platform neutrality, including Windows. You also get good (but not free) portability. This isolates you from heterogeneous deployment environments.

J2EE has a better legacy integration story through the Java Connector Architecture (JCA).

J2EE lets you use any operating system you prefer, such as Windows, UNIX, or mainframe. Developers can use the environment they are most productive in.

Source: http://www.theserverside.com/resources/article.jsp?1=J2EE-vs-DOTNET, The Middleware Company. Used by Permission.

Note that the Middleware Company specializes in Java server-side application deployment so many readers may view this commentary as somewhat biased. But, on the whole, it does capture the key points that one should consider when evaluating the .NET approach versus the J2EE approach. It does a fair job of representing the differences between the two approaches as well as representing the commonality between them.

Microsoft's Response

At this juncture it is only fair to present Microsoft's perspective on the Middleware Company's white paper. The present section has been derived from a "quite excited" memo on this topic that Microsoft sent to me.

With response to the contention that the BizTalk framework has proprietary SOAP extensions and does not support ebXML .NET Web services are not currently interoperable with present industry standards. Microsoft asserts that this contention is flat wrong:

  • Microsoft is driving standards and is actively promoting compliance both inside and outside the company. Along with IBM, we sponsor periodic interoperability events, inviting ALL Web services stakeholders to take part on our dime. Is Sun doing this? No. We are fully compliant with SOAP v1.1, WSDL 1.1, UDDI 1.0, XML 1.0, XSLT, HTTP 1.1, XPath, XSD, and many other relevant standards.

Microsoft observed that Sun is not an active participant in SOAPBuilders the home for Web services interoperability. A quick review of <">http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnsrvspec/html/globalxmlWebsrvinterop.asp> will show the state of Web services interoperability efforts.

With respect to the "arguments supporting both platforms" section of the Middleware Company report, Microsoft observed that:

  • Regardless of which platform you pick, new developers will need to be trained (Java training for J2EE, OO training for .NET).

With respect to the claim that J2EE supports Web services, Microsoft observed that 600 pages of J2EE specification say nothing at all about Web services, nor do the 700-odd pages of additional specification for JSP, EJB, and the other bits of J2EE. Building Web services "on J2EE" requires a bunch of infrastructure code not included in J2EE and not currently supported by vendors (called variously, "beta" support, "technology preview," third-party libraries). In contrast, .NET is designed from the ground up to support Web services. SOAP, WSDL, and XML are intrinsic to the .NET platform and the .NET tools. "We have customers who are using this stuff in production, today. There's a clear difference here."

Microsoft agreed that both platforms offer a low system cost, such as jBoss/Linux/Cobalt for J2EE, or Windows/Win32 hardware for .NET.

With respect to the statement, "You can build Web services today using both platforms," Microsoft observed that .NET was designed as a platform for Web services. J2EE has Web services bolted on as an afterthought. On .NET, Web services SOAP and WSDL are easy to create, easy to consume and easy to deploy. The same is not true on J2EE.

With response to the Middleware company's "Arguments for .NET and against J2EE" Microsoft observed that:

  • .NET has Microsoft's A-team marketing it.

  • An unfounded opinion such as this is irrelevant in the comparison of two platforms.

  • .NET released their Web services story before J2EE did, and thus has some mind-share.

  • .NET has a better story for shared context today than J2EE.

  • .NET has an awesome tool story with Visual Studio.NET.

  • .NET has a simpler programming model, enabling rank-and-file developers to be productive without shooting themselves in the foot.

  • .NET gives you language neutrality when developing new eBusiness applications, whereas J2EE makes you treat other languages as separate applications.

  • .NET benefits from being strongly interweaved with the underlying operating system.

Microsoft further stated that the authors of the Middleware Company's report failed to note the key advantages of .NET:

  • .NET is designed specifically to support Web services, at all points in the network: servers, clients, devices. J2EE does not have the broad reach of .NET. It focuses on Web services only on the server side. It ignores the huge potential of Web services at the edges of tomorrow's intelligent network.

  • .NET is designed with rocket-fast performance in mind. In contrast, J2EE focuses more on the academic pursuit of OO purity, with consequent costs in performance.

  • .NET is much more secure than any off-the-shelf J2EE offering today. Digital signatures for code, real code versioning, secure downloadable modules J2EE has none of these key capabilities for security.

Microsoft also observed that J2EE does not integrate Web services into the platform and attempts to blur the line between Web services SOAP and WSDL based and its legacy object protocols (RMI/CORBA) to get some of promise of Web services to rub off on its own cumbersome implementation.

Further, in the "Arguments for J2EE and against .NET" section, Microsoft took issue with the statement that "J2EE is being marketed by an entire industry":

  • The J2EE "industry" is in trouble. None of the standard bearers are making any money. BEA is the strongest vendor they have just posted a loss on declining revenues. Every other J2EE app server vendor is losing money on shrinking revenues (Iona, Silverstream, Gemstone, Persistence, ATG, Macromedia), and their stock share prices are way down, some 85% or more. Many are refocusing their strategies (Silverstream, Persistence, ATG, Gemstone, others), in search of a sustainable business. The J2EE ecosystem of software companies is in terrible shape.

With respect to the argument that "J2EE is a proven platform, with a few new Web services APIs. .NET is a rewrite and introduces risk as with any first-generation technology," Microsoft observed that:

  • True, J2EE is proven. But proven as what? It is proven to be expensive (see Gartner's recent claim that companies have overspent $1B on J2EE kit they do not use). It is proven to be slow (see www.gotdotnet.com/team/compare). It is proven to be hard to program (see the code complexity in the J2EE Blueprint called "Pet Store"). It is proven to be incomplete and insufficient (lack of Web services, poor support for XML, no disconnected model, poor code versioning, many other examples).

With respect to the statement "Only J2EE lets you deploy Web services today" Microsoft stated:

  • Not true, or otherwise a very misleading statement. See my comments above: J2EE includes no support for Web services. Crediting J2EE with Web services support is wrong. Customers have to "integrate it themselves" and the vendors aren't supporting it anyway.

With regard to the statement that "existing J2EE code will translate into a J2EE Web services system without major rewrites" Microsoft responded:

  • Not true for Windows DNA code ported to .NET. Windows DNA code can very easily be exposed as SOAP-accessible services with the MS SOAP Toolkit, which was the first production-quality SOAP engine released by any vendor. There is no need to rewrite anything to .NET. Likewise, there is no need to rewrite J2EE apps to expose them as Web services. The situations are very similar.

On the statement "J2EE is a more advanced programming model, appropriate for well-trained developers who want to build more advanced object models and take advantage of performance features" Microsoft issued a qualified "no complaint." Here's the response:

  • No complaint here, if by "advanced" they mean "complicated." As for performance, check out www.gotdotnet.com/team/compare this is a pretty strong indication that .NET applications perform significantly better than J2EE applications. In fact, two years after J2EE was originally released, there is STILL NO EVIDENCE that J2EE delivers competitive performance, or even reasonable performance, as compared to the Microsoft platform. See TPC-C, TPC-W, see any other independent benchmark none include J2EE.

To the statement that "J2EE lets you take advantage of existing hardware you may have" Microsoft responded:

  • Presumably this is an advantage, because J2EE will run on Sparc or RS6000, while Windows and .NET will not. This is true, and also irrelevant for most commercial ventures. Server hardware has a half-life of 2 3 years, according to Moore's Law, with the understanding that servers tend to live longer than desktops. It makes no business sense to recycle server hardware for newly developed apps. Server hardware probably represents 10% or less of the overall system cost for an enterprise application. This potential cost savings is a wash, when considered with the increased software cost of J2EE (see my comments above).

Microsoft next evaluated the claim that "J2EE gives you platform neutrality, including Windows. You also get good (but not free) portability. This isolates you from heterogeneous deployment environments."

  • There is little actual business value here, for enterprises and users of this infrastructure. Do customers often "port" their applications from Solaris to AIX in mid life? or vice versa? No. In fact, the portability of J2EE is possibly its greatest weakness, because (a) the portability is not real, and (b) it conversely exacts a real cost in terms of capability and performance. Building a portable platform means customers cannot take advantage of platform-specific optimizations, like transaction coordinators, resource coordinators, fail-over, and so on (think of all the special services in Windows Server, or in IBM's zOS), UNLESS they do so in a nonportable fashion.

With respect to the view that "J2EE has a better legacy integration story through the Java ConnectorArchitecture (JCA)" Microsoft responded:

  • This is utterly false. JCA is "paper and vapor." Where are the shipping connectors? Where are the reference customers? Microsoft has real customers using our host integration server, with great performance and transactional integrity. We've got 100+ Biztalk connectors today (though it is true we did not have this list of connectors at the time this opinion piece was originally written, in July).

On the topic "J2EE lets you use any operating system you prefer, such as Windows, UNIX, or mainframe. Developers can use the environment they are most productive in" Microsoft responded:

  • Yes, Productivity is the issue. But the OS doesn't affect programmer productivity nearly as much as rich, solid, easy-to-use tools, with intuitive user interfaces. This is Microsoft's strength, as even the authors of the paper acknowledge. VisualStudio.NET makes all the difference for programmer productivity.

Finally, Microsoft suggested that for those interested in tracking the state of Web services interoperability, a good site to visit for further information is: http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnsrvspec/html/globalxmlWebsrvinterop.asp.

A discussion about which platform is better for Web services (Java or .NET) can get quite heated. And developers from both camps can get equally excited about their respective positions. This author's advice is to remember that ultimately Web services will help eliminate cross-platform and cross-development language program-to-program communications disputes. This will cool off the discussions about which is better.



Web Services Explained. Solutions and Applications for the Real World
Web Services Explained, Solutions and Applications for the Real World
ISBN: 0130479632
EAN: 2147483647
Year: 2002
Pages: 115
Authors: Joe Clabby

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net