AMQP 1.0 Support

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

AMQP 1.0 Support

Daniel Marques-5
Hello.

(Absolute AMQP and RabbitMQ newbie here, so please point to the appropriate place for this discussion if this is not it.)

We're about to embark on a new project, and am considering AMQP for it.  We're hoping to unify at least 4 different messaging/communication systems, and replace them with a single enterprise-wide message bus.  As we have apps in at least 3 languages, on 2 OSs, and would like remain vendor-independent, AMQP sounds like a good fit.  RabbitMQ seems like a great implementation for our needs.

However, I'm concerned about the lack of a current AMQP 1.0 implementation in RabbitMQ - I would hate to write the software using 0.9 and have to rewrite it to support 1.0 once an implementation became available.  If other vendors implement 1.0, it is not clear that will keep support for 0.9 around, in which case I would not see the benefit of vendor independence.

I guess I was just curious as to RabbitMQ's plans to implement (or not) 1.0 and what that timeline looked like.  I'd be also curious to hear how hard it would be to convert an application from 0.9 to 1.0.

Thanks for your help.

Dan









_______________________________________________
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: AMQP 1.0 Support

Jason J. W. Williams
Hi Daniel,

AMQP 1.0 is so dissimilar from 0.9x that 1.0 should never have been called AMQP. It's literally as different as going from Gopher to HTTP.

1.0 is very difficult to use as an app developer. It solves a very narrow problem set best suited to integrating AMQP brokers better with other non-AMQP brokers. 1.0 is architecture astronauts at their best.

Rabbit is fairly protocol agnostic... 1.0 support was mocked up to my understanding and was able to run alongside 0.9.1. So even if 1.0 took over, 0.9.1 support in Rabbit isn't going anywhere.

In reality 0.9.1 is a much better protocol for getting real work done as an app developer. The primitives are higher level and much more useful for 99% of the tasks you'll likely want to do. As a result I don't think 0.9.1 is going to go away...particularly amongst most AMQP users.

Does that help?

-J

Sent via iPhone

Is your email Premiere?

On Apr 19, 2012, at 16:49, Daniel Marques <[hidden email]> wrote:

> Hello.
>
> (Absolute AMQP and RabbitMQ newbie here, so please point to the appropriate place for this discussion if this is not it.)
>
> We're about to embark on a new project, and am considering AMQP for it.  We're hoping to unify at least 4 different messaging/communication systems, and replace them with a single enterprise-wide message bus.  As we have apps in at least 3 languages, on 2 OSs, and would like remain vendor-independent, AMQP sounds like a good fit.  RabbitMQ seems like a great implementation for our needs.
>
> However, I'm concerned about the lack of a current AMQP 1.0 implementation in RabbitMQ - I would hate to write the software using 0.9 and have to rewrite it to support 1.0 once an implementation became available.  If other vendors implement 1.0, it is not clear that will keep support for 0.9 around, in which case I would not see the benefit of vendor independence.
>
> I guess I was just curious as to RabbitMQ's plans to implement (or not) 1.0 and what that timeline looked like.  I'd be also curious to hear how hard it would be to convert an application from 0.9 to 1.0.
>
> Thanks for your help.
>
> Dan
>
>
>
>
>
>
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> [hidden email]
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
_______________________________________________
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: AMQP 1.0 Support

Gordon Sim-2
On 04/20/2012 09:21 AM, Jason J. W. Williams wrote:
> 1.0 is very difficult to use as an app developer.

I don't think it is.

Perhaps I'm misunderstanding the point or perhaps it depends on
perspective. I would accept that the 1.0 specification *as a document*
is not particularly useful to an app developer and indeed they were not
the intended audience.

An app developer in my view would generally be using an AMQP library,
rather than implementing the protocol directly, and I can't see how that
would be made any more difficult (if anything for a certain class of
users at least I think it would be more intuitive).

Whether it is more difficult to *implement* such a library is of course
also a different question.

