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

Shawn McAllister commented on MQTT-197:
---------------------------------------

Having raised this JIRA, here is my stab at a proposal for discrete requirements for the mechanism(s) we need to define to satisfy the usecases we have in mind:

In the context of an IoT device D and another application A (where A is typically a datacenter application but could be another IoT device):

1. Support request/reply interactions with requests originating from D and replies from A as well as requests originating from A and replies from D.
-  This supports a device D autonomously requesting information from a datacenter application A and allows an application A to request information from D or effect some change on D or cause some action by D as and when A decides to do so, without requiring polling (and coupling) from D to A.

2. Support request/reply where the request may be routed to many target applications (pub/sub) and where the requester may receive many replies to its one request.  This must be supported for when either D or A initiate the request.

3. From an application’s pov, it must be possible to support both synchronous and asynchronous request/reply.  In the case of asynchronous requests, many requests may be outstanding at any one time.

4. For asynchronous request/reply, the defined mechanisms must allow the requester to correlate a reply message with the original request that was sent (or request state) and must allow for replies to be received in a different order than the order in which the requests were sent.

5. To ensure scalability, the request/reply interaction must be stateless in the MQTT broker when D and A are both MQTT clients.

6. Required topologies:
a. D and A are both MQTT clients that are connected to the same or different MQTT brokers (eg. when MQTT bridges are used to support subtended MQTT brokers on gateways, trains, buses, etc.)

b. D is an MQTT client but A uses some other non-MQTT protocol and may or may not be connected to the same broker as D.   
	i. In this case, it must be possible for the “MQTT-to-otherProtocol” interworking point to be NOT application-specific.  That is, there must be a 
           standard method for the transport interworking function to find in the MQTT packet the information required to interwork the MQTT request/reply 
           with the request/reply information of the “otherProtocol”.  Motivation for this is to avoid the need for application+messaging-specific bridges to 
           support request/reply in this topology
	ii. This is an important topology because while it is expected that MQTT will be widely used by IoT devices, it is not expected that it be as widely 
            used by datacenter applications and thus this messaging transport interworking must be offered as simply as possible “out of the box” by 
            standard products.
        iii. The interworking function itself is beyond the scope of what the MQTT OASIS group can specify.

	Pictorially described as follows:
                                    +---------------+
	D <---- mqtt ---->  |broker + iwf  |<---- non-mqtt protocol ---> A
                                    +---------------+


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