Though the debate over the superiority of .Net versus that of Java 2 Platform, Enterprise Edition (J2EE) seems a hot topic in today's technology circles, many people believe it is simply a marketing battle of little consequence. Marketing battle or not, the debate's effects will one day prove critical in software evolution. Thus, Sun Microsystems' and Microsoft's executive teams have committed significant marketing budgets in an effort to gain advantage. Should Microsoft lose this battle, the operating system might simply become a lifestyle choice. Sun's victory could one day enable software to run on any operating system, causing Microsoft's dominance in operating systems to slowly fade as other operating systems, capable of running the same software, come to market. On the other hand, should Microsoft succeed, it will further entrench its technology suite as the de facto standard for the foreseeable future.

In this article, we compare the J2EE and .Net technologies to help you decide which one is worth the investment.

Before Web services

When looking back to the brief period preceding the dot-com meltdown (circa 1998-2000), Internet historians point out that many dot-coms duplicated others' work. Most duplication revolved around Website construction. These Websites of antiquity aimed to give their visitors access to myriad information; information, which in hindsight, pertained not to the company's core competency, but rather to its goal of achieving the cool factor. Companies providing this variegated information, which included weather reports, stock quotes, news, mail services, and more, did not typically create it. Hence, these companies would purchase rights to the raw data and its redistribution in a viewable format. After acquiring the raw data, companies would create expensive and time-consuming programs that converted the provider-formatted data to a format that could be rendered to the user, typically HTML.

For example, suppose the Know-Can-Do Company provided a stock quote information service on its Website. To do that, Know-Can-Do obtained raw data from a provider, or the creator -- for example, the Stock-Quote-Provider Company. Know-Can-Do accessed Stock-Quote-Provider's raw data typically through proprietary technology (e.g., installed software) and expensive hardware (e.g., leased lines). Know-Can-Do then created parsing applications that converted the raw data into HTML. Figure 1 illustrates this process. Notice the light-blue line, which denotes a proprietary and expensive communication system between Know-Can-Do and Stock-Quote-Provider.

Figure 1. Data movement and manipulation using proprietary technology

Since Know-Can-Do wished to compete with dominant Web portals such as AOL, MSN (Microsoft Network), Yahoo!, and Excite, the pressure to provide more information increased exponentially. To remain competitive, Know-Can-Do needed to add weather and news facilities. Figure 1's model proved tedious since disparate technologies used to source data from multiple vendors was often unmanageable from a logistics and cost perspective. Raw data transfer had to be more cost effective, plus Know-Can-Do required an easier way to convert the data to a standard form (e.g., HTML, WML (Wireless Markup Language), Voice XML). Enter the Web service strategy.

What is a Web service?

The Web service emerged as the solution for providing a standard way to retrieve data without proprietary software and hardware. A Web service cornerstone is its ability to transfer data from the provider to the consumer, or requester, using the ubiquitous HTTP protocol; the data format is XML. Formatting the data in XML greatly facilitates raw data's conversion into a renderable format. Extensible Stylesheet Language Transformations (XSLT) perform the transformation rather easily, without complex parsing programs, as Figure 2 illustrates.

Figure 2. A conceptual depiction of an XSL transformation

A commissioned whitepaper for Sun defines a Web service as:

An application that accepts requests from other systems across the Internet or an intranet, mediated by lightweight, vendor-neutral communications technologies.

In "Defining the Basic Elements of .Net," Microsoft describes a Web service as:

XML Web services let applications share data, and -- more powerfully -- invoke capabilities from other applications without regard to how those applications were built, what operating system or platform they run on, and what devices are used to access them.

You can deduce some good news from the above definitions: both Sun and Microsoft seem to tacitly agree. From a purely intuitive level, a Web service is a service consumed via the Internet. More specifically, a Web service is invoked via HTTP and returns data to the consumer in XML.

Paradigm shift

Web services signify a shift in software development paradigms. While many companies still debate Web services' viability, companies like Concord EFS reap millions of dollars from their in-production credit card-processing Web service. Web services advocate that we should segment large applications so individual components can exist as Web services. This model would arguably replace the current paradigm: segmentation into dynamic link libraries (DLL) and COM (Component Object Model) components.

In fact, we can draw a strong analogy between Web services and DLLs. Both centralize related functionality; for example, business rules and database access. However, Web services and DLLs differ significantly. First, you can access Web services through the HTTP protocol, thus allowing any Web client to invoke Web services. This is not the case with DLLs, which are typically invoked from clients within the same intranet. Thus, Web services will usher in a new distributed computing era. Second, Web services return data to the client in XML. DLLs typically return data through programming language-specific data types.

These differences between Web services and their DLL ancestors result from the major industry trends that preceded Web services:

  1. The acceptance of HTTP as a protocol through which users access the Internet
  2. The acceptance of XML as the de facto standard for data transfer

These two trends provide the foundations upon which the Web service is built. Figure 3 illustrates how Know-Can-Do would use Web services. Notice the absence of leased lines and proprietary data formats.

Figure 3. Case example architected using a Web service approach

Java 2 Platform, Enterprise Edition

It seems that even those who understand Web services often misunderstand J2EE. Other than developers, most people believe that J2EE is a product you buy from Sun as you would .Net from Microsoft. On the contrary, J2EE is a set of specifications, each of which dictates how various J2EE functions must operate. For example, the Java Transaction Service (JTS) specification identifies how to build a service that allows distributed transactions. Sun provides reference implementations for these specifications, which you can use for compliance testing.

So if you don't buy J2EE from Sun, how does Sun make money? Sun makes money by licensing J2EE to independent software vendors who implement these specifications into products and sell them to the market. If you want to purchase a J2EE implementation, you would do so from a vendor who has developed a J2EE-compatible implementation. To find J2EE-compatible implementations, go to

To find J2EE licensees, go to You'll notice Microsoft is noticeably absent, a consequence of a lawsuit that resulted in a 0 million settlement.

Though not specifically created with Web services in mind, J2EE's servlet technology allows Web service development. A servlet performs all processing, including calls to Enterprise JavaBeans (EJBs) that return data to the servlet. The servlets then formulate a response and package it in XML for return to the client. Sun's new Java Web Services Developer Pack (WSDP) provides a single download for Java Web services development. It features the Java XML Pack, which abstracts developers from much of the low-level parsing, plus JavaServer Pages (JSP) Standard Tag Library 1.0, Ant 1.4.1, Java WSDP Registry Server 1.0, and Tomcat Java Servlet and JSP container 4.1.

Microsoft's .Net

Before we examine Microsoft's .Net solution, we must understand some of the events that triggered the .Net initiative. Towards the end of 1995, Microsoft began to shift its attention to the Internet; the company arrived late to the game as a result of its focus on Windows 95. At that time, Netscape was gobbling up market share, while Microsoft struggled to launch its own Internet browser. Microsoft used its incredible marketing arm (let's avoid a monopoly debate) to introduce Internet Explorer and destroyed Netscape's lead, which then boasted more than 16 million users.

During this same time, Microsoft scrambled to deliver technologies such as Active Server Pages (ASP). The technology was effective, yet lacked sophistication; after all, it provides a scripting environment, a step backwards from object-oriented development. We can imagine the development teams at Microsoft rushing to ship software, as if it were a Silicon Valley startup. The company developed many of these technologies in Internet time, and some early technologies missed their mark. You might remember Active Documents, the Visual Basic add-on that enabled Visual Basic developers to create Web applications with no additional programming. Active Documents died a quiet death. We must remember these technologies, because in our .Net assessment, we must be able to asseverate that Microsoft is not crying wolf.

Microsoft's marketing strategy is to penetrate and radiate. Microsoft enters the market with technologies that feature basic functionalities. Some technologies fail; many improve until they turn into industry standards. The real question here: Is .Net on the mark, or is Microsoft bluffing?

To be fair, we must credit Microsoft for promoting Web services' significance to developers. The company has done such a terrific job with its almost unlimited marketing budget that many people actually credit Microsoft with developing the initial technologies enabling Web services -- a feat that, in all fairness, should be attributed to Sun and its servlet technology. We could further argue that servlets were a solution developed in response to Microsoft's ASP technology. And so one begets the other, which begets the other, which begets the other, ad infinitum. (Larry Seltzer reiterates this point in "Shadow Initiatives: .Net and Java" (ZDNet, January 2002).)

Now that developers recognize Web services' importance, we should expect more companies to divide their software packages into various Web services, which the companies will then sell to other companies. Again, Microsoft has assumed pole position as one of the first to provide such Web services with a large potential user base. For example, developers will use HailStorm services -- software building blocks for Microsoft's .Net strategy -- to perform tasks such as messaging, scheduling, and notification. Perhaps the most visible HailStorm service, Microsoft's Passport provides unique user identifications and authentications. According to Microsoft statistics, Passport currently provides over 1.5 billion authentications per month. Hotmail is arguably the world's most active Web service, and its users will recognize the Passport logo on the default page.

