he Burlap/Hessian protocol is an alternative remote object invocation and Web services protocol supplied as an open source Java framework through Caucho Technology. If you want POJO (Plain Old Java Objects)-based object distribution, efficient serialization, distributed Java objects that hardly need a Web container, maximal ease of use, and a minimal learning curve, then you should give Burlap/Hessian a serious look. Although primarily a Java remote object invocation protocol, it offers stable implementations for C++, C#, Python, and PHP as well.
I first ran across Burlap/Hessian while working with the Spring framework. Its exceptional simplicity and efficiency inspired me to write this article. I begin with an explanation of how the protocol works, follow that with a demonstration for establishing a Hessian-based distributed architecture, and close with some practical suggestions for how to use the protocol.
Burlap/Hessian Architecture
Burlap and Hessian are peer specifications of the same conceptual protocol. The major difference between the two is the implementation of the serialization mechanism. Burlap serializes objects over the Web using XML; Hessian serializes objects using a proprietary (very compact) binary format. According to its authors, the protocol’s dull “textile” names reflect its boring simplicity?which I find to be anything but boring.
Burlap/Hessian remote objects are just ordinary Java objects that implement some interfaces. They don’t require special proxy, home, or remote classes. One of the inherent benefits of this object-and-interface model is that it promotes the good object-oriented design practice of design by interface. Design by interface mandates that client objects depend on abstractions and never on concrete classes.
Furthermore, the Burlap/Hessian protocol fully leverages the host environment’s Web container capabilities. Hessian server is nothing more than a servlet that can dispatch Burlap or Hessian serialized objects via the Web. Hessian remote objects are configured in a web.xml file (as examples will demonstrate shortly).
As previously mentioned, Burlap/Hessian serializes Java objects using a proprietary serialization mechanism. The serialization process is completely transparent to the application (i.e., you do not need to implement any special interfaces to make objects serializable). Burlap/Hessian serialization is very efficient, and the produced serialized object snapshots (either XML or binary) are very compact.
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 elseIt 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.
Suggested Practical Uses for Burlap/Hessian
The following are practical implementations for Burlap/Hessian that can benefit your development today:
If you develop enterprise applications using the Spring framework, Burlap and Hessian are already available to you through the framework in a completely transparent fashion. Spring does not require your application to use a particular remoting protocol, since the framework transparently injects the remote dependencies. In this scenario, I recommend using the Burlap/Hessian protocol to take full advantage of Hessian’s performance, simple Web application deployment model, and ease of use. With Spring, switching from the Burlap or the Hessian protocol to a more conservative JSR-endorsed protocol such as RMI is a matter of changing configuration.
Some developers may take issue with using a Java distributed computing framework that is not endorsed by the official Java specification. However, if you have to perform distributed computing between just a few applications, Hessian may be the practical way to go. You would save a significant amount of money that you would otherwise spend on EJB training, development, administration, and maintenance. Moreover, Hessian’s lightweight architecture and mild?almost non-existent?coupling with the application code will keep your applications from becoming strategically dependent on this proprietary framework.
The authors of the Burlap/Hessian protocol have proposed using it for small devices such as cell phones. This is a rather interesting proposal, and I think it warrants serious consideration. Its small deployment footprint (it can be deployed with only a few core classes), efficient serialization algorithm, and simple infrastructural requirement make Burlap/Hessian a good candidate for a remote protocol implementation in small devices.
