[openstack-dev] [marconi] Reconsidering the unified API model
Gordon Sim
gsim at redhat.com
Tue Jun 10 17:07:07 UTC 2014
On 06/10/2014 05:27 PM, Kurt Griffiths wrote:
> I think the crux of the issue is that Marconi follows the REST
> architectural style. As such, the client must track the state of where it
> is in the queue it is consuming (to keep the server stateless). So, it
> must be given some kind of marker, allowing it to page through messages in
> the queue.
Isn't this true both for task distribution and feed semantics?
[...]
> To my knowledge, this API can’t be mapped directly to AMQP.
I believe you are right, you could not map the HTTP based interface
defined for Marconi onto standard AMQP. As well as the explicit paging
through the queue you mention above, the concepts of claims and direct
deletion of messages are not exposed through AMQP[1].
AMQP was designed as an alternative interface into a messaging service,
one tailored for asynchronous behaviour. It isn't intended as a direct
interface to message storage.
> Perhaps there are other types of brokers that can do it?
There are certainly brokers that support a RESTful HTTP based
interface[2] alongside other protocols. I don't know of any standard
protocol designed for controlling message storage however.
--Gordon.
[1] You could use a filter (aka a selector) to retrieve/dequeue a
specific message by id or some other property. You could also define
behaviour where an acquired message gets automatically released by the
server after a configurable time. However, in my view, even with such
extensions AMQP would still not be an ideal interface for message
*storage* as opposed to message transfer between two processes.
[2] http://activemq.apache.org/rest.html, http://hornetq.jboss.org/rest
and I'm sure there are others.
More information about the OpenStack-dev
mailing list