[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (AMQP-117) Alternative mechanism for establishing a link pair
[ https://issues.oasis-open.org/browse/AMQP-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Godfrey updated AMQP-117:
-----------------------------
Description:
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.
was:
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.
> 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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]