I would also caution that the low level API is most certainly less
stable than JMS for two reasons: 1) AMQP itself has not reached 1.0 and
is subject to certain changes until it does, and 2) our low level
implementation is itself also subject to change. If you're willing to
track these changes closely and likely become more involved in the qpid
community then this may not be a problem, but if you just want to write
your code and forget about it then JMS is probably the safer bet.
Robert Greig wrote:
2008/5/9 Rajith Attapattu <[EMAIL PROTECTED]>:
Some of the reasons for using the AMQP API directly would be,
===============================================
You want to dynamically create/delete exchanges/queues/bindings as part of
the application logic.
The JMS API works well if you pre create your exchange/queues/bindings using
the JNDI properties file.
This is true just now but it does not imply that you need an "AMQP
API" to do that since it does not conflict with a JMS API. You could
easily add this capability to our "extended JMS API" and that is
definitely what I would like to see if users want it.
If your application needs to query for different exchanges, bindings, queuesis
etc as part of your application logic then you would need to use the AMQP
API
Again, since this doesn't conflict with JMS it could be added to our API.
I agree, I even think a lot of this could be done without requiring
casting to our own APIs, e.g. we could provide special topics/queues
that permit apps to access/manipulate broker wiring using ordinary JMS
messages.
If you want to have very fine grain flow controlling. The JMS impl deals
with only message units and use window mode (however we should make the byte
units configurable). If your application needs to switch between the
different flow control modes and/or change byte/message credits dynamically
as part of application logic then using the AMQP API makes sense.
I think it would be interesting to see if we could add this into the
JMS API. I need to understand the flow control in 0-10 a bit more
before I could really comment however.
This only makes sense to use for messages that won't easily fit into
memory, however I believe you could expose the functionality through
BytesMessage.
--Rafael
