Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 months ago.
The community reviewed whether to reopen this question 8 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
We are defining an architecture to collect log information by Logstash shippers which are installed in various machines and index the data in one elasticsearch server centrally and use Kibana as the graphical layer. We need a reliable messaging system in between Logstash shippers and elasticsearch to grantee the delivery. What factors should be considered when selecting Redis over RabbitMQ as a data broker/messaging system in between Logstash shippers and the elasticsearch or vice versa?
After evaluating both Redis and RabbitMQ I chose RabbitMQ as our broker for the following reasons:
RabbitMQ allows you to use a built in layer of security by using SSL certificates to encrypt the data that you are sending to the broker and it means that no one will sniff your data and have access to your vital organizational data.
RabbitMQ is a very stable product that can handle large amounts of events per seconds and many connections without being the bottle neck.
In our organization we already used RabbitMQ and had good internal knowledge about using it and an already prepared integration with chef.
Regarding scaling, RabbitMQ has a built in cluster implementation that you can use in addition to a load balancer in order to implement a redundant broker environment.
Is my RabbitMQ cluster Active Active or Active Passive?
Now to the weaker point of using RabbitMQ:
most Logstash shippers do not support RabbitMQ but on the other hand, the best one, named Beaver, has an implementation that will send data to RabbitMQ without a problem.
The implementation that Beaver has with RabbitMQ in its current version is a little slow on performance (for my purposes) and was not able to handle the rate of 3000 events/sec from one server and from time to time the service crashed.
Right now I am working on a fix that will solve the performance problem for RabbitMQ and make the Beaver shipper more stable. The first solution is to add more processes that can run simultaneously and will give the shipper more power. The second solution is to change Beaver to send data to RabbitMQ asynchronously which theoretically should be much faster. I hope that I’ll finish implementing both solutions by the end of this week.
You can follow the issue here:
https://github.com/josegonzalez/python-beaver/issues/323
And check the pull request here:
https://github.com/josegonzalez/python-beaver/pull/324
If you have more questions feel free to leave a comment.
Redis is created as a key value data store despite having some basic message broker capabilities.
RabbitMQ is created as a message broker. It has lots of message broker capabilities naturally.
I have been doing some research on this topic. If performance is important and persistence is not, RabbitMQ is a perfect choice. Redis is a technology developed with a different intent.
Following is a list of pros for using RabbitMQ over Redis:
RabbitMQ uses Advanced Message Queuing Protocol (AMQP) which can be configured to use SSL, additional layer of security.
RabbitMQ takes approximately 75% of the time Redis takes in accepting messages.
RabbitMQ supports priorities for messages, which can be used by workers to consume high priority messages first.
There is no chance of loosing the message if any worker crashes after consuming the message, which is not the case with Redis.
RabbitMQ has a good routing system to direct messages to different queues.
A few cons for using RabbitMQ:
RabbitMQ might be a little hard to maintain, hard to debug crashes.
node-name or node-ip fluctuations can cause data loss, but if managed well, durable messages can solve the problem.
I have been wondering the same thing. Earlier recommendations by the Logstash folks recommend Redis over RabbitMQ (http://logstash.net/docs/1.1.1/tutorials/getting-started-centralized), however that section of the notes no longer exists in the current documentation although there are generic notes on using a broker to deal with spikes here https://www.elastic.co/guide/en/logstash/current/deploying-and-scaling.html.
While I am also using RabbitMQ quite happily, I'm currently exploring a Redis broker, since the AMQP protocol is likely overkill for my logging use case.
If you specifically want to send logs from Logstash to Elasticsearch, you might want to use Filebeat instead of either Redis or RabbitMQ. Personally, I use fluent-bit to collect logs to send to Elasticsearch.
However, the other answers on this page have a lot of out-of-date information regarding Redis's capabilities. Redis has supported:
publish/subscribe since version 2.0
clustering since version 3.0.
streams since version 5.0.
SSL/TLS since version 6.0.
a copy-on-write append-only log for persistence to disk. It works best with Redis 7.0 or newer. This log is useful for recovering from a crash.
But there are some limitations:
Redis is still not as focused as RabbitMQ when it comes to message durability and crash recovery.
Redis pub/sub is not as scalable as RabbitMQ. Redis pub/sub messages were not sharded by Redis cluster nodes (until relatively recently). Redis Streams are a newer, more scalable API.
Quick questions to ask:
why do you need a broker? If you're using logstash or logstash-forwarder to read files from these servers, they both will slow down if the pipeline gets congested.
do you have any experience with administering rabbit or redis? All things being equal, the tool you know how to use is the better tool.
In the realm of opinions, I've run redis as a broker, and hated it. Of course, that could have been my inexperience with redis (not a problem with the product itself), but it was the weakest link in the pipeline and always failed when we needed it most.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I wanted a feedback on whether my evaluations and concerns are correct.
I have been reseaching the three, Data Distribution Service, AMQP and ZeroMQ for sometime now for building a data transport layer in a datacenter. All the three look promising, yet i encountered some blocking issues in few.
To give a context, my requirements are:
Scale upto 500+ physical nodes, 1000+ publishers and subscribers.
Support durable delivery of messages to take care of failing subscribers.
The aggregated throughput should be north of 1 Million messages / sec
Problems with AMQP:
The Broker architecture seems to be a bottleneck and central point of failure in the whole deployment setup. I can complicate my deployment by putting a federation and cluster to improve performance and availability of pending messages, but they still do not seem to be failproof.
The performance for durable queues seems to be very less. My sample application could only clock 6-7K messages / core / queue/ application.
Problems with ZeroMQ:
The Documentation seems to be a little wanting in depth.
The behavior of the system for pending messages seems to invite trouble in PUB/SUB model of communication. Please refer to : How zeromq handles slow consumers with PUB/SUB mode
OpenSplice DDS:
I didnt find anything lacking in the DDS protocol except for adoption in the industry. Will like to know a first hand review on this product in terms of stability, performance or limitations.
I am surprised about your concerns on OpenSplice DDS adoption. OpenSplice DDS is today deployed on over several mission and business critical systems such as Naval Combat Management Systems, Military Vehicles, Air Traffic Control and Management, Metro, to High Frequency Auto-Trading. Just to give you another bit of info that should give you reassure you w.r.t. the adoption of the technology, the OMG DDS standard (the standard implemented by OpenSplice DDS) has been recommended by EUROCAE to exchange flight data plans across centers pan-european.
Let me know if you have any further questions either on the adoption or the technology.
-AC
Take a look at this page. Lot of industries and companies are using DDS today.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
We are facing a choice to use IBM MQ over SFTP for file transfer. I've heard advantages of such approach, but I've never see anyone actually using it for a large files.
So main question: how well IMB MQ can handle transfer of large files (up to 100 MB)? Is it stable? It's from mainframe to UNIX server, if it does matter.
Thanks a lot.
I've used MQ with files up to 8GB in size, without incident. You have to allocate enough space for MQ to manage them, but it works.
MQ itself offers message-based communication between programs. You can't use it directly to transfer files. People talking about "sending files via MQ" often mean that they will write the programs themselves to read from a file, send over MQ, receive from MQ and write to another file. This sounds temptingly trivial at first but quickly becomes very complex if you want it to be robust. Not recommended.
What you should be doing if you want to involve MQ in your file transfers is use one of the file-transfer products that sit upon MQ. There are a number of mature offerings, about which I know next to nothing, together with a new product from IBM itself ("Websphere MQ File Transfer Edition") which is being actively developed and recently announced an updated version (7.0.1).
To answer your specific question, I've personally used WMQFTE to transfer a file of 1000GB from an AIX machine to a Windows one, so I don't think your "large" 100MB files will be a problem :-). I don't get involved with the mainframe as much but it is very much a core platform for FTE.
Vendors have been doing File transfer over a messaging system such as WebSphere MQ for over 12 years. I have not used the IBM product. Yet, I know until recently IBM resold Metastorm’s product (under the brand PM4Data) and only recently entered the market with a first generation product.
I’ve seen Metastorm Integration Manager handle files of terabyte sizes all of the time; breaking up the messages across WebSphere MQ and performing buffers acknowledgements so not to overflow message queues or having to do a lot of MQ Administration.
Other worthwhile considerations of using messaging systems for file transfer vs. SFTP include:
Pre-and Post-Data Movement Handling - As a network transport, SFTP moves data (as can file transfer products over WebSphere MQ). To do pre- or post-movement processing, you’d have to write your own monitoring, triggering, error handling, etc. Mature vendors in the file transfer over messaging space provide infrastructure out-of-the-box for you. Depending on your application, they can also help
Audit Trail - SFTP provides often provide system-level logging. Often time, vendors providing file integration over MQ have greater audit capabilities, including the Pre- and Post-Data Movement Handling. Some vendors also offer secure web-based systems to expose certain integrations to authorized users.
Exception Handling – SFTP will give synchronous error messages from which you then code your error logic. Vendors providing file integration over MQ often provide exception capabilities ranging from "here’s a message on queue signifying a problem happened... good luck" to built-in integration to Web-based consoles or even BPM system.
Treating File Transfer as a Service – Often times, File Transfer is part of a larger business process. Some vendors leverage this to chain file transfers and even have them collaborate with human-centric processes to provide end-to-end visibility around the context of a point-to-point file transfer. Additionally, using messaging systems for file transfer helps move an organization to a more real-time, message-driven approach.
I hope the additional details give some details in your assessment. Good luck!
In one of the previous answers, there is the followng statement:
People talking about "sending files via MQ" often mean that they will write the programs themselves to read from a file, send over MQ, receive from MQ and write to another file. This sounds temptingly trivial at first but quickly becomes very complex if you want it to be robust. Not recommended.
In theory it would be nice to "sending files via MQ" because you would receive a Confirmation on Delivery (CoD) message when the recipient got (read) the file from the queue. Another benefit would be that the file would be automatically removed from the queue when the recipient got (read) it from the queue.
Do you perhaps know whether the above (or a similar) is offered by MQFTE?
Capitalwares Universal File Mover is an option here.
Also WebSphere Message Broker for Remote Adapter Deployment and WebSphere MQ File Transfer Edition are options to consider.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
We'd be interested to hear any experiences with the pros and cons of ActiveMQ vs RabbitMQ vs ZeroMQ. Information about any other interesting message queues is also welcome.
Edit: My initial answer had a strong focus on AMQP. I decided to rewrite it to offer a wider view on the topic.
These 3 messaging technologies have different approaches on building distributed systems :
RabbitMQ is one of the leading implementation of the AMQP protocol (along with Apache Qpid). Therefore, it implements a broker architecture, meaning that messages are queued on a central node before being sent to clients. This approach makes RabbitMQ very easy to use and deploy, because advanced scenarios like routing, load balancing or persistent message queuing are supported in just a few lines of code. However, it also makes it less scalable and “slower” because the central node adds latency and message envelopes are quite big.
ZeroMq is a very lightweight messaging system specially designed for high throughput/low latency scenarios like the one you can find in the financial world. Zmq supports many advanced messaging scenarios but contrary to RabbitMQ, you’ll have to implement most of them yourself by combining various pieces of the framework (e.g : sockets and devices). Zmq is very flexible but you’ll have to study the 80 pages or so of the guide (which I recommend reading for anybody writing distributed system, even if you don’t use Zmq) before being able to do anything more complicated than sending messages between 2 peers.
ActiveMQ is in the middle ground. Like Zmq, it can be deployed with both broker and P2P topologies. Like RabbitMQ, it’s easier to implement advanced scenarios but usually at the cost of raw performance. It’s the Swiss army knife of messaging :-).
Finally, all 3 products:
have client apis for the most common languages (C++, Java, .Net, Python, Php, Ruby, …)
have strong documentation
are actively supported
Why did you miss Sparrow, Starling, Kestrel, Amazon SQS, Beanstalkd, Kafka, IronMQ ?
Message Queue Servers
Message queue servers are available in various languages, Erlang (RabbitMQ), C (beanstalkd), Ruby (Starling or Sparrow), Scala (Kestrel, Kafka) or Java (ActiveMQ). A short overview can be found here
Sparrow
written by Alex MacCaw
Sparrow is a lightweight queue written in Ruby that “speaks memcache”
Starling
written by Blaine Cook at Twitter
Starling is a Message Queue Server based on MemCached
written in Ruby
stores jobs in memory (message queue)
documentation: some good tutorials, for example the railscast about starling and workling or this blog post about starling
Kestrel
written by Robey Pointer
Starling clone written in Scala (a port of Starling from Ruby to Scala)
Queues are stored in memory, but logged on disk
RabbitMQ
RabbitMQ is a Message Queue Server in Erlang
stores jobs in memory (message queue)
Apache ActiveMQ
ActiveMQ is an open source message broker in Java
Beanstalkd
written by Philotic, Inc. to improve the response time of a Facebook application
in-memory workqueue service mostly written in C
Docu: http://nubyonrails.com/articles/about-this-blog-beanstalk-messaging-queue
Amazon SQS
Amazon Simple Queue Service
Kafka
Written at LinkedIn in Scala
Used by LinkedIn to offload processing of all page and other views
Defaults to using persistence, uses OS disk cache for hot data (has higher throughput then any of the above having persistence enabled)
Supports both on-line as off-line processing
ZMQ
The socket library that acts as a concurrency framework
Faster than TCP, for clustered products and supercomputing
Carries messages across inproc, IPC, TCP, and multicast
Connect N-to-N via fanout, pubsub, pipeline, request-reply
Asynch I/O for scalable multicore message-passing apps
EagleMQ
EagleMQ is an open source, high-performance and lightweight queue manager.
Written in C
Stores all data in memory and support persistence.
It has its own protocol. Supports work with queues, routes and channels.
IronMQ
IronMQ
Written in Go
Fully managed queue service
Available both as cloud version and on-premise
I hope that this will be helpful for us.
source
More information than you would want to know:
http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes
UPDATE
Just elaborating what Paul added in comment. The page mentioned above is dead after 2010, so read with a pinch of salt. Lot of stuff has been been changed in 3 years.
It really depends on your use-case.
Comparing 0MQ with ActiveMQ or RabbitMQ is not fair.
ActiveMQ and RabbitMQ are Messaging Systems wich require installation and administration.
They offer featurewise a lot more than ZeroMQ. They have real persistent Queues, Support for transactions etc.
ZeroMQ is a lightweight message orientated socket implementation. It is also suitable for in-process asynchronous programming. It is possible to run a "Enterprise Messaging System" over ZeroMQ, but you would have to implement a lot on your own.
So:
ActiveMQ, RabbitMQ, Websphere MQ & MSMQ are "Enterprise Message Queues"
ZeroMQ is a message orientated IPC Library.
There's a comparison between RabbitMQ and ActiveMQ here. Out of the box, ActiveMQ is configured to guarantee message delivery - which can give the impression its slow compared to less reliable messaging systems. You can always change the configuration for performance if you wish and get at least as good performance as any other messaging system. At least you have that option. There's a lot of information on the forums and the ActiveMQ FAQ for configuration for scaling, performance and high availability. Also, ActiveMQ will support AMQP 1.0 when the spec is finalized, together with other wire formats, like STOMP.
Another plus for ActiveMQ is its an Apache project, so there is diversity in the developer community - and its not tied to one company.
I have not used ActiveMQ or RabbitMQ but have used ZeroMQ. The big difference as I see it between ZeroMQ and ActiveMQ etc. is that 0MQ is brokerless and does not have built in reliabilty for message delivery. If you are looking for an easy to use messaging API supporting many messaging patterns,transports, platforms and language bindings then 0MQ is definitely worth a look. If you are looking for a full blown messaging platform then 0MQ may not fit the bill.
See www.zeromq.org/docs:cookbook for plenty examples of how 0MQ can be used.
I an successfully using 0MQ for message passing in an electricity usage monitoring application (see http://rwscott.co.uk/2010/06/14/currentcost-envi-cc128-part-1/)
I'm using zeroMQ. I wanted a simple message passing system and I don't need the complication of a broker. I also don't want a huge Java oriented enterprise system.
If you want a fast, simple system and you need to support multiple languages (I use C and .net) then I'd recommend looking at 0MQ.
I can only add my 2 cents about ActiveMQ but since this is one of the most popular:
The language you want to write in might be important. Although ActiveMQ does have a client for most, their C# implementation is far from complete compared to the Java Library.
This means some basic functionality is flaky (fail-over protocol that ... well ... fails in some cases, no redelivery support) and other simply isn't there. Since .NET doesn't seem to be all that important to the project, development is rather slowish and there doesn't seem to be any release plan. Trunk is often broken so if you do consider this, you might want to consider contributing to the project if you want things to go ahead.
Then there is ActiveMQ itself which has a lot of nice features but some very strange issues aswell. We use the Fuse (Progress) version of activemq for stability reasons but even then there are a couple of weird "bugs" that you want to keep in mind:
Brokers that stop sending messages in some occasions
Journal Errors making the queue show messages that are not there anymore (they don't get delivered to the consumer but still)
Priority is still not implemented (is on the Issues list since the start of human kind)
etc. etc.
All and all, it is a pretty nice product IF you can live with its issues:
A) are not afraid to actively get involved when using .NET
B) develop in java ;-)
ZeroMQ is really with zero queues! It is a really mistake! It does not hav queues, topics, persistence, nothing! It is only a middleware for sockets API. If it is what you are looking cool! otherwise forget it! it is not like activeMQ or rabbitmq.
There is a comparison of the features and performance of RabbitMQ ActiveMQ and QPID given at
http://bhavin.directi.com/rabbitmq-vs-apache-activemq-vs-apache-qpid/
Personally I have tried all the above three. RabbitMQ is the best performance wise according to me, but it does not have failover and recovery options. ActiveMQ has the most features, but is slower.
Update :
HornetQ is also an option you can look into, it is JMS Complaint, a better option than ActiveMQ if you are looking for a JMS based solution.
I wrote about my initial experience regarding AMQP, Qpid and ZeroMQ here: http://ron.shoutboot.com/2010/09/25/is-ampq-for-you/
My subjective opinion is that AMQP is fine if you really need the persistent messaging facilities and is not too concerned that the broker may be a bottleneck. Also, C++ client is currently missing for AMQP (Qpid didn't win my support; not sure about the ActiveMQ client however), but maybe work in progress. ZeroMQ may be the way otherwise.
I've used ActiveMQ in a production environment for about 3 years now. While it gets the job done, lining up versions of the client libraries that work properly and are bug free can be an issue. Were currently looking to transition to RabbitMQ.
There is some discussion in the comments of this blog post, about Twitter writing their own message queue, which may be interesting.
Steve did extensive load and stress
testing of ActiveMQ, RabbitMQ, etc.
ActiveMQ is actually quite slow (much
slower than Kestrel), RabbitMQ
consistently crashes with too many
producers and too few consumers.
You probably won't have Twitter-like load initially however :)
Few applications have as many tuning configurations as ActiveMQ. Some features that make ActiveMQ stand out are:
Configurable Prefetch size.
Configurable threading.
Configurable failover.
Configurable administrative notification to producers.
...
details at:
http://activemq.net/blog
http://activemq.apache.org
If you are also interested in commercial implementations, you should take a look at Nirvana from my-channels.
Nirvana is used heavily within the Financial Services industry for large scale low-latency trading and price distribution platforms.
There is support for a wide range of client programming languages across the enterprise, web and mobile domains.
The clustering capabilities are extremely advanced and worth a look if transparent HA or load balancing is important for you.
Nirvana is free to download for development purposes.
Abie, it all comes down to your use case. Rather than relying on someone else's account of their use case, feel free to post your use case to the rabbitmq-discuss list. Asking on twitter will get you some responses too. Best wishes, alexis
About ZeroMQ aka 0MQ, as you might already know, it's the one that will get you the most messages per seconds (they were about 4 millions per sec on their ref server last time I checked), but as you might also already know, the documentation is non existent. You will have a hard time finding how to start the server(s), let alone how to use them. I guess that's partly why no one contributed about 0MQ yet.
Have fun!
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
Can anyone recommend a tool for quickly posting test messages onto a JMS queue?
Description:
The tool should allow the user to enter some data, perhaps an XML
payload, and then submit it to a queue.
I should be able to test consumer without producer.
This answer doesn't apply to all JMS brokers, but if you happen to be using Apache ActiveMQ, the web-based admin console (by default at http://localhost:8161/admin) allows you to manually send text messages to topics or queues. It's handy for debugging.
HermesJMS seems to be a rather powerful client for interacting with JMS providers. In my opinion, it is pretty unintuitive and hard to set up, though. (At least I'm mostly failing at it...)
Other, more user-friendly clients are often vendor-specific. Sonic Message Manager is a very nice and simple-to-use open-source JMS client for SonicMQ. It would be great to have a client like that working with different providers.
The ActiveMQ's web-based admin console has a big deficiency - one cannot specify any headers / custom properties when posting a message.
I came across a neat FOSS tool that can post a message and also specify headers/properties:
http://sourceforge.net/projects/activemqbrowser/
HTH
Apache JMeter is a tool (written for the Java platform) which allows:
sending messages to a queue ( point to point)
publishing/subscribing to a topic
sending both persistent and non persistent messages
sending text , map and object messages
Apache ActiveMQ includes a ProducerTool and a ConsumerTool example sources (Java) with many command-line configuration options. As it is based on the JMS API, using it with other message brokers should be easy with minor modifications.
IBM provide a free, powerful command line tool called perfharness.
Although aimed at benchmarking JMS providers, it's really good at generating (and consuming) test messages. You can use data either generated randomly or taken from a file.
The power features include sending and consuming messages at a fixed rate, using a specific number of threads, using either JMS or native MQ, etc. It generates statistics telling you exactly how fast your queue is performing (hence the name).
The only down side is that it's not super intuitive, given the number of operations it supports.
I recommend the approach of #Will and using the Web Console of ActiveMQ which lets you post messages and browse queues or delete messages easily.
Another approach I often use is to use a directory of files as sample data and use a Camel route to move the messages from the directory to a JMS queue - or to take them from a queue and save them to disk etc
e.g.
from("file://someDirectory").
to("activemq:MyQueue");
This would move all the files from someDirectory and send them to an ActiveMQ queue called MyQueue. If you'd rather leave the files in place you can use the URI "file://someDirectory?noop=true".
For more details see
the file endpoint in Camel
a sample Camel example routing from files to JMS
the various enterprise integration patterns Camel supports
Also if the JMS broker supports JMX like ActiveMQ does you can use JConsole to post message and do a lot more.
ActiveMQ has a web console for sending test messages (like mentioned above), but if your provider doesn't have this, it might be easiest to just write a console app/web page to post test messages. Sending a message in JMS isn't too hard, you might get the most benefit just writing your own test client.
If you can use Spring in Java, it has some really powerful utilities, check out the JmsTemplate.
I'm not aware of a simple client. I remember looking for one a long time ago when I researched different queue systems and trying JMS I couldn't find one then, and I couldn't find one now. One thing though - there are a ton of tutorials that get you started and you could do a simple form to achieve that.
Sorry to be not more helpful.
I have built a GUI tool for administering Open Source JMS Servers (Currently Activemq and Hornetq). It can send and receive messages and most of the usual stuff, as well as aggregate queues and topics into logical "groups".
Its a commercial product but the BETA is free and is fully functional.
try it out at http://www.rockeyesoftware.com/
For ActiveMQ the examples directory holds scripts. For Rubyists, look at example/ruby/stompcat.rb and catstomp.rb for subscribing and publishing.
I'm a brazilian developer and I made a Java program for Post HTTP and JMS Messages his available for download at: https://sites.google.com/site/felipeglino/softwares/posttool
In thath page you can found english instructions.