Interoperability and Server Agnosticism (was Re: Pressured to move to AMQP 1.0)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Interoperability and Server Agnosticism (was Re: Pressured to move to AMQP 1.0)

Tony Garnock-Jones-6
On 5 June 2014 08:00, Gordon Sim <[hidden email]> wrote:
So 0.9.1 is to all intents and purposes the RabbitMQ protocol (much like 0-10 is just a Qpid protocol, or OpenWire is just an ActiveMQ protocol).

That doesn't seem quite right. Support for 0-9-1 is even now an advertised feature of Qpid-java: http://qpid.apache.org/components/java-broker/index.html. There was quite a bit of cross-implementor support for it, for a while there, whereas I'm not aware of similar levels of interoperability for the other protocols you mention.

If interoperability and choice is a consideration (and I'd certainly accept they aren't in every case) then AMQP 1.0, STOMP and MQTT are better choices as they are supported by more than one broker implementation (including RabbitMQ).

I've recently become curious about AMQP 1.0 interoperability again. I know with STOMP and MQTT, quite sophisticated distributed systems can be written using client libraries without regard for which STOMP or MQTT server one is using. Beyond a certain point, however, one leaves the spec behind and relies on implementation-specific behaviour.

For a while there, AMQP 0-9-1 enjoyed similar rough consensus and running code. People can still run their clients against Qpid-java using AMQP 0-9-1, and get a certain base level of interchangeability with RabbitMQ.

What is the level of server-agnosticism that people are actually seeing with AMQP 1.0?

It's clear that people can get the AMQP 1.0 transport and data encoding languages to interoperate. They might even get some links established.

Is it possible to get server implementation agnosticism while programming at the AMQP 1.0 equivalent of the conceptual level of exchanges, queues, and bindings?

I read the OASIS spec yesterday, at long last, and it doesn't seem to cover anything at that level, and the various extension registries at amqp.org are all empty. Perhaps there's a de-facto standard for AMQP 1.0 broker behaviour? Any pointers anyone has to hand would be appreciated.

Regards,
  Tony

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Interoperability and Server Agnosticism (was Re: Pressured to move to AMQP 1.0)

Gordon Sim-2
On 06/05/2014 02:27 PM, Tony Garnock-Jones wrote:
> What is the level of server-agnosticism that people are actually seeing
> with AMQP 1.0?

A reasonable degree, though I would certainly love to see some consensus
from implementers on extending that.

Specifically you can get reliable (i.e. acknowledged) or unreliable
(unacknowledged) transfer to and from queues, you can get pub-sub, you
can get request-reply with several different brokers[1] all based on the
core protocol as published.

I would argue that's probably more than you get with either STOMP or
MQTT on their own.

In addition several brokers support some extensions and conventions that
essentially allow full JMS functionality against different brokers over
AMQP 1.0.

> It's clear that people can get the AMQP 1.0 transport and data encoding
> languages to interoperate. They might even get some links established.
>
> Is it possible to get server implementation agnosticism while
> programming at the AMQP 1.0 equivalent of the conceptual level of
> exchanges, queues, and bindings?
>
> I read the OASIS spec yesterday, at long last, and it doesn't seem to
> cover anything at that level, and the various extension registries at
> amqp.org <http://amqp.org> are all empty.

There have been some filters registered for some time now:

   http://www.amqp.org/specification/1.0/filters

These are relied on for full JMS behaviour and also include some support
for the old exchange types.

> Perhaps there's a de-facto standard for AMQP 1.0 broker behaviour?

There is work ongoing I believe to standardise the JMS mapping,
including any extensions it requires, which will provide some of this.

--Gordon

[1] Both Qpid brokers, Qpid dispatch router, ActiveMQ, ApolloMQ,
HornetQ, SwiftMQ and apart from the request-response, RabbitMQ. There is
of course also Microsoft's ServiceBus and IBM's MQLight, but I haven't
yet tried either of those.

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Interoperability and Server Agnosticism (was Re: Pressured to move to AMQP 1.0)