> It solves a very narrow problem set best suited to integrating AMQP brokers better with other non-AMQP brokers.

I very much disagree.

It is certainly not limited to - or even focused on - integration with
non-AMQP brokers though it is deliberately less imposing in terms of a
broker implementations internal architecture to promote even wider adoption.

I don't believe the target problem set has narrowed since earlier
versions however, if anything it is the reverse.

What important problems does it not address in your view?

--Gordon.
_______________________________________________
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: AMQP 1.0 Support

Jason J. W. Williams
Hi Gordon

>
> I don't think it is.

We'll have to disagree. RedHat is one of a couple corporate members of
the WG that were largely responsible for pushing the shift in
direction to what became 1.0, and 1.0 serves those interests.

> An app developer in my view would generally be using an AMQP library, rather
> than implementing the protocol directly, and I can't see how that would be
> made any more difficult (if anything for a certain class of users at least I
> think it would be more intuitive).

Client libraries reflect the primitives present in the protocol, and
thereby directly the difficulty or ease with which they can be used to
build applications.

1.0 replaces useful out-of-the-box ready primitives like queues,
exchanges and bindings with a "build-it-yourself" approach using
nodes, links and filters. 0.9.x gives us the equivalent of power
tools, 1.0 instead makes you build the tools before you can ever get
going. In this regard, 1.0 and ZeroMQ have a lot in common and of the
two ZeroMQ is frankly the better choice. The point to having a broker
is provide those messaging power tools so you can focus on your
application.

Furthermore, any client library attempting to emulate
queue/binding/exchange fabric primitives using 1.0 "bricks" would be
doing so as a  non-standard convention, one that would have to be
adopted by other library writers in exactly the same way to afford the
cross-platform capabilities that 0.9.x has from day one as a draft
standard.


> It is certainly not limited to - or even focused on - integration with
> non-AMQP brokers though it is deliberately less imposing in terms of a
> broker implementations internal architecture to promote even wider adoption.

Quoting from a JPMorgan preso on 1.0 as to the design goals:

* Simplify wire protocol
* Global Addressing
* Create a model more easy to retro-fit to legacy
brokers
* Extensible layered protocol


All of these serve federation and integration (i.e. broker writers),
not the app developer.

THE reason nodes/links/filters became the new 1.0 primitives was
precisely to enable easier federation with non-AMQP brokers. Want to
forward a message on to a federated broker? No problem, attach another
link pointing to the federated broker with the right filter. 1.0
exists to make life easier on broker implementers and integrators, not
to help app developers/users. It puts the burden on the app developer
to build up the actual primitive he wants. Again, ZMQ is a better 1.0
than 1.0: it has similar primitives, is simpler, and doesn't pretend
to be anything other than a transport erector set.


As an OASIS standard now, I foresee AMQP 1.0 continuing on it's trek
to serve it's corporate masters/designers...which would be fine if it
didn't throw app developers and their productivity to the wolves as
1.0 has done.

-J
_______________________________________________
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: AMQP 1.0 Support

Martin Sustrik-2
Hi Jason, Gordon,

Interesting discussion.

I think Jason has a point in that AMQP/1.0 has deliberately dropped to
"model" part of spec (i.e. exchanges/queues/bindings) which was the real
meat of the protocol.

I have no idea what the reasons were. In any case it dumbs down the
protocol to the extent where it becomes an ugly version of TCP built on
top of TCP.

I have to disagree though that ZeroMQ/Crossroads did a similar thing.
Instead of dropping the AMQP model, my goal was to refine it, remove
weird cases (like broadcasting messages to multiple queues, then
load-balancing them to the consumers) and make the concepts implicitly
contained in AMQP model, like request/reply, publish/subscribe etc. even
more explicit.

Martin

On 20/04/12 19:37, Jason J. W. Williams wrote:

