I. Preface

---

Some of the statements we make will offend you, and hopefully more of them will agree with you. So as you read this paper, please remember our three promises:

1. We promise to compare these choices at a logical, neutral, and unbiased level.
2. We promise to tell the tale about how we really do feel about these technologies.
3. We promise to dispel the Fear, Uncertainty, and Doubt (FUD) that exists in the marketplace today.

Although both J2EE and .NET cover a great deal of technologies and standards, we will focus specifically on building server-side systems as web services using these architectures (for example, we will not be mentioning Jini or Office XP). After reading this white paper, you will have a solid understanding of how these architectures compare, and be empowered to make intelligent decisions in new web services initiatives.

The first half of this Document is background information about web services, J2EE, and .NET. If you already understand these technologies, feel free to skip ahead to the 2nd half of the paper, which is the juicy comparison.

II. Introduction

---

The next generation of distributed computing has arrived. Over the past few years, XML has enabled heterogeneous computing environments to share information over the World-Wide Web. It now offers a simplified means by which to share process as well. From a technical perspective, the advent of web services is not a revolution in distributed computing. It is instead a natural evolution of XML application from structured representation of information to structured representation of inter-application messaging. The revolution is in the opportunities this evolution affords.

"A collection of functions that are packaged as a single entity and published to the network for use by other programs. Web services are building blocks for creating open distributed systems, and allow companies and individuals to quickly and cheaply make their digital assets available worldwide."

Prior to the advent of web services, enterprise application integration was very difficult due to differences in programming languages and middleware used within organizations. The chances of any two business systems using the same programming language and the same middleware was slim to none, since there has not been a de-facto winner. These 'component wars' spelled headaches for integration efforts, and resulted in a plethora of custom adapters, one-off integrations, and integration 'middlemen'. In short, interoperability was cumbersome and painful.

With web services, any application can be integrated so long as it is Internet-enabled. The foundation of web services is XML messaging over standard web protocols such as HTTP. This is a very lightweight communication mechanism that any programming language, middleware, or platform can participate in, easing interoperability greatly. These industry standards enjoy widespread industry acceptance, making them very low-risk technologies for corporations to adopt. With web services, you can integrate two businesses, departments, or applications quickly and cost-effectively.

The vision for web services predicts that services will register themselves in public or private business registries. Those web services will fully describe themselves, including interface structure, business requirements, business processes, and terms and conditions for use. Consumers of those services read these descriptions to understand the abilities of those web services. Web services will be smart, in that once a service has been invoked, it will spontaneously invoke other services to accomplish the task and to give users a completely personal, customized experience. In order for these services to dynamically interact, they need to share information about the user's identity, or context information. That context information should only need to be typed in once, and then made available at the user's discretion to selected web services.

Building web services with technologies that have gained the most acceptance

Now that we've seen the general philosophy behind web services, let's look at how to build and use a web service. Web services are in reality simply XML-based interfaces to business, application, and system services, and are really old technologies wearing a new hat. The following technologies that have gained the most industry acceptance, and is one possible way to perform web services:

• A provider creates, assembles, and deploys a web service using the programming language, middleware, and platform of the provider's own choice.
  
  
• The provider defines the web service in WSDL (the Web Services Description Language ). A WSDL document describes a web service to others.
  
  
• The provider registers the service in UDDI (Universal Description, Discovery, and Integration ) registries. UDDI enables developers to publish web services and that enables their software to search for services offered by others.
  
  
• A prospective user finds the service by searching a UDDI registry.
  
  
• The user's application binds to the web service and invokes the service's operations using SOAP (the Simple Object Access Protocol ). SOAP offers an XML format for representing parameters and return values over HTTP. It is the communications protocol that all web services use.

Note that the above technologies are only sufficient for simple web services. Extended business exchanges require an agreed-upon structure for business transactions, multi-request transactions, schemas, and document flow. These application requirements often stretch the limits of a purely SOAP based implementation. This is the motivation for ebXML, which is a suite of XML specifications and related processes and behavior designed to provide an e-infrastructure for B2B collaboration and integration.

