Differences

A web service, that connects to an EJB, requires a Java wrapper class; the VS.Net framework can expose a server object, natively.
NET XML doesn’t support many of the communication features in .NET Remoting, the binary communication protocol; J2EE doesn’t currently support XML.

J2EE

Application servers multiplex web client connections to a shared database.  Application servers are coded in Java.  J2EE hosts EJB’s within an application server container, which can’t host web services.  J2EE application server containers require J2EE 1.4 to communicate via the HTTP protocol; previously, J2EE required a protocol bridge or gateway class to hear web service HTTP calling an EJB, which listens for RMI/IIOP communication protocol.

To implement web services, a Java class receives an HTTP/SOAP message, parses the XML and maps to another class or bean to implement the service.  The web service implementation goes into either a session Bean or an entity Bean, accessed via either RMI or RMI/IIOP, rather than HTTP.  Expect J2EE 1.4 to standardize web services support.

NET

Net uses two communication protocols (HTTP and TCP a.k.a. .NET Remoting) to exchange SOAP messages.  TCP/.NET Remoting is more efficient and powerful.  HTTP is used for “external” communication e.g. to J2EE.
ASP.NET is recommended for creating web services.  ADO.NET is recommended for accessing data resources.

Bridging J2EE with .NET

In theory, one could bridge J2EE with .NET, using WSDL for service descriptions and SOAP/HTTP for communication.  However, integrated security, transactions and reliable messaging aren’t available.  Neither do web services standards yet address this.

Back Home