Introduction

Routing was introduced in version 2.1 and enables multiple JMS servers to cooperate in a network. Each server (broker) can forward messages to any number of other brokers, which can in turn forward to yet other broker, etc. This allows advanced applications to create messaging systems that are more scalable, have better performance and greater flexibility. This chapter provides a high level introduction to routing in Novell exteNd Messaging Platform JMS.

The concept of routing is well known from the IP and mail messaging stacks. Rather than sending a message directly from the sender to the receiver, a message may go through a number of intermediaries. Routing is really just an extension of the idea of introducing a single message server between producer and consumer applications. Routing introduces the following benefits:

Performance. Sending messages to a broker that in turn forwards the messages to a bulk of consumers or other brokers can result in great performance improvements. As an example, if the consumers are all on the same machine the messages can be sent using one network invocation and a series of local invocations.
Reliability. By having multiple message brokers it is possible to avoid single points of failure. Although parts of the system may no longer receive messages if a message broker fails, this does not necessarily have to affect other consumers.
Flexibility. Grouping of producers and consumers into logical units can simplify system configuration and improve flexibility. For instance, instead of changing all consumers in a group to use a new message broker, only the producers that provide messages to the group must be altered.

To get a feel for the benefits of routing, consider the four basic kinds of network topologies in Figure 1 below. To introduce a bit of terminology, we use the term "down-stream" to mean all nodes reachable from a particular node. As an example, c₁₃ and c₁₄ are down-stream from both c₁₁ and c₁₂ in the fan-out graph. In a similar fashion, "up-stream" is used to denote all the nodes that could be sources of messages for a particular node.

Figure 1: Basic network topologies.

These topologies each offer a specific kind of benefit:

Fan-in. Fan-in is typically used to avoid excessive network traffic and expensive network connections. In Figure 1 the producers c₁₁ and c₁₂ can each create a cheaper connection to c₁₃ rather than each creating an expensive connection to c₁₄. As an example, c₁₁, c₁₂, and c₁₃ could all be one the same machine or local area network while c₁₄ resides on a remote network.
Diamond. A diamond means that messages have two routes to reach their destination. While diamonds introduce the possibility of receiving multiple copies of the same message, their also provide fault-tolerance in case one of the nodes in a diamond path is unavailable.
Cycle. A cycle is usually considered dangerous because messages can circle indefinitely in the network, draining resources and causing multiple deliveries of the same messages. However, sometimes cycles can make sense; in the case where only messages for certain destinations are routed, there is not really a cycle. Also, message expiry can prevent messages from circling indefinitely.
Fan-out. Fan-out is the opposite of fan-in, and these two kinds of topologies are often deployed together in a network. Fan-out can for instance be used to dramatically increase the performance of systems where a message server can fan-out to a group of local consumers.

Another typical configuration where routing is deployed is local/remote broker. In this case, each machine in the network has a local broker (running on the local machine) which can be assumed to always be available. Each local broker communicates with one or more remote brokers, which are responsible for dissemination of messages. If the connection between the local broker and the remote broker is unavailable, this can be completely transparent to the client.

JMS Routing

JMS supports routing by allowing each server to have any number of routing target brokers. The target brokers are specified using host/port as was the case for clustering. Also similar to clustering, message forwarding is different for queues and topics:

Topic messages are by default always forwarded since topics are conceptually everywhere. This means that any consumer down-stream from a router that receives a topic message will be able to also receive that message.
Queue messages are only forwarded if the following two conditions are satisfied. First, the queue must be non-local, i.e. the queue is not bound to the server/router that received the messages. If the queue is local, the message will simply be delivered to a local queue receiver (or a proxy receiver from another broker). Second, if the server is in a cluster, the queue message is not forwarded if any member of the cluster hosts the queue in question. In this case, the message will be delivered to the cluster server, which hosts the message.

There is no automatic synchronization of destinations between message brokers that are networked together. If a destination is created on one broker, which routes messages to a second broker, the destination in question will not automatically be created on the second broker. If a topic message should reach a broker which doesn't hosts the destination for which the message is intended, the message will simply be discarded. However, if a queue message can not be forwarded, it will be stored in a special error queue, if such a queue has been set up administratively.

The above strategy provides the same semantics for queues and topics as in a single server system. Topic subscribers will receive all messages sent to a topic after the subscription was first made. Queue receivers will receive un-consumed messages from a queue in round-robin fashion. The only difference is that consumers can receive messages from a different server than the message was originally sent to.

Local/Remote Broker

The local/remote broker is a very common configuration. This configuration can in particular be used with the HTTP transport to for instance allow a laptop to shift messages across to a remote broker by using the Internet. Figure 2 below shows such a configuration:

Figure 2: Local/Remote broker in Novell exteNd Messaging Platform JMS.

The message producer uses a local broker, which in this case is configured to use a file store ("light" message server). The local broker in turn routes to a remote broker using HTTP(S), i.e. the messages go out on the Internet. On the remote end, the ORB's HTTP Tunnel receives incoming HTTP traffic and forwards it to the remote broker.

Router Administration

Routing is configured using the following properties from the JMQMessageService interface:

msgsvc.router.targets - A comma separated list of URL's for other brokers that this broker should forward messages to. Example:
```
        godel:53506, escher:53506
     
```
msgsvc.router.topics - A comma separated list of topics for which messages will be routed to other brokers. This is typically used to limit the amount of messages that get routed. Example:
```
        topic0, topic1
     
```
msgsvc.error.queue - A queue where local error messages will be stored. If a message broker receives a routed message designed for a queue which is not bound to this broker, and this broker has no other routing destinations or cluster memebers to forward the message to, said message will be stored in this error queue. If no error queue is specified, the message will be silently discarded. If the queue which is named by this property doesn't exist it will be created automatically.

These properties are part of the msgsvc.properties file used by the JMS server program jmqserv.