Resin Documentation

hessian messaging

The Hessian binary web service protocol can provide a messaging service layered on top of its RPC call. The messaging service itself is based on the standard Hessian RPC call, so Hessian itself has no need to become more complicated.

Each hop the message takes uses a simple send method to the next server in line. The receiving service might be the final destination or it might choose to send the message to another server, making another hop. This architecture is essentially the same as the standard SMTP mail architecture. SMTP is custom protocol for each hop while RFC-822 specifies the meaning of the mail headers.

We'll just be discussing the hop protocol, i.e. the SMTP replacement. Any definition of the end-to-end headers and routing would be built on top of the basic Hessian messaging.

This discussion shows that Hessian's RPC mechanism is sufficient for handling messaging, without introducing any extra complications to the Hessian protocol itself. By choosing a layered protocol model, each protocol layer can be simple independent of the others.

The message service sends a message from the client to the server. When you strip away all other complications, that's all messaging does.

The message service method is simple. It consists of a single method send with two arguments: headers and message. headers contain message routing information. message contains the message itself.

package com.caucho.services.message;

public interface MessageSender {
  public void send(java.util.HashMap headers, Object message)
    throws MessageServiceException;
}

The simplest messaging service receives text message to a URL. With that messaging service, only the message object is used and the headers are ignored. Many applications only need the most basic messaging protocol. Until the application needs messages to be forwarded and to have many middle servers, the simple use case is sufficient.

The message service URL is the message destination. This example might use http://foo.com/hessian/message/test-bean. Since this sample service ignores the headers, there's no forwarding of the message.

c x01 x00                -- hessian call
  m x00 x04 send         -- the send method
  N                      -- null headers
  S x00 x0c Hello, world -- string message
z                        -- end of request

The Hessian packet does not need to contain the URL, since that's specified in the containing enveloper. For example, when using Hessian with HTTP, the HTTP request will specify the URL of the Hessian service.

String url = "http://foo.com/hessian/message/test-bean";

HessianProxyFactory factory = new HessianProxyFactory();
MessageSender sender;
sender = (MessageSender) factory.create(MessageSender.class, url);

sender.send(null, "Hello");

import hessianlib;

proxy = Hessian("http://foo.com/hessian/message/test-bean")
proxy.send(None, "hello")

package test.hello;

import javax.ejb.*;
import javax.jms.*;

public class MyMessageBean implements MessageDrivenBean, MessageListener {
  public void setMessageDrivenContext(MessageDrivenContext cxt)
  {
  }

  public void ejbCreate()
  {
  }

  public void onMessage(Message msg)
  {
    try {
      TextMessage textMessage = (TextMessage) msg;

      String text = textMessage.getText();

      System.out.println("MESSAGE: " + text);
    } catch (JMSException e) {
    }
  }

  public void ejbRemove()
  {
  }
}

<-- configure the EJB server -->
<resource-ref>
  <res-ref-name>java:comp/env/cmp</res-ref-name>
  <class-name>com.caucho.ejb.EJBService</class-name>
</resource-ref>

<-- configure the Hessian protocol -->
<servlet-mapping>
  <url-pattern>/hessian/*</url-pattern>
  <servlet-name>com.caucho.ejb.hessian.HessianServlet</servlet-name>
</servlet-mappin>

Routing parameters are contained in the headers map. For example, Java's messaging service (JMS) defines a number of routing headers. These headers could be used for more sophisticated mail routing than point to point.

Defining the routing headers is beyond the aim of this page. The important point to note is that the routing protocol is built on top of the Hessian messaging service which is built on Hessian. Hessian itself does not need to be complicated with the routing headers.

In some sense, this protocol is too simple. That's the point. By designing the messaging protocol as a layered system, each layer can be simple. So a simple messaging service will be easy, and complicated messaging routing services are still possible.

• Hessian can remain a simple RPC protocol with no complicated routing headers.
• The messaging service API can remain trivial so simple scripting language clients can use it.
• Sophisticated routing protocols can be built on top of the messaging by properly defining the headers.