Remoting, Spring, and EJB

For EJB applications, you can best achieve component distribution by using built-in features of the EJB specification. Recently, EJB has come under a lot of industry scrutiny, but the fact remains that EJB does simplify the creation of distributed applications, which makes it a useful tool when you are developing distributed J2EE applications.

For non-EJB, the common choice for building distributed applications is Java's Remote Method Invocation (RMI), which allows Java objects running in one JVM to be accessed from another. RMI is quite complex to work with, and part of the allure of EJB is that it hides the underlying details of RMI from the developer.

For both EJB and non-EJB applications, the most common kind of distribution is to have one Java component talk to another Java component, but in many cases, the components that make up a distributed system are not written in the same language. Using RMI, you can have Java components interoperate with components written in other languages using Common Object Request Broker Architecture (CORBA). More recently, Java has gained support for web services, allowing you to build applications in Java that interoperate with arbitrary services using XML as a means of communication.

The two main problems you face when you go to create distributed applications in Java are complexity and the sheer amount of code you need to create distributed components. EJB goes some way toward solving this by hiding some of the details of RMI and, as of J2EE 1.4, web services from your applications. However, for non-EJB applications, this does not help because EJB is not available. In EJB applications, we are seeing a shift away from heavyweight EJB concepts toward lightweight frameworks such as Spring.

Thankfully, Spring provides a comprehensive set of features, known as Spring remoting, that ease the creation of distributed applications. For non-EJB applications, you can use Spring remoting to radically simplify the creation of remote services and to reduce the amount of code you need to access these services. For EJB applications, Spring remoting provides a viable alternative to EJB for building many distributed applications that, when coupled with other features in Spring, may remove the need for EJB altogether, allowing for much more flexibility in how you choose to deploy your EJB application.

Note 

Although Spring's RMI support provides a viable alternative to EJB in many cases, out of the box, there is no support for standard role-based authentication nor is there support for propagating remote transactions. It is possible to add this support, although this is outside the scope of this chapter. If you require either of these two features, we recommend that you use EJB to create your remote components.

Spring provides support for five distinct types of remoting architecture that cover both homogenous (Java-to-Java) and heterogeneous (Java-to-Other) communication. These architectures are detailed in Table 16-1.

Table 16-1: Remoting Support in Spring

Architecture	Description
JAXRPC	The Java API for XML-based Remote Procedure Calls, JAXRPC, provides a standard Java API for accessing and exposing RPC-style SOAP web services. Spring provides support classes to ease the creation of JAXRPC client applications and servlet-based service endpoints. Like many of the Java XML APIs, JAXRPC comes in many different flavors, the most popular of which is Apache Axis, a fully JAXRPC-compliant SOAP stack that is available from http://ws.apache.org/axis. We use Axis for the JAXRPC examples in this chapter.
HTTP Invoker	The HTTP Invoker architecture is a Spring-native remoting architecture that uses standard Java serialization and HTTP to provide a simple solution for building remote components. The HTTP Invoker relies on a servlet container at the server side to host remote services. A benefit of this is that you can secure your remote services using HTTP authentication methods.
Hessian	Hessian is a binary protocol created by Caucho (www.caucho.com) to simplify the creation of web services. Hessian is not linked to any particular transport, although in general, it is used with HTTP. Spring provides support classes to make it easier to create Hessian services. These classes use HTTP as the transport and also provide proxy support, allowing Hessian services to be accessed transparently.
Burlap	Burlap is an XML-based protocol also created by Caucho. Burlap is a complement to the Hessian protocol. Aside from the details of the protocol, Burlap is used in an identical manner to Hessian. Burlap support in Spring is a mirror of the support offered for Hessian; indeed, the Burlap classes are designed to be drop-in replacements for the Hessian classes, should you need to swap protocols.