06/03/2019
Hi,
I’m new to OPC UA and I wonder, if it is possible to call a published method (part 4, chapter 5.11) or modify an attribute of a node stored in a server (publisher) from a client (subscriber) in a PubSub infrastructure using AMQP transport? I’ve read part 14 of the standard, but did not find the related information.
I assume all services (defined in part 4) are possible, because a subscriber of a topic may have read or write access to the underlying data. But possibly, I’ve missed something.
Thank you for your help.
Carsten
05/30/2017
Any service that requires a request-response message pattern is not suited for PubSub.
That said, we did explore defining a client-server transport over AMQP/MQTT but our testing established that brokers need to be carefully tuned to make them useful for applications using a request-response pattern.
In theory, sessionless service calls over AMQP/MQTT could work without broker tuning but we are waiting for users to tell the committee that they really need such capabilities.
05/30/2017
Carefully tuned means the queues have to be configured to minimize delay and support large messages. What creates problems is brokers tuned in this way no longer scale as well for huge numbers of clients which negates one of the reasons for using a broker in the first place.
There is a prototype that has not been maintained here:
In OI4.0 (https://www.openindustry4.com/) we want to use OPC UA over MQTT. Pub-Sub seems to be ok, but additionally we want to use OPC UA Services over MQTT.
I search in the link https://github.com/OPCFoundati…..yping/AMQP for some mapping informations.
Where can I find how the Call-Service is mapped into a PubSub network message?
Is there some draft specification in any WG available (for instance the UA WG?)
br
05/30/2017
This feature has not been defined yet.
In short term, I was going to suggest session-less service calls could work but are not recommended because it would be completely insecure because the AccessToken is sent cleartext over MQTT. It could be viable if you lock down your MQTT queues and make sure only authorized users are allowed to send to the queues used by the Server to process the incoming Sessionless requests.
1 Guest(s)