Hi Everyone,
As discussed at the last meeting I'm throwing out a few key addressing scenarios I'm interested in supporting.
The general category can roughly be described as enabling REST-like use of AMQP. The features of AMQP make it a really powerful choice for this sort of thing, however the addressing (and indeed its current definition of source and target) provide a bit of a stumbling block along the way. While this doesn't preclude REST-like usage, it does mean that rather than there being one obvious way to apply REST-like patterns to AMQP, there are several subtle and non-obvious ways.
The general idea here is to be able to easily write down the address of an endpoint, along with an open ended set of parameters for that endpoint, and establish a link based on this transcribable representation. Below I will describe some specific scenarios, along with the challenges of trying to support them currently. I'm fairly sure there are a whole bunch more useful scenarios that would fall out of this sort of thing, but these are the ones closest to what I've directly encountered.
== REST-like Subscriptions ==
You can roughly imagine establishing a subscription to an "address+parameters" as analogous to an HTTP get, except instead of getting back the result in the usual HTTP way, you get back a fully asynchronous stream of messages.
== REST-like Request/Response ==
AMQP provides unidirectional message flows as a basic building block. While this is one of the things that makes it powerful, it also makes simple request/response scenarios harder than they need to be. Using reply-to as the basis of simple request/response requires the requester to somehow have access to an AMQP address that is routable by any third parties to which the initial request may be forwarded. While this is very useful in some scenarios, it requires a much more complex and involved setup than the analogous scenario for say a simple HTTP request/response. A REST-like subscription capability would provide a nice way to do a basic Request/Response style interaction that doesn't involve both parties having a fully routable AMQP address. The requester simply encodes his request into the parameters for the endpoint, establishes an incoming link from that endpoint, and reads back any responses.
== API Keys ==
This is a basic scenario of supplying API keys as part of establishing a link. It's interesting to note that while the above scenarios focus mostly on incoming links, i.e. links initiated by the receiver of messages, this particular scenario applies equally to outgoing links.
There are a number of challenges associated with supporting the above scenarios, but they mainly boil down to where exactly in the terminus configuration do you stuff the parameters, and how do you write that down in a transcribable form. Currently, one option for outgoing links is to supply parameters for your
endpoint inside a filter, however this constitutes something of an abuse
for a couple reasons:
- Firstly, filters as defined are geared
towards message intermediaries rather than endpoints, as such they are
set up to operate on arbitrary pre-existing message streams, e.g. the
canonical example of a filter is basically an SQL where clause.
- Filters are expected to be registered and understood by multiple
classes of intermediaries, whereas the form and semantics of the
parameters of a REST-style subscription, are generally nprivate to the
endpoint.
- Unlike a filter, the parameters of a REST-style
subscription, may actually define the form of the content being
returned, e.g. the parameters could control what is/is not included in
the message content, not just which messages are returned, so they wouldn't necessarily compose well with other filter types.
This
isn't to say filters aren't a plausible way to go about this sort of
thing, e.g. we could define a general purpose open ended filter type for
this sort of case, but that would still require some amount of
specification, and perhaps most importantly, we would still need a
standard way to specify the terminus configuration in a transcribable
way.
The other option for this sort of thing is to
simply encode the parameters into the address string itself, e.g.
//global-address/foo?a=b. There are a couple of drawbacks here as well. For one thing message
intermediaries now have a bunch of parameters bunged into the string
they are using for routing. Another issue is that larger parameters, e.g. API keys or what have you are kind of cumbersome with this approach.
--Rafael