[OASIS Issue Tracker] (MQTT-197) Support request/reply as a new MEP

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

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

Allan Stockdill-Mander  commented on MQTT-197:
----------------------------------------------

I was thinking of a slight variation on the above.

An axiom of this idea is that a client will receive responses on fixed topic structure, eg: $<clientid>/response/<correlation id>

The client sets a correlation id in a publish sent to a service topic.

The broker substitutes this id with an indicator of where the service should respond. In a naive single broker setup this may just be $<clientid>/response/<correlation id>. In a more complicated clustered arrangement it might be something else that the broker use to route between each other, in an implementation that wants to ensure anonymity and decoupling of requester and servicer it could be a uuid. Essentially the substituted id field is the topic the servicer should reply on.

The servicer handles the request and sends a normal publish to the response address.

The various implementations of broker decide how to handle any translations they've done and the response is delivered to the requesting client on $<clientid>/response/<correlation id>

From a client point of view I can setup a single message handler for all responses, simple clients can reuse a single request id that they control and it provides a mechanism for requests that can have multiple responses.

For servicers it handles the case of shared subscriptions.

> Support request/reply as a new MEP 
> -----------------------------------
>
>                 Key: MQTT-197
>                 URL: https://issues.oasis-open.org/browse/MQTT-197
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: New Feature
>          Components: candidateCN
>            Reporter: Shawn McAllister
>
> This JIRA requests that the version of the MQTT protocol after 3.1.1 be augmented to support the request/reply message exchange pattern.  Minimally what is required is the ability to (optionally) carry a "reply-to" topic in a published "request" message that would allow the receiver to publish a "reply" message addressed to the contained reply-to topic.
> Hopefully the need to support request/reply is not in dispute as it is a very common message exchange pattern supported by HTTP, JMS and all major messaging products because of its usefulness and for which there are many applications in M2M use cases.
> The only way now with MQTT3.1.1 (that I am aware of)  to return a reply to the sender of a request message is for the requester and replier to coordinate on the reply-to address outside of any specific services provided by MQTT.  For example, by embedding the reply-to address in the payload of the message.   The main functional reason this is insufficient is that it does not allow protocol interworking functions(MQTT to some other messaging protocol)  that are not (and should not be) aware of application payloads to create an end-to-end request/reply flow.
> Therefore I would like to request that the TC consider and implement the protocol changes required to support this functionality.



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