> Hi Gordon
>
>>
>> I don't think it is.
>
> We'll have to disagree. RedHat is one of a couple corporate members of
> the WG that were largely responsible for pushing the shift in
> direction to what became 1.0, and 1.0 serves those interests.
>
>> An app developer in my view would generally be using an AMQP library, rather
>> than implementing the protocol directly, and I can't see how that would be
>> made any more difficult (if anything for a certain class of users at least I
>> think it would be more intuitive).
>
> Client libraries reflect the primitives present in the protocol, and
> thereby directly the difficulty or ease with which they can be used to
> build applications.
>
> 1.0 replaces useful out-of-the-box ready primitives like queues,
> exchanges and bindings with a "build-it-yourself" approach using
> nodes, links and filters. 0.9.x gives us the equivalent of power
> tools, 1.0 instead makes you build the tools before you can ever get
> going. In this regard, 1.0 and ZeroMQ have a lot in common and of the
> two ZeroMQ is frankly the better choice. The point to having a broker
> is provide those messaging power tools so you can focus on your
> application.
>
> Furthermore, any client library attempting to emulate
> queue/binding/exchange fabric primitives using 1.0 "bricks" would be
> doing so as a  non-standard convention, one that would have to be
> adopted by other library writers in exactly the same way to afford the
> cross-platform capabilities that 0.9.x has from day one as a draft
> standard.
>
>
>> It is certainly not limited to - or even focused on - integration with
>> non-AMQP brokers though it is deliberately less imposing in terms of a
>> broker implementations internal architecture to promote even wider adoption.
>
> Quoting from a JPMorgan preso on 1.0 as to the design goals:
>
> * Simplify wire protocol
> * Global Addressing
> * Create a model more easy to retro-fit to legacy
> brokers
> * Extensible layered protocol
>
>
> All of these serve federation and integration (i.e. broker writers),
> not the app developer.
>
> THE reason nodes/links/filters became the new 1.0 primitives was
> precisely to enable easier federation with non-AMQP brokers. Want to
> forward a message on to a federated broker? No problem, attach another
> link pointing to the federated broker with the right filter. 1.0
> exists to make life easier on broker implementers and integrators, not
> to help app developers/users. It puts the burden on the app developer
> to build up the actual primitive he wants. Again, ZMQ is a better 1.0
> than 1.0: it has similar primitives, is simpler, and doesn't pretend
> to be anything other than a transport erector set.
>
>
> As an OASIS standard now, I foresee AMQP 1.0 continuing on it's trek
> to serve it's corporate masters/designers...which would be fine if it
> didn't throw app developers and their productivity to the wolves as
> 1.0 has done.
>
> -J
> _______________________________________________
> rabbitmq-discuss mailing list
> [hidden email]
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

_______________________________________________
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: AMQP 1.0 Support

Jason J. W. Williams
Hi Martin,

> I have to disagree though that ZeroMQ/Crossroads did a similar thing.
> Instead of dropping the AMQP model, my goal was to refine it, remove weird
> cases (like broadcasting messages to multiple queues, then load-balancing
> them to the consumers) and make the concepts implicitly contained in AMQP
> model, like request/reply, publish/subscribe etc. even more explicit.

I tend to think of (and use) ZeroMQ more of as a way to link
applications together in a brokerless topology and still get a lot of
the benefits of messaging. . My intention in drawing in the comparison
with ZMQ is to highlight that I think ZMQ does it right for those use
cases.

(I realize using ZMQ you can make one of your apps a broker and bake
in your own persistence)

I have a lot of respect for ZMQ.

-J
_______________________________________________
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: AMQP 1.0 Support

Gordon Sim-2
In reply to this post by Jason J. W. Williams
On 04/20/2012 06:37 PM, Jason J. W. Williams wrote:
> Client libraries reflect the primitives present in the protocol, and
> thereby directly the difficulty or ease with which they can be used to
> build applications.
>
> 1.0 replaces useful out-of-the-box ready primitives like queues,
> exchanges and bindings with a "build-it-yourself" approach using
> nodes, links and filters.

That isn't the case.

