Communications of the ACM

E-services

The Web Services Debate: J2ee vs. .net

By Joseph Williams
Communications of the ACM, June 2003, Vol. 46 No. 6, Pages 58-63
10.1145/777313.777342
Comments

Two of the leading companies in the high-tech field are competing for that vote with architectures that promise to build and orchestrate distributed applications. There's been much speculation regarding Microsoft's .NET and Sun Microsystems' J2EE approaches to Web services solutions. Here, Joseph Williams, Master Architect, Sun Professional Services, and Gerry Miller, chief technology officer for Microsoft's U.S. Central Region, argue the strengths, advantages, and implications of these systems.

The mere utterance of the word "integration" in a meeting of experienced IT professionals can clear the room faster than a Paul Anka song at a college rave. Hardly a Dilbert cartoon storyline doesn't at some point mock the integration claims of some weasel of a vendor or of a hapless engineer (or both!). For all the skepticism, derision, fear, and loathing directed at integration as a concept, a widely used rule of thumb is that 60% of IT costs are absorbed by integration efforts. Integration is staggeringly important but remains a numbingly difficult activity.

One of the many very good reasons that Web services have been given a lot of attention is because they have the potential to dramatically mitigate the complexities and the costs of integration projects. Formal analyses of these claims are still in the offing, but anecdotal evidence suggests that significant reductions in lead times and investments are being achieved by Web services deployments. The now-famous example of the Southwest Airlines/Dollar-Rent-a-Car Web services integration achieved reduced transaction costs by 80%.¹ Merrill Lynch reported they recently brought in a budgeted $800,000 project for $30,000 when they switched to a Web services solution.²

---

In point of fact, the realization of Web services as a common communications infrastructure requires cooperation between the J2EE and .NET factions.

---

At the bottom line, Web services are of interest in large part because they promise a common communications infrastructure that will be supported by all of the major application vendors and development shops. There are still a number of major shortcomings to Web services that need addressing before they can be anointed as a linqua franca for integration (security and workflow management are just two obstacles) and it is not at all clear at this point that SOAP, XML, HTTP, UDDI, and WSDL will be the ultimate enabling platforms for Web services.³ However, there is considerable momentum behind Web services; although Web services may not yet be a mature technology, they have clearly arrived. Unlike previous attempts at interoperability (for example, DCOM, CORBA), Web services take a loosely coupled approach that is appealing at many levels.

Development and deployment of Web services requires no specific underlying technology platform. However, the 600-pound gorillas on the scene are Microsoft's .NET framework and the Java Community Process' (JCP) J2EE specification. Since Sun Microsystems invented the Java programming language and is one of its most vocal proponents, the Web services platform debate is often viewed as a Sun vs. Microsoft or J2EE vs. .NET confrontation. Indeed, there is some philosophical and business animus but it does not detract from the core commitments both companies (and, indeed, virtually all companies) have to making Web services successful as common communications infrastructure. In point of fact, the realization of Web services as a common communications infrastructure requires cooperation between the J2EE and .NET factions.

Figure 1.

