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

Wed Mar 3 23:32:09 GMT 2010

Hi Laurens,

On Wed, Mar 3, 2010 at 12:25 PM, Laurens Van Houtven <lvh at laurensvh.be> wrote:
> 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 :-)

-snip-

> 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.)

Are you talking about exposing your mobile apps to external users via AMQP?

What's the nature of the public API. Is there a performance or
throughput requirement?

Working with an AMQP interface is considerably different from working
with a REST or other RPC interface. If you're thinking along these
lines, I'd float the idea by some of your users to see what they think
of the approach. That's also assuming you have a technical requirement
to use AMQP for the public interface.

> 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.

You can create your queues as exclusive, which tells rabbit to auto
delete the queue once the declaring connection is closed.

> 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.

Running AMQP on mobile clients would make for a cool demo, but you're
thinking is sound here.

> 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.

In my block-and-tackle understanding, you would opt for a message
oriented approach for a few reasons:

- Out-of-the-box support async application patterns
- Latency requirements prohibit the use of expensive transports like HTTP
- Flexibility in provisioning services

(I hope others weigh in with their thoughts here.)

You may very well be fine with an HTTP server and a database. I think
you'll want to be pretty clear on why you need a broker, else you'll
end up spending a lot of time horsing around with the tech for minimal
or no payoff. You've already signed up for an HTTPS interface for the
mobile clients, so that's a sunk cost.

>
> Thanks for reading this admittedly long post, and thanks in advance
> for your comments and insights :-)
> Laurens
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>

Garrett