To capitalize on the Web service evolution, Microsoft has launched its .Net initiative. While .Net differs architecturally from its DNA (Distributed Internet Architecture) origins, from a Web service viewpoint, it offers few new features, save the significant strides in the ASP offering, named ASP.Net. ASP.Net now offers a full programming language environment rather than its prior scripting-based environment. Perhaps the most significant .Net aspect is that Visual Basic is finally object-oriented. Other admirable features, not available in Sun's offering, include ASP.Net's capability to render pages in various HTML formats, which abstracts developers from version-specific HTML. Servlets can achieve this same task, though with more manual coding.

.Net is innovative in that it doesn't compile applications into native code -- that is, it doesn't compile applications into Intel-specific code, for example. Instead, the compilation is now a two-step process. The developer-written code compiles into Microsoft Intermediate Language (MSIL). Then, the Common Language Runtime (CLR) compiles the code into native code at execution. Does this sound familiar? Microsoft, it seems, isn't above watching and learning. .Net includes C#, a language that bears a remarkable resemblance to Java. Microsoft has also provided a program that converts Java code to C#.

Rumors abound that developers are already working on a Linux CLR. If the rumors hold merit, the CLR would serve as a port to allow .Net-developed applications to work on Linux. That could negate Java's major advantage of platform independence.

.Net vs. J2EE

While J2EE and .Net differ technically, we won't delve into such minutiae in this article. Instead, we address the two most significant distinctions -- the way J2EE and .Net address multiplatform and multilanguage issues.


Page 2 of 2

From a developer perspective, both J2EE and .Net provide the tools to create Web services. While J2EE boasts multiplatform support, if we believe Microsoft, J2EE might not enjoy this advantage for much longer. Microsoft has positioned its .Net offering to use a two-step compilation process, which allows Microsoft to provide runtime environments for different platforms similar to Java.

Eric Rutter, Microsoft's senior vice president of evangelism, substantiated the rumors of a FreeBSD port for .Net. FreeBSD is a compatible operating system derived from BSD (Berkeley Software Distribution) Unix. He claimed that Microsoft is indeed building a runtime environment for FreeBSD. Though FreeBSD support might challenge Java's exclusive platform independence, we shouldn't bank on it just yet. It might take years before CLRs for the most popular operating systems are developed. Furthermore, Microsoft once made similar claims to port DCOM (Distributed Component Object Model) to other platforms. These ports never materialized.

Currently, J2EE is the only development environment that offers platform independence.


J2EE's single language foundation (Java) starkly contrasts with the .Net offering, which supports more than two dozen languages, including Fortran, COBOL, C++, and Visual Basic. While we could argue that a single language provides a more elegant solution, we must admit that .Net offers an advantage to organizations wishing to leverage its knowledge workers' IT expertise. For those developers currently using languages other than Java, .Net lets them create Web services in their current language with minimal training.

Microsoft's strategy might relegate Java as just another programming language. Sun's defense: Java is not just a language, but a platform.

Check out the sidebar "Microsoft and Sun compare .Net and J2EE," in which we discuss with both vendors the two platforms' differences, similarities, and relative strengths.

Test both platforms

While .Net and J2EE comparisons indeed generate interesting debate, we should not lose focus of these solutions' vision. Either technology will allow you to build Web services that consumers using disparate technologies can access. A .Net Web service could serve as a consumer to a J2EE Web service and vice versa because of the standards Web services provide. Furthermore, even if one solution proves superior, it will provide superior efficacy only when used by a superior developer. The tools are only as good as the developer who yields them.

From an industry viewpoint, some believe that .Net and J2EE's relative success will depend on their marketing departments. Both technologies are so similar that the differences are negligible.

Ironically, Sun should heed its Java pioneer James Gosling, who at the recent InfoWorld Next-Generation Web Services Conference said these sagacious words:

Web services provide a homogenous view of a heterogeneous environment.

This being the case, Web services should end the discussion about which platform is best; developers need not worry about their platform when building a service since Web services present a homogenous view.

In closing, we suggest you build a Web service with both .Net and J2EE. You will quickly know which platform works best for you. In selecting a vendor, many people concede to the following rule of thumb: if you are committed to a homogenous Microsoft platform now, then choose .Net, otherwise choose J2EE.

Jonathan Lurie has been implementing commercial information systems for almost a decade. He has worked with Java since 1997. He holds a bachelor's degree in computer science as well as several certifications. When not working on a new software system, he enjoys mentoring, writing, and teaching. R. Jason Belanger has been implementing Web-based applications for more than five years. He has designed and developed a half-dozen large-scale commercial sites. He is currently a principal of

Learn more about this topic