.NET is a Microsoft-centric approach to Web services. It runs on a single platform (Windows) but it does natively support multiple languages (although each is a value-added purchase for the .NET development platform and C# is still the language of choice). J2EE, on the other hand, is a platform-independent solution deployed in a single language (Java), although it does have support for other languages. J2EE is the more mature and proven technology. Microsoft has made a massive investment in its .NET framework and, in many respects, has staked the credibility and future of the company on .NET. Both J2EE and .NET present different challenges and opportunities in the application environment.

The development platform that should be adopted will depend on a number of factors, including the development/business environments, the exigencies being addressed, and the enterprise's objectives for the project. As with any tools choice, J2EE vs. .NET is an "it depends" proposition (see "It Depends" sidebar).

In the final analysis, however, J2EE has much more going for it than does Microsoft's .NET. By most accounts J2EE is the platform of choice for 55–70% of Web services deployments.⁴ It has broad support from the major vendors (for example, SAP, Oracle, IBM, HP, PeopleSoft, BEA) and provides the ISVs with the greatest platform flexibility.

Figure 2.

Microsoft and Sun Microsystems are basically in accord on what Web services are, how they work, and their value to the development community. The issue isn't whether Web services are valuable—we all agree (including IBM, HP, and virtually the rest of the industry) they are. The issue is how to implement them. Thus, it truly is a J2EE vs. .NET debate. And, although Sun Microsystems is the flag bearer for J2EE, it is Microsoft against the entire Java community when it comes to deploying Web services. And Java has a serious head start that all of Microsoft's investment dollars cannot easily overcome.

Back to Top

Microsoft's .NET

.NET is Microsoft's attempt to develop a comprehensive execution environment that includes everything a company would need to implement Web services on Windows. In many ways .NET is Microsoft's Windows-centric response to J2EE. Much of the hype around .NET is just rebranding of existing products. The current centerpiece of .NET is the .NET development platform. A huge product (the zipped file is 1.8GB and expands to more than 24,000 files), Visual Studio .NET is an update to Visual Studio 6 that directly supports the new languages Microsoft is promoting for developing Web services: C#, which is a new language that looks a lot like Java; J#, an even closer implementation of Java syntax and libraries; and VB.NET, a substantial update to Visual Basic.

The bottom line on .NET is that it only runs on Windows servers. Thus, it is completely a Microsoft-centric technology. Yes, it does support dozens of different languages so it is a very rich development platform (of course, each language module must be individually licensed at considerable cost). However, the deployment platform is pure Microsoft, meaning the technology has limited reach in the kinds of heterogeneous environments that persist at most enterprises.

Microsoft has been running a series of attacks on J2EE that feature their .NET rewrite of the Java Pet Store study.⁵ Quoting The Middleware Company (TMC) in October 2002, Microsoft stated:

The TMC team spent four months performing this benchmark. They worked 100 hours per week on this and worked every weekend, skipping holidays. Trust me, they were trying very hard to make J2EE win. But in the end, J2EE did not come out on top. TMC had a lot of heartache seeing the results of this benchmark. We internally debated about whether we should post this or not. In the end, we decided to go forward and publish this report.

Figure 3.

In fact, TMC is obscure and certainly not a definitive source for information on J2EE (that is, it's all FUD—fear, uncertainty, and doubt). Microsoft will also cite a VeriTest report saying that .NET is 10 times faster than J2EE.⁶ This report is also little more than FUD and has been countered effectively by Oracle (otn.oracle.com/tech/java/oc4j/pdf/9ias_net_bench.pdf). And, since the announcement of its results TMC is considering a rematch based on feedback it received on flaws to its approach.⁷

The Java Pet Store was never designed to be a benchmarking platform, as all but Microsoft acknowledge. It isn't even clear yet how to make meaningful performance comparisons between .NET and J2EE that involve large-scale, highly concurrent, high-availability applications. Thus, at this early stage all the Microsoft performance FUD falls under the broad category of "lies, statistics, and benchmarks."

Even so, Microsoft's commitment to .NET should not be underestimated. In addition to rebranding their entire product line as ".NET" they have reportedly invested four years and millions of hours in producing its .NET development environment.⁸ They have supposedly invested more than $6 billion in new money already in developing the .NET story (by contrast, Sun Microsystem's total R&D budget is estimated to be about $1.8 billion per year). To spread the .NET gospel, Microsoft and Hewlett-Packard have jointly invested $50 million to train 5,000 HP sales professionals on .NET, to get 3,000 HP Services professionals certified on .NET, and in forming a new group of .NET solution architects in HP's services group.⁹

Back to Top

J2EE

The Web services promise of loosely coupled components existing in a build once/use-many environment finds its natural expression in J2EE. Although J2EE is Java-centric it does have the ability to run on any operating system; thus it represents the flip side of .NET. J2EE is one language, many platforms. .NET is many languages, one platform (although, arguably, that actually isn't true since most of the powerful tools for .NET are designed specifically for C#; thus, it really is one full-featured language on one platform).

The bottom line on J2EE is that on a feature-by-feature basis it compares very favorably with .NET (see Figure 4).

Moreover, all of the specifications that define the J2EE platform are published and reviewed publicly, and numerous vendors offer compliant products and development environments. This simply isn't true with .NET.

J2EE is more mature than .NET and even though XML is not yet native (it will be in JDK 1.5) much of the vision implemented by Web services was presaged in J2EE.

Back to Top

.NET Claims Against Sun and J2EE

The software community expected Sun to step right up and announce a well-articulated vision to counter Microsoft's marketing machine around .NET. For whatever reason, analysts now claim it didn't happen:

"To the disappointment of many, Sun announced only some XML interfaces to Java and little else. No overarching vision, no clever sound bites. Nothing. As can be seen from the companion interview¹⁰ with Marge Breya, vice-president in charge of Sun ONE, there is still no vision beyond promoting Solaris, the iPlanet application server, and the Liberty Alliance. (DevX Special Report)."¹¹

This perception, unfortunately, is widely held and a number of influential commentators have stated that Sun Microsystems missed the Web services wave. This simply isn't true (after all, Sun's own John Bosak was on the forefront of XML's invention), but the misperception lingers. J2EE support for Web services has always been implemented in the J2EE Web Services Pack and, as mentioned earlier, Web services will be native to J2EE in JDK 1.5.

Microsoft claims the default interpretive mode of Java is a liability (it has stated this in response to several lawsuits filed against the company) in that bytecodes designed for a virtual machine do not lend themselves as well to native optimization. There is no hard data to prove or disprove that claim, either generally (bytecodes vs. native-compiled languages) or specifically (Java vs. C#) so this claim is also little more than marketing FUD.

Back to Top

Conclusion

Both Sun and Microsoft are articulating clear visions around Web services. J2EE and .NET are different tools embodying different strategies for implementing Web services. It is pointless to argue currently that one tool is superior to the other. Instead, the focus needs to be on ensuring the right tool is deployed; for most enterprise shops J2EE offers more flexibility, greater robustness, and a proven pedigree.

Back to Top

Back to Top

Back to Top

Back to Top

The Digital Library is published by the Association for Computing Machinery. Copyright © 2003 ACM, Inc.