Version 1.0.0 of the message handler HazelcastMQ includes a new Java STOMP client and server implementation and an Apache Camel component, Mike Pilone recently reported.
HazelcastMQ provides a messaging layer on top of the basic Queue and Topic data structures in Hazelcast, an in-memory data grid, and can be embedded in a single JVM or clustered across a number of nodes. According to Mike these new additions simplifies setup of a clustered, scalable messaging architecture without a centralized broker.
HazelcastMQ is divided into components, including:
- A core message queue (MQ) library providing a JMS 2.0-like API for sending and receiving messages.
- An Apache Camel component implementation supporting Camel's integration framework and Enterprise Integration Patterns, with no dependency on the Spring Framework. Support includes configurable consumers and producers including request/reply messaging and concurrent consumers.
- A JMS 1.1 implementation layered on top of the core.
- A STOMP server mapping all commands to the producers and consumers in the core. A Stomplet implementation enables use of non-Java clients to send and receive messages. Using the underlying clustering, a local STOMP server can be running on each node letting Hazelcast handle all network communication.
- Yeti, A STOMP server and client framework built on Netty to ease building STOMP implementations for existing brokers. Yeti aims to provide fast and reusable STOMP frame codecs and channel handlers while abstracting away the underlying network IO.
Code examples are included in each module and in a separate examples module.
Hazelcast was introduced on InfoQ earlier this year.
STOMP is the Simple (or Streaming) Text Orientated Messaging Protocol, providing an interoperable wire format so that STOMP clients can communicate with any STOMP message broker enabling messaging interoperability over multiple languages and platforms.