Queues

Applications can also communicate with each other using queues of messages. One application sends messages to the queue and another receives the messages from the queue. There could be any number of message producers and consumers on a given queue and there could be any number of queues in the system.

Messages are kept in the queue in the order in which they were sent until a consumer requests a message. Each message will be delivered to one and only one consumer. This delivery algorithm is the main difference between queues and topics.

Figure 6 shows the notion of a queue.

Figure 6. The notion of a queue

Consumers can register themselves as queue listeners. By doing so, they eliminate the need to request a message every time. In the queue listener mode, a message that is received by the queue will be delivered immediately to one of its listeners.

In a broker-based architecture, all queues are managed by the centralized broker in a manner very similar to topics.

Queues are centralized by their nature, because of the order requirement and the "once and only once" delivery constraint. In MantaRay, we kept the queue as a centralized logical entity and still removed the need for a broker. We have introduced a third role (beyond consumer and producer) called a queue coordinator, which can reside on any MantaRay element in the network. Different MantaRay elements can coordinate different queues. The only rule that has to be kept is that there is only one queue coordinator per queue.

Figure 7 shows how queues work in a distributed environment.

Figure 7. Queues in a distributed environment

The coordinator for each queue is a configurable attribute of MantaRay. Once a MantaRay element is configured to be the coordinator of a queue, it will automatically manage that queue. The queue coordinator can even be a dedicated standalone MantaRay process, which does not act as a consumer or producer at all.

If planned correctly, this queue architecture can be much faster than a queue on a broker. Let's say we have only one consumer of messages from the queue; this means we can configure the queue coordinator on the same MantaRay instance. This gives us a very fast queue--one that does not require network traffic.
On the other hand, if you have only one producer and multiple consumers, you can configure the queue coordinator to be on the same process as the producer and queuing a message into the queue will not require network traffic.

Inter-Process Messaging

Messaging can also be useful for inter-process communication; different logical components and different tiers in an application can communicate with each other using JMS. This abstraction helps you decouple the tiers and more easily separate them into different applications when that time comes.

MantaRay enables inter-process communication with no network traffic. If MantaRay "knows" that the destination of a message is in the same JVM, it skips all of the network stuff (serialization, network send and receive, and deserialization), making the communication much faster.

Using Standards

While writing a proprietary code can be fun, using standards is very important. Standards have been proven and accepted by the community and usually cover all bases. MantaRay tries to use standards as much as possible:

Commons-logging lets MantaRay logs plug into the logs of the application that uses MantaRay.

MantaRay keeps the persistent world view (of all of the other MantaRays in the system) in a well-formed, easy-to-read XML file.

Conclusion

When considering a messaging solution, there are many things to take into account: stability, robustness, high availability, and speed. Up until now, you could only solve these problems by buying a stronger computer and a stronger network infrastructure. This meant you'd need your brokers to be backed up,
clustered, and load-balanced.
While these options are still valid, MantaRay provides a different point of view on the messaging world; one that is less costly, and one that is easy to deploy and manage.

Issues of scaling and cost should be considered, as well. Until recently, scaling up was very costly and sometimes a big pain. Now you have the option to start small and easily scale up.

Because it is a lightweight solution and easy to deploy, and because of its distributed nature, MantaRay can be an ideal solution for your Java messaging needs.