Nodes are simply a more general concept covering queues or exchanges or
indeed other types of messaging endpoints.

Links are simply subscriptions (i.e. an indication of a desire to
receive from a give queue/node) expanded to include an analogous concept
for indicating the desire/intention to send to a given queue/node. That
is useful for flow control and can enable faster routing decisions.

The same basic patterns - direct communication through shared queue,
pub-sub, request-response - are all supported.

> 0.9.x gives us the equivalent of power
> tools, 1.0 instead makes you build the tools before you can ever get
> going.

No, you would get all the same tools from your broker.

> In this regard, 1.0 and ZeroMQ have a lot in common and of the
> two ZeroMQ is frankly the better choice. The point to having a broker
> is provide those messaging power tools so you can focus on your
> application.

And that is still the case. Brokers can provide exactly the same
queueing and routing capabilities.

> Furthermore, any client library attempting to emulate
> queue/binding/exchange fabric primitives using 1.0 "bricks" would be
> doing so as a  non-standard convention, one that would have to be
> adopted by other library writers in exactly the same way to afford the
> cross-platform capabilities that 0.9.x has from day one as a draft
> standard.

The client library doesn't need to emulate that; it is brokers who will
provide the equivalent functionality.

>> It is certainly not limited to - or even focused on - integration with
>> non-AMQP brokers though it is deliberately less imposing in terms of a
>> broker implementations internal architecture to promote even wider adoption.
>
> Quoting from a JPMorgan preso on 1.0 as to the design goals:
>
> * Simplify wire protocol
> * Global Addressing
> * Create a model more easy to retro-fit to legacy
> brokers
> * Extensible layered protocol
>
>
> All of these serve federation and integration (i.e. broker writers),
> not the app developer.
>
> THE reason nodes/links/filters became the new 1.0 primitives was
> precisely to enable easier federation with non-AMQP brokers.

No, the abstractions were generalised to be less prescriptive about the
internals of a broker and to make the model simpler (e.g. no need to
explicitly declare subscription queues for standard pub-sub pattern, let
the broker do that for you) and more consistent (e.g. eliminate the need
for clumsy workarounds like the default-exchange).

> Want to
> forward a message on to a federated broker? No problem, attach another
> link pointing to the federated broker with the right filter. 1.0
> exists to make life easier on broker implementers and integrators, not
> to help app developers/users. It puts the burden on the app developer
> to build up the actual primitive he wants. Again, ZMQ is a better 1.0
> than 1.0: it has similar primitives, is simpler, and doesn't pretend
> to be anything other than a transport erector set.

ZMQ does not have similar primitives. The primitives in AMQP 1.0 focus
on reliable, flow controlled transfer of well defined message formats
all of which are deliberately not addressed by ZeroMQ.

> As an OASIS standard now, I foresee AMQP 1.0 continuing on it's trek
> to serve it's corporate masters/designers...which would be fine if it
> didn't throw app developers and their productivity to the wolves as
> 1.0 has done.

As you say, we'll have to disagree. I am confident that app developers
will be very productive on 1.0, but time will tell as they say ;-)

--Gordon.


_______________________________________________
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: AMQP 1.0 Support

Gordon Sim-2
In reply to this post by Martin Sustrik-2
On 04/20/2012 07:12 PM, Martin Sustrik wrote:
> I think Jason has a point in that AMQP/1.0 has deliberately dropped to
> "model" part of spec (i.e. exchanges/queues/bindings) which was the real
> meat of the protocol.

It has deliberately moved on from a model explicitly based on exchanges,
binding and queues. It has generalised the model, making it simpler and
more consistent, while supporting the same patterns.

I would disagree that the exchange/queue/binding was the real meat of AMQP.

> I have no idea what the reasons were. In any case it dumbs down the
> protocol to the extent where it becomes an ugly version of TCP built on
> top of TCP.

Beauty is in the eye of the beholder ;-) I don't think its fair to say
it dumbs down the protocol though, as it is more capable than previous
versions (more control over different options for reliability, more
control over managing the flow of messages, standardised approaches to
message signing etc).

