[OASIS Issue Tracker] (AMQP-117) Alternative mechanism for establishing a link pair

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/AMQP-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=66927#comment-66927 ] 

Clemens Vasters commented on AMQP-117:
--------------------------------------

In the above example, you'd need two magic nodes and they'd need to know and be configured to forward messages between them on the reply path, no? How long does that magic node exist?

> Alternative mechanism for establishing a link pair
> --------------------------------------------------
>
>                 Key: AMQP-117
>                 URL: https://issues.oasis-open.org/browse/AMQP-117
>             Project: OASIS Advanced Message Queuing Protocol (AMQP) TC
>          Issue Type: Bug
>          Components: Link Pairing
>            Reporter: Gordon Sim
>
> In my opinion, introducing a completely new mechanism for request-response is a mistake.
> I don't see any real problem we have that would necessitate this new approach. 
> If you want this link pairing concept, why not implement it via a dynamic-node-property that indicates the sending link with which the receiving link is associated? (Avoiding the need to wait for a server assigned address could likewise be achieved by a dynamic-node-property and advertised connection capability).
> That way you have one mechanism for request-response, with the ability to modify that basic pattern for more specialised cases if necessary. Less work and less risk of increased interoperability issues.
> Proposal :
> To establish a request-response "pair" with a service S 
> Client attaches receiving link L to a dynamic source, with a dynamic-node property/value "paired-source -> S" 
> Client attaches sending link L to target S
> The links themselves do not carry the paired property.  We can still use $me as the reply-to.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)