OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

amqp message

[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

Rob Godfrey created AMQP-117:

             Summary: 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]