Tony Garnock-Jones-6
On 5 June 2014 10:25, Gordon Sim <[hidden email]> wrote:
Specifically you can get reliable (i.e. acknowledged) or unreliable (unacknowledged) transfer to and from queues, you can get pub-sub, you can get request-reply with several different brokers all based on the core protocol as published.

Thanks. I've gone back and puzzled out some of how that might be done, based on the spec document. But it doesn't look like many of the brokers actually do things based on the spec's ideas of "distribution mode" and "filter". Instead, they encode routing, filtering, and node type into source and target *names*.

The documentation for each of (at least!) ApolloMQ [1], ActiveMQ [2], and RabbitMQ [3] makes it clear that the semantics of AMQP 1.0 routing, filtering, and delivery is largely based on encoding things into node names. Each broker does this quite differently, and seemingly quite independently of support for destination modes and filters.

This makes me think that reliably selecting, say, queueing functionality requires intimate knowledge of the specific broker the client will be running against, in order to choose the correct way of encoding the notion of "queue" into the node name.

I may have missed something in the protocol spec, but on top of this, it looks like there is no standard way to create nodes (queues/exchanges) with application-chosen names. How do implementations deal with that?

Not being able to choose node names for shared resources in a portable way makes it difficult both to select specific functionality (because of the encoding of node type and filtering into node names) and to establish a shared understanding of resource names between clients communicating via a broker.

Based on what you've said so far, I don't think AMQP 1.0 server-agnostic interop is there yet. It sounds more like it's en par with STOMP, actually, which can do all of the things you list above, with the caveat that some things are encoded into resource names, just like it seems AMQP 1.0 implementations do.

(Aside: Why isn't request-reply layered atop regular messaging? Why does it need special support? That seems weird.)

Cheers,

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Interoperability and Server Agnosticism (was Re: Pressured to move to AMQP 1.0)

Gordon Sim-2
On 06/05/2014 06:00 PM, Tony Garnock-Jones wrote:
> This makes me think that reliably selecting, say, queueing functionality
> requires intimate knowledge of the specific broker the client will be
> running against, in order to choose the correct way of encoding the
> notion of "queue" into the node name.

Yes, that's true. You do need to potentially tailor the exact name you
use in each case. That is an area I think we could improve by some
consensus between existing implementers without requiring much extra
effort by anyone.

> I may have missed something in the protocol spec, but on top of this, it
> looks like there is no standard way to create nodes (queues/exchanges)
> with application-chosen names. How do implementations deal with that?

ApolloMQ has a very nice approach that is a lot like RabbitMQ policies.
You define a configuration along with a pattern and when links are
attached for non-existent nodes matching that pattern, the policy is
used to create them.

The Qpid c++ broker has copied this approach. It lets you control what
part of the 'node' namespace can be created on demand and how to do that
creation. It also centralises the configuration making it easy to change
and enforce (as opposed to having to have it updated in all clients).

I'd love to see other implementations adopting similar approaches. (It
would work with STOMP as well).

> Not being able to choose node names for shared resources in a portable
> way makes it difficult both to select specific functionality (because of
> the encoding of node type and filtering into node names) and to
> establish a shared understanding of resource names between clients
> communicating via a broker.
>
> Based on what you've said so far, I don't think AMQP 1.0 server-agnostic
> interop is there yet. It sounds more like it's en par with STOMP,
> actually, which can do all of the things you list above, with the caveat
> that some things are encoded into resource names, just like it seems
> AMQP 1.0 implementations do.

I've found that request-response doesn't work so well with STOMP because
of the lack of support for creating temporary reply-queues and including
a reference of some sort to them in the reply-to.

> (Aside: Why isn't request-reply layered atop regular messaging? Why does
> it need special support? That seems weird.)

I think having the ability to create a temp reply queue and a clear way
of specifying that in the reuest message such that responses get back
where they are expected is very helpful. AMQP 1.0 provides this.

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss