Archived
This forum has been archived. Please start a new discussion on GitHub.
IceStorm vs AMQP
Hi,
Our company has deferred the decision to set up some kind of standardized message queuing system for several years. There have been many projects that seemingly could have been enhanced by coordinating data flow between systems using messaging, but the cost to implement this was always deemed not worth the risks.
This calculation has changed, because we have decided that for certain applications we must have message oriented middleware. So if one is late to the MOM party, why not start with the lastest standard that is *not* vendor-specific and for which there are *credible open source implementations*?
I wonder if anyone from zeroc or any other knowledgeable users have an opinion about how IceStorm compares to basic packages like RAbbitMQ or OpenAMQ?
A related question would be, if I decided that for whatever reason IceStorm does not stack up against AMQP, how reasonable would it be to choose to try to use ICE on top of AMQP, so that we could have language-neutral type system on top of a messaging protocol of our choice?
I am not in fact making a negative comparison between IceStorm and any messaging product or standard, but I do feel that ICE rpc handily beats or supercedes many other approaches, and I do not feel comfortable making such a declaration about IceStorm.
If my ignorance can be cleared up by simply reading the docs or some whitepaper, apologies.
Our company has deferred the decision to set up some kind of standardized message queuing system for several years. There have been many projects that seemingly could have been enhanced by coordinating data flow between systems using messaging, but the cost to implement this was always deemed not worth the risks.
This calculation has changed, because we have decided that for certain applications we must have message oriented middleware. So if one is late to the MOM party, why not start with the lastest standard that is *not* vendor-specific and for which there are *credible open source implementations*?
I wonder if anyone from zeroc or any other knowledgeable users have an opinion about how IceStorm compares to basic packages like RAbbitMQ or OpenAMQ?
A related question would be, if I decided that for whatever reason IceStorm does not stack up against AMQP, how reasonable would it be to choose to try to use ICE on top of AMQP, so that we could have language-neutral type system on top of a messaging protocol of our choice?
I am not in fact making a negative comparison between IceStorm and any messaging product or standard, but I do feel that ICE rpc handily beats or supercedes many other approaches, and I do not feel comfortable making such a declaration about IceStorm.
If my ignorance can be cleared up by simply reading the docs or some whitepaper, apologies.
0
Comments
-
In short IceStorm is not a message queue, and therefore these products are not comparable. IceStorm is a publish/subscribe system. That is it sends message from publishers to subscribers, much as you might publish stock quotes for interested parties.
Message queuing is about queuing messages for consumption by workers, typically by a single worker. For example, you might want to queue a print job to one of many available printers, but you don't want that print job to be printed multiple times. Message queuing systems often have additional features, such as persistence of messages and transactional behavior which IceStorm lacks.0 -
RabbitMQ / Icestorm
Hi there, Alexis from RabbitMQ AMQP here. May I add a few comments?
First off, I don't know much about Ice beyond a quick glance through the docs just now. It looks incredibly cool and thorough. Apologies though, if I have misunderstood anything.
Second, IceStorm looks like it could fairly easily implement at least the pubsub part of AMQP, if not the queueing (which is equivalent to a shared consumption buffer). This is because AMQP pubsub uses a notion called a 'routing key' which has a correlate in Icestorm: that of a 'Topic' (45.3.2). Subscribers on topics in Icestorm are like consumers in AMQP using keys to bind routing rules in the broker.
Third, I note that Icestorm has oneway semantics (45.3.3) which is similar to AMQP. But AMQP explicitly encourages twoway to be built out of this using reply queues (oneway back), whereas Icestorm presumably uses Ice for RPC.
Finally, AMQP brokers like RabbitMQ, offer persistent storage in case of delivery failure. Various qualities of service, flow control, etc, are supported in different ways.
In summary, "what works for you". I'd think if you were already within an Ice setting, you'd be pushed to not use Icestorm if you want object-object pubsub. Starting from scratch, it depends on your use case.
Hope this helps,
alexis0 -
Just a word of warning here: implementing a service like IceStorm is a decidedly non-trivial exercise. You should embark on such a course only if you are certain that there is no other option.
Cheers,
Michi.0