The fact that TCP provides acking and flow control is not sufficient in
many cases. An application level protocol still needs to have a solution
to these, particularly one that aims to be a general protocol for
asynchronous message transfer.
_______________________________________________
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: AMQP 1.0 Support

Jason J. W. Williams
In reply to this post by Gordon Sim-2
>
> Nodes are simply a more general concept covering queues or exchanges or
> indeed other types of messaging endpoints.

My point exactly..."build your own out of our primitives".


> Links are simply subscriptions (i.e. an indication of a desire to receive
> from a give queue/node) expanded to include an analogous concept for
> indicating the desire/intention to send to a given queue/node. That is
> useful for flow control and can enable faster routing decisions.
>
> The same basic patterns - direct communication through shared queue,
> pub-sub, request-response - are all supported.

It is not the totally async model 0.9 has where publishers don't have
to understand where their messages might end up due to exchanges. It's
up to both publisher and consumer nodes to build the elaborate
interconnections between them to emulate queues/exchange/bindings.



> No, you would get all the same tools from your broker.

No, but no point in arguing in circles.


>> In this regard, 1.0 and ZeroMQ have a lot in common and of the
>> two ZeroMQ is frankly the better choice. The point to having a broker
>> is provide those messaging power tools so you can focus on your
>> application.
>
>
> And that is still the case. Brokers can provide exactly the same queueing
> and routing capabilities.

....once you build it...


>
>
> The client library doesn't need to emulate that; it is brokers who will
> provide the equivalent functionality.

....once the client library tells the broker how to build an
equivalent set of nodes, links, and filters to create a queues,
exchanges and bindings. Since this is up to the client, this is
exactly what I was saying about replicating 0.9 primitives being by
convention of the library.



> No, the abstractions were generalised to be less prescriptive about the
> internals of a broker and to make the model simpler (e.g. no need to
> explicitly declare subscription queues for standard pub-sub pattern, let the
> broker do that for you) and more consistent (e.g. eliminate the need for
> clumsy workarounds like the default-exchange).

That's a new spin on what I've been hearing from those involved
directly for 2 years.


> ZMQ does not have similar primitives. The primitives in AMQP 1.0 focus on
> reliable, flow controlled transfer of well defined message formats all of
> which are deliberately not addressed by ZeroMQ.

ZMQ does offer reliable transfer and it's primitives are very similar.
It does also offer basic flow control.


> As you say, we'll have to disagree. I am confident that app developers will
> be very productive on 1.0, but time will tell as they say ;-)

Yes we will have to. I'm sure they'll be productive to the level of
WS-* and OASIS' other stable of technologies...

-J
_______________________________________________
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: AMQP 1.0 Support

Gordon Sim-2
On 04/20/2012 09:58 PM, Jason J. W. Williams wrote:
> It is not the totally async model 0.9 has where publishers don't have
> to understand where their messages might end up due to exchanges.

It is. Your producer doesn't need to know any more about where messages
end up than when publishing to an exchange. It simply sends messages to
a named node on the broker (just like it would send to a named exchange
pre 1.0).

> It's
> up to both publisher and consumer nodes to build the elaborate
> interconnections between them to emulate queues/exchange/bindings.

No, the broker provides all of that. You may need to create the broker
node through which messages are flowing, much as you may need to create
an exchange.

The producers don't need to know anything about the consumers however,
and vice versa.

[...]
> ....once the client library tells the broker how to build an
> equivalent set of nodes, links, and filters to create a queues,
> exchanges and bindings. Since this is up to the client, this is
> exactly what I was saying about replicating 0.9 primitives being by
> convention of the library.

In 0.9, the publisher simply sends messages to the exchange. The
subscriber indicates the messages it wants from that exchange (through
bind requests).

In 1.0 the publisher sends messages to the node by establishing a link
to the node and transferring messages over it. The subscriber indicates
the messages it wants from the node by establishing a link from the
node. That is standard, not convention.

Nodes are an extension point (as were exchanges before 1.0). I can
define a new type of node behaviour for my broker, for example a last
value queue, but this is no different from previous versions and it
doesn't mean that applications themselves have to 'build their own'. The
protocol for sending to- or subscribing to- the node however is standard
and available to any 1.0 client (again just like a custom exchange would
be).

[...]
> ZMQ does offer reliable transfer and it's primitives are very similar.
> It does also offer basic flow control.

Really? Can you give point me somewhere those are described?

--Gordon.
_______________________________________________
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: AMQP 1.0 Support

Jason J. W. Williams
> In 1.0 the publisher sends messages to the node by establishing a link to
> the node and transferring messages over it. The subscriber indicates the
> messages it wants from the node by establishing a link from the node. That
> is standard, not convention.

As you've stated the producer and consumer nodes need to know about
each other, which is not how an exchange operates, thus proving my
point. Emulating the behavior of an exchange would therefore be
convention.


> Really? Can you give point me somewhere those are described?

http://zguide.zeromq.org/

-J
_______________________________________________
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: AMQP 1.0 Support

Daniel Marques-5
In reply to this post by Jason J. W. Williams
The reason I was drawn to AMQP was that the API (as far as I could tell from the RabbitMQ tutorial) was fairly intuitive how I could implement the communication patterns that my applications used. 

Is there any documentation that describes the changes from 0.9x to 1.0?  Does the AMQP group have any formal statement as to why they changed the API so significantly?

Thanks.

Dan



On Fri, Apr 20, 2012 at 4:21 AM, Jason J. W. Williams <[hidden email]> wrote:
Hi Daniel,

AMQP 1.0 is so dissimilar from 0.9x that 1.0 should never have been called AMQP. It's literally as different as going from Gopher to HTTP.

1.0 is very difficult to use as an app developer. It solves a very narrow problem set best suited to integrating AMQP brokers better with other non-AMQP brokers. 1.0 is architecture astronauts at their best.

Rabbit is fairly protocol agnostic... 1.0 support was mocked up to my understanding and was able to run alongside 0.9.1. So even if 1.0 took over, 0.9.1 support in Rabbit isn't going anywhere.

In reality 0.9.1 is a much better protocol for getting real work done as an app developer. The primitives are higher level and much more useful for 99% of the tasks you'll likely want to do. As a result I don't think 0.9.1 is going to go away...particularly amongst most AMQP users.

Does that help?

-J

Sent via iPhone

Is your email Premiere?

On Apr 19, 2012, at 16:49, Daniel Marques <[hidden email]> wrote:

> Hello.
>
> (Absolute AMQP and RabbitMQ newbie here, so please point to the appropriate place for this discussion if this is not it.)
>
> We're about to embark on a new project, and am considering AMQP for it.  We're hoping to unify at least 4 different messaging/communication systems, and replace them with a single enterprise-wide message bus.  As we have apps in at least 3 languages, on 2 OSs, and would like remain vendor-independent, AMQP sounds like a good fit.  RabbitMQ seems like a great implementation for our needs.
>
> However, I'm concerned about the lack of a current AMQP 1.0 implementation in RabbitMQ - I would hate to write the software using 0.9 and have to rewrite it to support 1.0 once an implementation became available.  If other vendors implement 1.0, it is not clear that will keep support for 0.9 around, in which case I would not see the benefit of vendor independence.
>
> I guess I was just curious as to RabbitMQ's plans to implement (or not) 1.0 and what that timeline looked like.  I'd be also curious to hear how hard it would be to convert an application from 0.9 to 1.0.
>
> Thanks for your help.
>
> Dan
>
>
>
>
>
>
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> [hidden email]
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss


_______________________________________________
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: AMQP 1.0 Support

