[rabbitmq-discuss] Writing applications using AMQP, basic design questions

Wed Mar 3 18:25:24 GMT 2010

ello :-)

I'm stuck with a few questions about designing an application based on
AMQP messaging, and using RabbitMQ. I'm not sure how much of this is
RabbitMQ-specific. If anyone knows a mailing list for AMQP apps in
general or if rabbitmq-discuss is not the right place for this
message, please feel free to shout :-)

I realise it's a bunch of text, but I've tried to keep it as short as
possible without omitting stuff I thought was relevant.

Redux: a bunch of mobile clients send stuff to us. That stuff has to
be persisted, and potentially tracked live by someone monitoring a
particular mobile client through a browser. Mobile clients have UUIDs
and pre-shared certificates, signed by me. Browser clients might have
a pre-shared cert (not really necessary), but they can be uniquely
identified for auth purposes (through OpenID).

Because people want to track one particular mobile client, I think the
AMQP thing to do would be to have one queue per mobile client. As long
as we're not in AMQP/1.0 which gets rid of them there would be one
exchange, and the routing key would be the unique identifier of the
mobile client. (Sending everything to everyone is not acceptable,
because the information is sensitive.)

I'm interested in temporary queues, so that only active mobile clients
have queues running. I have read the AMQP specification (v0.8),
section 2.2.8, specifically the part about temporary queues.
Apparently any client can cause a queue to be created, and the client
creating it is responsible for creating a consumer on it.

I take it that means letting the mobile clients (with untrustworthy
software) do AMQP is a bad idea. The first idea is to have an
HTTP(S)->AMQP bridge. Why?

1. As said before, if the client (soon to be producer) is responsible
for creating a consumer, a malicious client might refuse to do that.
I'm not sure what happens then. The bridge could be responsible for
creating the consumer that persists the data. I trust the bridge.
Giving the clients the power to start a consumer that talks to a
database sounds like a disaster waiting to happen anyway.
2. Perhaps not every stupid mobile client can be taught to speak AMQP,
but *everyone* understands HTTPS.
3. AMQP seems to be more catered towards doing messaging for your
app's internals, as opposed to, for example, XMPP or perhaps even
STOMP, which is built for going to clients.
4. Authentication through pre-shared certs means client's don't have
to tell me who they are (and, as a result, attackers can't lie about
it either).
5. Not telling the mobile clients about my internal messaging means
more flexibility to change it later.

Basically, I don't really know anything about AMQP yet, and I might be
completely wrong about everything, but I'd love to pick you guy's
brains' on the matter. I have some other question regarding the other
end (monitoring in browsers: an AMQP -> HTTPS bridge to do Comet-like
things), but perhaps asking too many questions about that when I don't
even know the mobile client side makes sense is any good might be a
bit of a waste of time.

Thanks for reading this admittedly long post, and thanks in advance
for your comments and insights :-)
Laurens