amqp — archive

Groups - linkpair uploaded

From: Jakub Scholz <[email protected]>
To: [email protected]
Date: Wed, 15 Mar 2017 13:56:00 -0000

Hi Rob, I read through it and I have some points which are not completely clear to me … - I was a bit surprised to see the introduction chapter talk about queues since the core spec doesn’t seem to use the term queue that much. Shouldn’t we stick with something more neutral like “node”? At the end you don’t need necessarily a queue to implement what you described there. Or is there some special reason why you used queue? - Today, when you use temporary queues (well, I used queue term as well J ) to process the requests and responses, your service can use a plain AMQP client (e.g. Qpid JMS client) to receive the requests and respond to them. It is not clear to me how would this work with the link pairs. How would for example a simple client implement this? How will it accept the link pairs which it receives? - In general, it is not really clear to me how would you implement even the requestor side for example in something like JMS. Do you and Robbie have already some idea? (not really needed to put it into the document, but might be useful for the discussion) - In the chapter 2.1.2, you talk about the propagation across network. You expect that for every hop you create a separate link pair. That means that when you have a big network, all the link pairs will propagate up to the service which actually answers the request. That can result in quite a large number of links handled by the service. Sounds a bit inefficient to me. You have much more experience with actually writing the AMQP servers than I do … do you think that this is OK and will not cause any problems? Thanks & Regards Jakub From: [email protected] [mailto:[email protected]] On Behalf Of Rob Godfrey Sent: 10. brezna 2017 10:49 To: [email protected] Subject: [amqp] Groups - linkpair uploaded Submitter's message All, After the last TC meeting a number of us agreed to go away and try to make some progress on the various work streams that we have outstanding. One of the building blocks that a lot of the other streams were waiting on was a definition of how to do direct request-response messaging without requiring an intermediary. After some discussions amongst the interested parties we came up with the idea of "link pairing" which is described in this document. I have a number of other documents that I'll be putting out over the next week or two. Please send any comments/suggestions to this list. I'll aim to set up regular TC meetings once everybody's clocks are in sync again :-) -- Rob Godfrey Document Name : linkpair Description AMQP defines links as unidirectional transport for messages between a source and a target. A common messaging pattern is that of "request-response", that is, two parties partaking in a bidirectional conversation using messages. This document defines a common pattern for pairing two unidirectional links to create a bidirectional message transport between two endpoints. Download Latest Revision Public Download Link Submitter : Rob Godfrey Group : OASIS Advanced Message Queuing Protocol (AMQP) TC Folder : Working Documents Date submitted : 2017-03-10 01:48:07 ----------------------------------------- Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte Informationen. Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bitte sofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen ist nicht gestattet. The information contained in this message is confidential or protected by law. If you are not the intended recipient, please contact the sender and delete this message. Any unauthorised copying of this message or unauthorised distribution of the information contained herein is prohibited. Legally required information for business correspondence/ Gesetzliche Pflichtangaben fuer Geschaeftskorrespondenz: http://deutsche-boerse.com/letterhead