Gordon Sim-2
In reply to this post by Jason J. W. Williams
On 04/20/2012 10:47 PM, Jason J. W. Williams wrote:
>> In 1.0 the publisher sends messages to the node by establishing a link to
>> the node and transferring messages over it. The subscriber indicates the
>> messages it wants from the node by establishing a link from the node. That
>> is standard, not convention.
>
> As you've stated the producer and consumer nodes need to know about
> each other,

No, they do not.

> which is not how an exchange operates, thus proving my
> point.

An exchange operates by having a publisher send messages to it and a
subscriber bind their queue to it in order to receive (possibly a subset
of) those messages.

Likewise in 1.0 the publisher publishes to the node and the subscriber
links to it in order to receive (possible a subset of) those messages.

In neither case does the subscriber need to explicitly know about the
publisher. They simply know about the exchange or, in 1.0 terminology,
the node.

Of course prior to 1.0 you can have the subscriber simply subscribe to a
pre configured queue and have the bindings set up as part of the
configuration. The same is possible with the 1.0 model.

> Emulating the behavior of an exchange would therefore be
> convention.
>
>
>> Really? Can you give point me somewhere those are described?
>
> http://zguide.zeromq.org/

I'll take lack of anything more specific as confirmation that ZMQ does
not offer primitives for reliability but deliberately leaves that to
applications themselves.
_______________________________________________
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: AMQP 1.0 Support

Jason J. W. Williams


> I'll take lack of anything more specific as confirmation that ZMQ does not offer primitives for reliability but deliberately leaves that to applications themselves

Durable yes is up to the app, but reliability and durability are not the same thing. I'll take the lack of distinction as you painting them to be the same.

-J
_______________________________________________
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: AMQP 1.0 Support

Gordon Sim-2
On 04/21/2012 03:04 AM, Jason J. W. Williams wrote:
>
>
>> I'll take lack of anything more specific as confirmation that ZMQ does not offer primitives for reliability but deliberately leaves that to applications themselves
>
> Durable yes is up to the app, but reliability and durability are not the same thing. I'll take the lack of distinction as you painting them to be the same.

I'm not concerned with durability here (or I would have said so), but
with _reliability_.

I see nothing in the API reference or the protocol specification to
corroborate the assertion that ZMQ has similar primitives for
reliability to AMQP.

The guide discusses reliability patterns that applications can build
themselves given ZMQ does not provide primitives for that. (I'm not
criticising that decision, merely clarifying the facts).


_______________________________________________
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: AMQP 1.0 Support

Martin Sustrik-2
On 23/04/12 14:41, Gordon Sim wrote:

> I see nothing in the API reference or the protocol specification to
> corroborate the assertion that ZMQ has similar primitives for
> reliability to AMQP.
>
> The guide discusses reliability patterns that applications can build
> themselves given ZMQ does not provide primitives for that. (I'm not
> criticising that decision, merely clarifying the facts).

It's using TCP (standard sliding window algorithm) to ensure reliability.

The interesting question is what *additional* reliability guarantees
does AMQP (or, as a matter of fact, by any other messaging protocol)
provide on top of TCP. That's a question that's bugging me for years and
I haven't found an answer yet.

IIRC I've asked it during the "message broker websocket subsprotocol"
IETF discussion with Mark Hapner (author of JMS) and Clebert Suconic
(current HornetQ project lead) but never got an answer.

Anyway, I think we've strayed pretty far away from the intended topic of
this mailing list.

Martin

_______________________________________________
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: AMQP 1.0 Support

Gordon Sim-2
On 04/23/2012 03:02 PM, Martin Sustrik wrote:
> The interesting question is what *additional* reliability guarantees
> does AMQP (or, as a matter of fact, by any other messaging protocol)
> provide on top of TCP. That's a question that's bugging me for years and
> I haven't found an answer yet.

It allows reliability to be defined in terms that are useful to the
application layer.

The fact that the packet has made it to the remote host and been acked
at the TCP level - even if that was somehow exposed through the socket
API - does not mean that the message it is part of has been successfully
processed.

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