[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