Note that the above approach is but one way of making web services work. There are other choices as well, but we feel that these technologies are the most important and will achieve the widest industry adoption. Because of this, in reality, we really haven't reached complete consensus on building web services, and there are still a lot of issues to be resolved. For example, there is vendor disagreement on SOAP extensions, ebXML, and service flow descriptions. The good news is that:

• For once, all major players, including Sun and Microsoft, generally agree that SOAP, WSDL, and UDDI are good things and that they (or their standard derivatives) will provide a foundation for the future.
  
  
• All the vendors are working together to establish web services standards, and a foundation is emerging.

The J2EE and Microsoft.NET approach to Web Services

If you want to build a usable web services system, there is more than meets the eye. Your web services must be reliable, highly available, fault-tolerant, scalable, and must perform at acceptable levels. These needs are no different than the needs of any other enterprise application.

J2EE and .NET are evolutions of existing application server technology used to build such enterprise applications. The earlier versions of these technologies have historically not been used to build web services. Now that web services has arrived, both camps are repositioning their solutions as platforms that you can also use to build web services.

The shared vision between both J2EE and .NET is that there is an incredible amount of 'plumbing' that goes into building web services, such as XML interoperability, load-balancing, and transactions. Rather than writing all that plumbing yourself, you can write an application that runs within a container that provides those tricky services for you.

This paradigm allows you to specialize in your proficiencies. If you were a financial services firm, for example, you'd have proficiency in financial services, but likely very little proficiency in web services plumbing compared to a specialist such as Sun, IBM, BEA, Oracle, or Microsoft. By purchasing the container off-the-shelf, you won't need to be an expert at plumbing to build a financial services-based web service. Rather you just need to understand their business problem at hand, and leave the web service plumbing to the container.

With that said, let's take a look at the details of each vision.

III. J2EE

---

The Java 2 Platform, Enterprise Edition (J2EE) was designed to simplify complex problems with the development, deployment, and management of multi-tier enterprise solutions. J2EE is an industry standard, and is the result of a large industry initiative led by Sun Microsystems.

It's important for you to realize that J2EE is a standard, not a product. You cannot "download" J2EE. Rather you download a set of Adobe Acrobat PDF files which describe agreements between applications and the containers in which they run. So long as both sides obey the J2EE contracts, applications can be deployed in a variety of container environments.

The J2EE camp's goal is to give customers choice of vendor products and tools, and to encourage best-of-breed products to emerge through competition. The only way this would ever happen is if the industry as a whole were bought-into J2EE. To secure buy-in, Sun collaborated with other vendors of eBusiness platforms, such as BEA, IBM, and Oracle, in defining J2EE. Sun then initiated the Java Community Process (JCP) to solicit new ideas to improve J2EE over time. The reason Sun did this is because they had to do so to achieve success--the best way to secure buy-in to an idea is to involve others in defining that idea.

Java: The foundation for J2EE

The J2EE architecture is based on the Java programming language. What's exciting about Java is that it enables organizations to write their code once, and deploy that code onto any platform. The process is as follows:

1. Developers write source code in Java.
2. The Java code is compiled into bytecode, which is a cross-platform intermediary, halfway between source code and machine language.
3. When the code is ready to run, the Java Runtime Environment (JRE) interprets this bytecode and executes it at run-time.

J2EE is an application of Java. Your J2EE components are transformed into bytecode and executed by a JRE at runtime. Even the containers are typically written in Java.

J2EE and Web Services

J2EE has historically been an architecture for building server-side deployments in the Java programming language. It can be used to build traditional web sites, software components, or packaged applications. J2EE has recently been extended to include support for building XML-based web services as well. These web services can interoperate with other web services that may or may not have been written to the J2EE standard.