[rabbitmq-discuss] Simpler STOMP Behaviour

Tue Oct 5 12:36:07 BST 2010

Lionel,

On 10/05/2010 08:07 AM, Lionel Cons wrote:
> Michael Bridgen<mikeb at rabbitmq.com>  writes:
>> Since there's no reply from the server to SUBSCRIBE, and we generally
>> want reply queues to have different properties to shared queues, really
>> the only option is to have a distinguished prefix for reply queue
>> destinations, and require clients to supply their own (preferably fresh)
>> names.
>
> In practice, other solutions exist. I'm not sure which one is
> preferable.
>
> (1) With ActiveMQ, one can subscribe to /temp-queue/whatever and a
> private queue with a random name will be created on the broker. The
> client program can send a message to itself, examine the destination
> header of the received message and find out this way what is the real
> queue name.

I don't quite understand this -- when sending the tracer message, does 
the client also use "/temp-queue/whatever" as the destination; and if 
that works, why bother finding out the "real" queue name?

> (2) We could imagine using the RECEIPT frame to allow the broker to
> "reply" to the client. Something like:
>
>    SUBSCRIBE /i-want-a-private-queue
>    receipt:123
>
>    RECEIPT
>    receipt-id:123
>    destination:/queue/004b2782fba54d18576bc2c710b517b1

Ah, RECEIPT, good call.  I was wrong about the server no being able to 
reply.  This would be my preferred style; with the following as a option 
too.

>> SUBSCRIBE /reply/<md5 of some client properties>
>
> This would work too.
>
>>> Also, what about AMQP 1.0? Have you considered it in order to get a
>>> syntax that can be adapted/extended to the new AMQP 1.0 concepts?
>>
>> Do you mean using something like /node/ for destinations?
>
> For instance. AMQP 1.0 has nodes, queues, links and filters (and no more
> exchanges). They should be exposed via STOMP somehow.

Not any more; queues are mentioned only in passing if at all.  And nodes 
really are just a stand-in something for addresses to be addressing. 
Links are an abstraction in the transfer protocol rather than part of a 
model.

It's not true to say there are "no more exchanges" in the sense that 
AMQP 1.0 somehow does away with the exchange/binding/queue model.  The 
recommendation sets out a message transfer protocol, and tries very hard 
to not take any position on where messages are when they are not being 
transferred.  So it's not the case that the AMQP 1.0 recommendation 
supplants the broker model given in previous versions of AMQP with 
something else (nodes, links, whatever) -- it simply steers clear of 
saying anything about a broker model.

> In addition, AMQP 1.0 introduced the notion of global addressing,
> something like node-name at container. This should also be usable from
> STOMP.

This was mooted at some point but doesn't actually appear in the 
recommendation, which says next to nothing about the form of addresses. 
  It may still come about, in some ancillary part of the specification.

> However, I'm not up-to-date with what AMQP 1.0 really is today. Concepts
> like remote addressing have been described for instance in last year's
> F2F meeting:
> http://www.amqp.org/confluence/download/attachments/2523324/AMQP+F2F+Presentation.pdf
> I don't know if these are still relevant...

If you want to catch up it is worth reading the recommendation; it's 
significantly different to the previous most long-lived revision (PR2) 
which was itself something of a departure from earlier revisions.

Michael.