As I mentioned in a previous post, to completely move off of ActiveMQ as my message broker, I would need a messaging solution for some of the C and C++ components in my system. Currently these components use the STOMP interface exposed by the ActiveMQ broker. After getting the initial version of HazelcastMQ pushed to GitHub, I started working on a STOMP server implementation. Today I'm happy to announce that the first cut at the server is now also available in GitHub as HazelcastMQ Stomper.
Stomper is implemented as a layer on HazelcastMQ so it uses all the standard JMS components for message sending and receiving. Using the JMS components allows a STOMP client to easily interact with JMS clients creating a language agnostic messaging solution on Hazelcast. While Stomper was written and tested with HazelcastMQ JMS components, it should work with any JMS provider if you wanted to use it as a generic STOMP server implementation. You can also use Stomper's STOMP server without dealing with any of the JMS APIs other than creating the initial connection factory.
With Stomper and HazelcastMQ you can now send a message to a queue or topic via the STOMP API and receive it via the JMS API (all on a distributed cluster of Hazelcast nodes). The same works in the opposite direction. This is extremely useful in a mixed language environment where Python, Ruby, C, or C++ components need to interact with Java components without having to implement a custom message passing solution.
Check out the examples in the hazelcastmq-examples module and give it a try. The next step is to write a simple STOMP client (to be named HazelcastMQ Stompee) which will allow me to write some simple producer/consumer examples using just the STOMP API (i.e. no direct JMS interaction).
No comments:
Post a Comment