java hessian rmi_Efficient Java RMI Hessian

Application Development in a Hessian-Based Distributed Architecture

This section demonstrates the typical steps involved in establishing a Hessian-based distributed architecture. The sample scenario involves two applications: one for inventory management and the other for order management. The inventory management app is a standalone J2EE application that enables its users to track and manage their parts inventory over the Web. This example takes a plain Java object (InventoryTracker) and exposes it to the ordering management application that needs inventory lookup services.

Step 1. Enable server components for the remote invocation

The first step in making inventory-tracking objects available remotely via Hessian is to make sure that objects of interest implement some plain Java interfaces. If the object you plan to expose remotely does not implement any interfaces, you need to extract the appropriate business interface from it, and implement that interface. This step is actually the only requirement that Hessian imposes on your server-side objects.

[Hint: If you want to expose the server objects but you cannot make any changes to them, you can apply the Adapter design pattern. Expose the Adapter object that implements the needed interface and then have it delegate the remote method invocations to the actual business component.]

As previously stated, this example exposes the plain Java object InventoryTracker. This object tracks the item inventory, and the order management application can use it to verify if the items are available. The following code makes InventoryTracker implement the ItemAvailabilityTracker interface:

public class PartsTracker implements ItemAvailabilityTracker{

/**

* Default constructor

*

*/

public PartsTracker() {

}//end constructor

/** Purely fabricated business method that verifies if the refurbished part is

* available on the inventory.

* @param partID

* @return boolan - true if the part ID is not empty, null or longer than 5 digits

* (invented part numbering standard)

*/

public boolean isPartAvailable( String partID ) {

The following is the ItemAvailabilityInterface:

public interface ItemAvailabilityTracker {

/** Method verifies if the part is available on the inventory

*

* @param partID

* @return true if available

*/

public boolean isPartAvailable( String partID );

Step 2. Configure the server component for the remote invocation (over the Web)

In order to make the ItemAvailabilityTracker service available over the Web, the server object and the interface it implements have to be registered with the Hessian Servlet (org.caucho.Hessian.HessianServlet) in the web.xml file of the existing inventory management Web application.

Using the standard Servlet parameter settings in the web.xml file, specify the service implementation object (parameter: home-class) and the interface (parameter: home-api) of the service that is going to be accessible by the Java clients:

Sample application for Hessian

Sample host application for Hessian remoting

invoker

com.caucho.hessian.server.HessianServlet

home-class

com.acme.inventory.PartsTracker

home-api

com.acme.inventory.ItemAvailabilityTracker

/invoker

invoker

The Burlap/Hessian protocol fully leverages the Web container capabilities of the host environment.

As you can see, the Hessian server is nothing more than a servlet that can dispatch either Burlap or Hessian serialized objects via the Web. As the service provider, you can choose whether to have a special-purpose Web application for the remote services or to have an already functional Web application expose the remote objects.

Step 3. Invocation on the client

In order to invoke the objects remotely, the client application needs to have a Burlap or Hessian jar in the classpath, as well as in the interface for the service being invoked. In this case, the application needs the interface com.acme.inventory.ItemAvailabilityTracker. The following code demonstrates the typical steps required to obtain the object remotely and to invoke its services:

String url = "http://localhost:8080/inventory/invoker";

HessianProxyFactory factory = new HessianProxyFactory();

ItemAvailabilityTracker tracker = (ItemAvailabilityTracker)

factory.create(ItemAvailabilityTracker.class, url);

if ( tracker.isPartAvailable( itemID ) ) {

System.out.println( "Item " + itemID + " ordered." );

}else {

System.out.println( "Item " + itemID + " not available for ordering." );

}//end else

It is actually a very simple interaction. The client code needs to know the URL of the Hessian servlet. It will use this URL along with the interface class to obtain the interface implementation from the HessianProxyFactory.

As you probably noticed, the only actual coupling point between the clients' application code and the Burlap- or Hessian-specific classes is through the HessianProxyFactory. Compared with EJB or even RMI, Hessian's client dependency on the API is quite minimal, and if you use an Inversion of Control (IoC) container such as Spring, your client code will effectively have no dependencies on the framework.

The most attractive aspect of the Burlap or Hessian client-to-server interaction is that it is accomplished in a true Web services fashion. The client effectively locates the remote object (as a URL) over HTTP (or HTTPS), and from that point it interacts with the object in a true POJO fashion.