In the publish-subscribe messages distribution scenario senders of messages, called publishers, do send messages without knowledge of which subscribers if any, there may be. Similarly, subscribers receive messages that are of interest, without knowledge of which publishers, if any, there are.

In case they do not even need to know about the existence of each other it is difficult to recognize the publisher on the network and provide request/response scenario. In this case, the message may be recognized as a one-way ticket.

This case looks like the scenario described for the Microsoft Azure IoT Hub and AMQP:

https://github.com/Azure/amqpnetlite/blob/master/docs/articles/service_to_iothub.md

In the article, this bidirectional communication is implemented without any protocol modification. I believe it is the same with this request, i.e. this functionality shall be implemented above the PubSub using two independent communication paths.

Consider to invalidate it.

As you describe, part 14 (PubSub) is for one-to-many communication.
And yes, the sender must not necessarily know how many subscribers are listening.

Part 6 describes mappings from OPC UA request/response to different TransportProtocols. There are already TransportProtocol mappings for request/response via

• OPC UA TCP
• SOAP/HTTP
• OPC UA HTTPS
• WebSockets

I don't know AMQP well enough to say whether it makes sense to add a mapping.
In any case, this is an issue for part 6 rather than part 14.

Part 6 in section 7 defines OPC UA Connection Protocol (UACP). Additionally The OPC UA Connection Protocol is designed to work with the SecureChannel implemented by a layer higher in the stack.

This mapping is not applicable to PubSub. Part 14 in section 7 defines PubSub Mappings and we MUST not confuse both.

My example is not related to AMQP, because it points out the Microsoft Azure IoT Hub as an example. It is not relevant to this discussion that this scenario is described in the AMQP stuff. IoT Hub is prepared to used many protocols as the messages transport layer. Azure IoT Hub natively supports communication over the MQTT, AMQP, and HTTPS protocols. In some cases, devices or field gateways might not be able to use one of these standard protocols and require protocol adaptation. In such cases, you can use a custom gateway.

Anyway, to provide request/response relationship a session must be established by communicating parties. In the IoT Hub case, the session is created by the Hub above the transport protocol. In case of PubSub we don't have any layer above. The PuSub application is self-contained, so it must be responsible to do it, namely, it must select two unidirectional communication channel to form one bidirectional request/response interoperability. In my opinion, in this case, we shall implement this scenario using independent OPC UA session oriented connectivity. It is native and all in one approach. IoT Hub doesn't have this capability so it must offer something artificial.

More about my finding related to the implementation of the PubSub you can find at:

https://mpostol.gitbooks.io/object-oriented-internet/content/Networking/SemanticData/README.PubSubMTF.html