The release of HazelcastMQ v1.0.0 includes a new Java STOMP client and server implementation as well as a HazelcastMQ Apache Camel component. With these additions, it is now easier than ever to setup a clustered, scalable messaging architecture with no centralized broker.
Yeti is a STOMP server and client framework built on Netty to make it simple to build STOMP implementations for existing brokers. Yeti borrows the best ideas from Stampy and
Stilts to provide fast, reusable STOMP frame codecs and channel handlers while abstracting away the underlying network IO with a Stomplet API similar to the familiar Servlet API. To build a custom server, simply implement a Stomplet or extend one of the existing Stomplets to provide custom handling for STOMP frames.
HazelcastMQ Stomp implements a Stomplet to link the STOMP send, subscribe, and message commands to HazelcastMQ. This means you can now have non-Java clients send and receive messages via a STOMP API. With Hazelcast's underlying clustering, you could run a local STOMP server on each node and let Hazelcast handle all the network communication.
HazelcastMQ Camel is an Apache Camel component implementation for HazelcastMQ supporting Camel's integration framework and Enterprise Integration Patterns (EIP). The component supports configurable consumers and producers including request/reply messaging and concurrent consumers. Unlike Camel's existing JMS component, HazelcastMQ Camel has no dependency on the Spring
Framework by building directly on HazelcastMQ Core.
If your application is already using Camel, switching to HazelcastMQ simply requires changing the endpoint URIs. For example, hazelcastmq:queue:blog.posted creates an endpoint that can consumer from or produce to the blog.posted queue in HazelcastMQ.
Combining HazelcastMQ Stomp and Camel means a Java application using Camel gateway proxies could use a simple Java interface to exchange messages with a C application using STOMP while getting all the benefits of a reliable and clustered data grid.