Errata exists for this version of the document.
With PubSub, OPC UA Applications do not directly exchange requests and responses. Instead, Publishers send messages to a Message Oriented Middleware, without knowledge of what, if any, Subscribers there may be. Similarly, Subscribers express interest in specific types of data, and process messages that contain this data, without knowledge of what Publishers there are.
Message Oriented Middleware is software or hardware infrastructure supporting sending and receiving messages between distributed systems. It depends on the Message Oriented Middleware how this distribution is implemented.
To cover a large number of use cases, OPC UA PubSub supports two largely different Message Oriented Middleware variants. These are:
- A broker-less form, where the Message Oriented Middleware is the network infrastructure that is able to route datagram-based messages. Subscribers and Publishers use datagram protocols like UDP multicast.
- A broker-based form, where the Message Oriented Middleware is a Broker. Subscribers and Publishers use standard messaging protocols like AMQP or MQTT to communicate with the Broker. All messages are published to specific queues (e.g. topics, nodes) that the Broker exposes and Subscribers can listen to these queues. The Broker may translate messages from the formal messaging protocol of the Publisher to the formal messaging protocol of the Subscriber.
PubSub is used to communicate messages between different system components without these components having to know each other’s identity.
A Publisher is pre-configured with what data to send. There is no connection establishment between Publisher and Subscriber.
The knowledge about who Subscribers are and the forwarding of published data to the Subscribers is off-loaded to the Message Oriented Middleware. The Publisher does not know or even care if there is one or many Subscribers. Effort and resource requirements for the Publisher are predictable and do not depend on the number of Subscribers.