WebORB includes integration with the ZeroMQ messaging library. A messaging destination can be configured to relay messages to a ZeroMQ socket. WebORB supports two types of the ZeroMQ sockets: ZMQ_PUB and ZMQ_PUSH.The former enables multiple WebORB publishers and multiple WebORB consumers. The latter supports multiple publishers, but only one subscriber.
Below is a sample destination included with WebORB when the ZeroMQ integration is selected in the product installer:
<!-- url to bind server at. This is the 0mq socket weborb will publish messages to -->
<!-- url for subscribers, this is the endpoint from where the messages will be read -->
<!-- can be 'topic' or 'queue' values -->
<!-- for RTMP change channel ref to "weborb-rtmp-messaging" -->
The configuration includes two endpoints: <publish-uri> and <subscribe-uri>. If the endpoint value is the same, messages sent/received by WebORB publishers and subscribers go through the same ZeroMQ socket. Otherwise, a destination can be configured so that subscribers receive messages from an alternative socket. The diagrams below illustrate both configurations:
Same Publish and Subscribe URIs
When the publish and subscribe URIs are the same, the ZeroMQ socket is allocated by WebORB. The server is bound to the URI and any messages published by the WebORB producers are sent to the socket. Notice this scenario does not allow any native external ZeroMQ publishers.
Different Publish and Subscribe URIs
When the URIs are different, all WebORB subscribers can get messages from two different sources: one is the internal publishing endpoint which supports all WebORB publishers and the other is an external endpoint which supports native ZeroMQ publishers. This scenario is useful when integration with a third party system is needed. Messages received from an external ZeroMQ socket are processed and delivered as byte arrays. This behavior can be modified with a custom message factory.
Message Factory and Serializer
A message factory is responsible for:
|1.||Converting published messages into instances of the org.zeromq.ZMsg class (the publishing use-case).|
|2.||Converting received messages from org.zeromq.ZMsg into objects delivered to WebORB subscribers (the subscription use-case).|
A message factory must implement the following interface:
public interface IMessageFactory
public ZMsg createMessage( ISerializer serializer, Hashtable properties, Object messageBody ) throws Exception;
public Object parseMessage( ISerializer serializer, ZMsg message ) throws Exception;
A message factory implementation relies on a serializer to handle object to byte conversion and vice versa. A serializer implementation must implement the following interface:
public interface ISerializer
public String getContentType();
public byte toBytes( Object o ) throws Exception;
public Object fromBytes( byte bytes ) throws Exception;
The getContentType() method must return a string which is a symbolic representation of the serialization format. For instance, the default serializer provided by WebORB uses the AMF3 format for object to byte serialization and the getContentType method() returns the "application/x-amf" content type.
A message factory and serializer are assigned to a destination using the <message-factory> and <serializer> elements:
Message factory is responsible for processing both messages published by WebORB publishers (these messages are created using the createMessage method of the IMessageFactory interface) and messages published by non-WebORB publishers. The default implementation of the message factory serializes messages published by a non-WebORB client as byte arrays. Messages published by WebORB clients have the following structure: