|
On 12/8/2015 12:48 PM, David Ingham
wrote:
<stuff deleted>
Thanks I understand that Dave. But my
point was that AMQP basically implements queues and topics for
the model of inter-process interaction.
[DBI] No, AMQP 1.0 has no notion
of queues and topics, it has a notion of 1-way Links.
All I meant to say was that the typical communication model exposed
to the programmer is queues and topics. I understand that 1
way-links may lie underneath in AMQP, but for this discussion that
doesn't much matter to me at the moment.
However, if you feel their explanation is incorrect, feel free to
correct the folks behind this article:
https://spring.io/understanding/AMQP
As one whose implemented RPC over AMQP and
other messaging impls (e.g. [1]), it hasn't been my experience
that layering non-trivial RPC on async messaging is as simple
as you implying. Particularly when one considers
service-and-distribution-level issues in addition to
transport-level protocol differences [2].
[DBI]
I agree that implementing RPC over AMQP 0.x, JMS and other
queuing systems isn’t trivial. Doing request/response over a
pair of AMQP 1.0 Links is different.
Indeed it is. I would argue that generally what people are 'looking
for' is closer to RPC than it is req/resp over a link. Granted not
true for all use cases, but generally true I would say. That's why
I'm asking the following...
>My follow-up question really is: what thinking is currently
happening WRT this mapping between IoT >communication needs (e.g.
provisioning) and these abstractions (e.g. async/sync, point vs.
multipoint, reliable vs. >unreliable, rpc, events, etc).
Thanks,
Scott
|
