Lurie, Jonathan; Belanger, R. Jason; .NET; J2EE: The great debate: .Net vs. J2EE - Does one Web services platform dominate the other?, in: JavaWorld.com, JavaWorld.com 2002.

THEMES: Lurie, Jonathan | Belanger, R. Jason | .NET | J2EE
META STRUCTURES: J2EE vs. .NET
YEAR: 2002
Login Login
User: Anonymous


LABEL: J2EE | Web Services | .NET
ORGANIZATIONS: Microsoft | Sun
THINGS: comparison | Platform
TIME: 2002
 
Source: http://www.javaworld.com/javaworld/jw-03-2002/jw-0308-j2eenet_p.html

The great debate: .Net vs. J2EE

Does one Web services platform dominate the other?

      Summary
      Java 2 Platform, Enterprise Edition (J2EE) and .Net are competing technologies that both contribute to Web service creation. In this article, Jonathan Lurie and R. Jason Belanger describe a Web service and compare J2EE's major components with .Net's. With this ammunition, you can power your way through a conversation concerning how Web services will benefit your department's strategic direction. (
      2,600 words; March 8, 2002)
By Jonathan Lurie and R. Jason Belanger

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 $20 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.

Multiplatform
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.

Multilanguage
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.

About the author
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 NoFeeListing.com.



Microsoft and Sun compare .Net and J2EE

We posed a few questions to both Microsoft and Sun in January. Here is what they had to say:

Jonathan Lurie: How are .Net and J2EE similar?

John Montgomery, Microsoft's group product manager for the .Net framework: Both the J2EE specifications and Microsoft .Net are similar in that both can accelerate and simplify business application development. Microsoft .Net is a platform comprising servers, clients, and services. It consists of a set of applications such as Visual Studio .Net, the Tablet PC, and the .Net My Services. Microsoft .Net was designed to address current and future customer needs about how applications will be built, deployed, and operated. The shift in how customers are building and deploying software -- particularly the shift from building proprietary software to buying software and customizing and integrating it -- is a Microsoft .Net foundation principle. Microsoft .Net was built for integration through XML Web services using protocols and file formats such as SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language), and UDDI (Universal Description, Discovery, and Integration).

By contrast, the J2EE specifications are just that -- specifications. They define a small portion of a complete platform focused on server-side application development. These specifications, such as the JSP and EJB specifications, clone the Microsoft Windows 2000 operating system. For example, JSP is a direct clone of Microsoft's Active Server Pages, and EJB is a clone of some of Windows' COM+ features. J2EE is largely a set of specifications designed to make building server-side applications on Unix systems easier.

David F. Harrah, marketing manager for Java and XML software, Sun Microsystems: Primarily, both provide an application and services development and deployment platform, combining an object-oriented language with an application-execution component. In Java's case, the Java language code is compiled into bytecode, which is executed in the Java Runtime Environment (JRE). .Net-supported languages translate into Microsoft Intermediate Language, which the Common Language Runtime (CLR) interprets and translates into a native executable.

The new Microsoft C# language resembles Java. J2EE is a Java technology implementation that combines the base Java technology with additional enterprise-oriented components, such as EJBs and JSPs.

Both are intended for use by developers building networked applications.

Lurie: How do .Net and J2EE differ?

Montgomery: First, J2EE is a Sun specification set designed prior to the advent of XML Web services, the new integration technology embraced by the industry. Microsoft .Net is an implementation set built on open standards such as SOAP, WSDL, C#, and the CLI (command line interface). In addition, J2EE is a server-focused specification set whereas Microsoft .Net offers a complete platform. Finally, J2EE still doesn't sport a standard API set for XML Web services. By contrast, with Microsoft .Net, XML Web services are innate to the platform. (Editors' note: Since this interview, Sun has released the Java Web Services Developer Pack: http://java.sun.com/webservices/downloads/webservicespack.html.)

A second, and major differentiator, is that Microsoft .Net is designed to support multiple programming languages -- currently, Microsoft .Net supports more than 20 languages, enabling virtually any developer to get up to speed building .Net applications today without retraining. By contrast, J2EE supports only one programming language: Java.

Harrah: First, Java is the product of more than 400 companies and organizations innovating together; .Net is the product of one company. The Java technology is maintained and enhanced by the Java Community Process, a group of more than 400 companies, organizations, and individuals innovating together to create an application and services platform that runs on any system type. The Java Community Process forms expert groups comprised of interested members, who collaborate to define new specifications and to enhance existing ones. Key votes throughout the process ensure that Java remains a level playing field for all, without favoring any one company.

Java applications run on any operating system: enterprise systems like Unix, Linux, OS/390, Windows 2000, or HP-UX; desktop operating systems such as Mac OS, Windows, or Linux; and mobile device operating systems such as Palm OS or Symbian's EPOC. .Net was developed entirely by Microsoft and runs only on Microsoft operating systems.

The Java technology is an open technology and built to industry standards. Anyone can download or study the source code for the entire platform. Microsoft has opened some of the .Net technology, such as the C# language, but Microsoft tightly holds the platform's key portions, which are not openly published. Microsoft makes portions of its source code selectively available to some handpicked partners. The last number I saw was 1,500.

.Net is a new platform from Microsoft, only available in beta versions. The Java technology has been in use for almost six years, which means that a great deal of experience and infrastructure has been incorporated into the various versions of the Java editions. J2EE is currently on its third version, with the Java Community Process defining the fourth version. (Editors' note: Since this interview, Microsoft has released Microsoft Visual Studio .Net: http://msdn.microsoft.com/vstudio/.)

Lurie: In what way does J2EE have an advantage over .Net?

Montgomery: J2EE's main advantage is that you can purchase implementations of the baseline specifications from several vendors.

Harrah: The Java technology was built from the ground up with the network in mind. It recognizes the network's heterogeneous nature and is supported on all the operating systems and chip architectures in use on today's networks. A strict security model was designed into Java from the beginning, so Java is not as susceptible to hackers and viruses as Microsoft products.

Java supports not only Web services, but also other kinds of services like wireless data services and services on demand. Java supports Web services technologies like XML, SOAP, and UDDI and was listed in an Evans Data Corp. Developer Survey as the number one tool used by developers to build Web services. I have not seen Microsoft articulate in detail how it supports wireless data services in .Net. Meanwhile, at least 15 million Java-enabled phones are in use with wireless data services, especially in Japan.

Lurie: In what way does .Net have an advantage over J2EE?

Montgomery: The main benefit of Microsoft .Net is that it's a complete platform -- J2EE is only oriented toward server development. More than that, J2EE is just a specification set -- you must purchase an expensive (usually $15,000/CPU) implementation of the J2EE specifications to make them real. Microsoft .Net, by contrast, is a set of products and services. In addition, Microsoft .Net has XML Web services built into the platform rather than as a simple bolt-on to a tool. This leads to substantial performance and developer productivity gains. Microsoft .Net was also built for integration through XML Web services using protocols and file formats such as SOAP, WSDL, and UDDI.

As I mentioned before, Microsoft .Net supports multiple programming languages; J2EE supports only one: Java.

Harrah: I can't think of any.