The great debate: .Net vs. J2EE

Does one Web services platform dominate the other?

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 http://java.sun.com/j2ee/compatibility.html.

To find J2EE licensees, go to http://java.sun.com/j2ee/licensees.html. 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.

1 2 Page
Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies
See more