J2EE V.S. .NET

J2EE Components

• JSP
• EJB
• JCA
• JMS
• JMX
• JNDI
• JDBC
• HotSpot VM

.NET Components

• Smart Client Software
• XML Web Services
• Enterprise Servers
• Development tools/Runtime Environment

J2EE Service Description

J2EE-enabled Web Services exchange information with interested parties using WSDL to come to an agreement on the proper format for each transferred XML document.

.Net Service Description

As with a J2EE Web Service, a .NET Web Service supports the WSDL 1.1 specification and uses a WSDL document to describe itself. In this case, however, an XML namespace is used within a WSDL document to uniquely identify the Web Service's endpoints.

• .NET provides a client-side component that lets an application invoke Web Service operations described by a WSDL document and a server-side component that maps Web Service operations to COM-object method calls as described by a WSDL and a Web Services Meta Language (WSML) file. This file is needed for Microsoft's implementation of SOAP (Simple Object Access Protocol)

J2EE Service Implementation

Existing Java classes and applications can be wrapped using the Java API for XML-based RPC (JAX-RPC) and exposed as Web Services. JAX-RPC uses XML to make remote procedure calls (RPC) and exposes an API for marshalling (packing parameters and return values to be distributed) and un-marshalling arguments and for transmitting and receiving procedure calls.

With J2EE, business services written as Enterprise JavaBeans are wrapped and exposed as Web Services. The resulting wrapper is a SOAP-enabled Web Service that conforms to a WSDL interface based on the original EJB's methods.

The J2EE Web Services architecture is a set of XML-based frameworks, providing infrastructures that allow companies to integrate business-service logic that was previously exposed as proprietary interfaces. Currently, J2EE supports Web Services via the Java API for XML Parsing (JAXP). This API allows developers to perform any Web Service operation by manually parsing XML documents.

.Net Service Implementation

.NET applications are no longer directly executed in native machine code. All programs are compiled to an intermediate binary code called the Microsoft Intermediate Language (MSIL). This portable, binary code is then compiled to native code using a Just In Time compiler (JIT) at run time and run in a virtual machine called the Common Language Runtime (CLR). With the .NET platform, Microsoft will provide several languages based on the Common Language Infrastructure (CLI), such as Managed C++, JScript, VB.NET and C#.

J2EE Service Publishing, Discovery, and Binding

Sun Microsystems is positioning its Java API for XML Registries (JAXR) as a single general purpose API for interoperating with multiple registry types. JAXR allows its clients to access the Web Services provided by a Web Services implementer exposing Web Services built upon an implementation of the JAXR specification

There are three types of JAXR providers:

• The JAXR Pluggable Provider, which implements features of the JAXR specification that are independent of any specific registry type.
• The Registry-specific JAXR Provider, which implements the JAXR specification in a registry-specific manner.
• The JAXR Bridge Provider, which is not specific to any particular registry. It serves as a bridge to a class of registries such as ebXML or UDDI.

.Net Service Publishing, Discovery, and Binding

At first, Microsoft had the discovery of Web Services with DISCO in the form of a discovery (DISCO) file. A published DISCO file is an XML document that contains links to other resources that describe the Web Service. Since the wide spread adoption of UDDI, however, Microsoft has supported it in order to maximize interoperability between solutions in what is, after all, a set of specifications for interoperability.

In addition to providing a .NET UDDI server, the UDDI SDK provides support for Visual Studio .NET and depends on the .NET framework. Products such as Microsoft Office XP offer support for service discovery through UDDI.

J2EE Service Invocation and Execution

J2EE uses the Java API for XML-based RPC (JAX-RPC) to send SOAP method calls to remote parties and receive the results. JAX-RPC enables Java developers to build Web Services incorporating XML based RPC functionality according to the SOAP 1.1 specification.

Once a JAX-RPC service has been defined and implemented, the service is deployed on a server-side JAX-RPC runtime system. The deployment step depends on the type of component that has been used to implement the JAX-RPC service. For example, an EJB based service is deployed in an EJB container.

During the deployment of a JAX-RPC service, the deployment tool configures one or more protocol bindings for this JAX-RPC service. A binding ties an abstract service definition to a specific XML based protocol and transport. An example of a binding is SOAP 1.1 over HTTP.

A Web Service client uses a JAX-RPC service by invoking remote methods on a service port described by a WSDL document.

.Net Service Invocation and Execution

In Microsoft's .NET framework, interested parties can gain access to a Web Service by implementing a Web Service listener. In order to implement this, a system needs to understand SOAP messages, generate SOAP responses, provide a WSDL contract for the Web Service, and advertise the Service via UDDI.

.NET Developers creating SOAP-based Web Service listeners and consumers currently have three choices:

• Use the built in .NET SOAP message classes
• Construct a Web Service listener manually, using MSXML, ASP, or ISAPI, etc.
• Use the Microsoft SOAP Toolkit version 2 to build a Web Service listener that connects to a business facade, implemented using COM.

The Better Choice: J2EE or .Net for Web Services

• One advantage of using J2EE as a base for your system is that you have a much wider choice of vendor for your pre-built software (application servers mostly), including numerous open source projects. In many ways, open source J2EE application servers are closer to the standard laid down by Sun, because they don't add proprietary extensions to overcome problems.
• The key advantage, perhaps, of using the .NET approach to Web Services is that it has been designed for that purpose, whereas J2EE is being retrofitted by the addition of further APIs.

My opinion, if Web Services ect... are new to your organization then .Net should be given a strong looking at, otherwise J2EE has greater flexibility.

Sources