[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=66928#comment-66928 ] 

Rob Godfrey commented on AMQP-117:
----------------------------------

So If we consider each node A,B,C is in container Na, Nb and Nc respectively...

Na establishes a receiving link L1 with Nb to a dynamic source with dynamic-node property "paired-source"="B" target A, and a sending link L1 from source A to target B
Nb establishes a receiving link L2 with Nc to a dynamic source with dynamic-node property "paired-source"="C" target B, and a sending link L2 from source B to target C

Obviously the containers Nb and Nc have to understand some link pairing magic to associate the paired links... Which hints at the biggest conceptual difference here - that in the original proposal the knowledge of the pairing can be contained to a given node, whereas in the alternative proposal the container which holds the node has to have knowledge of the pairing / magic.

> 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)