This option assumes a messaging Broker in the middle as shown in Figure 15. No application is speaking directly to other applications. All the communication is passed through the Broker. The Broker routes the NetworkMessages to the right applications based on business criteria ("queue name", "routing key", "topic" etc.) rather than on physical topology (IP addresses, host names).
Advantages of this model (partly depending on used Broker and its configuration) include:
- Publisher and Subscriber do not have to be directly addressable. They can be anywhere as long as they have access to the Broker.
- Fan out can be handled to a very large list of Subscribers, multiple networks or even chained Brokers or scalable Brokers.
- Publisher and Subscriber lifetimes do not have to overlap. The Publisher application can push NetworkMessages to the Broker and terminate. The NetworkMessages will be available for the Subscriber application later.
- Publisher and Subscriber can use different messaging protocols to communicate with the Broker.
In addition, the Broker model is to some extent resistant to the application failure. So, if the application is buggy and prone to failure, the NetworkMessages that are already in the Broker will be retained even if the application fails.
Figure 16 depicts the applications, entities and messages involved in typical communication scenarios with a Broker. It requires use of messaging protocols that a Broker understands, like AMQP defined in ISO/IEC 19464:2014 or MQTT defined in ISO/IEC 20922:2016. In this model the Message Oriented Middleware will be a Broker that relays NetworkMessages from Publishers to Subscribers. The Broker may also be able to queue messages and send the same message to multiple Subscribers.
Note that the Broker functionality is outside the scope of this specification. In terms of the messaging protocols, the Broker is a messaging server (the OPC UA Publisher and the OPC UA Subscriber are messaging clients). The messaging protocols define how to connect to a messaging server and what fields in a message influence the Broker functionality.
An OPC UA Publisher that publishes data may be configured through the PubSub configuration model. It contains a connection Object per Broker. The Broker is configured through an URL in the connection. The connection can have one or more groups which identity specific queues or topics. Each group may have one or more DataSetWriters that format a DataSet as required for the messaging protocol. A DataSet can be collected from a list of Event fields and/or selected Variables. Such a configuration is called PublishedDataSet.
Each DataSet is sent as a separate DataSetMessage serialized with a format that depends on the DataSetWriter. One DataSetMessage format is the JSON message mapping which represents the DataSet in a format which Subscribers can understand without knowledge of OPC UA. Another DataSetMessage format is the UADP message mapping.
Message confidentiality and integrity with the Broker based communication model can be ensured at two levels:
- transport security between Publishers or Subscribers and the Broker or
- message security as end-to-end security between Publisher and Subscriber.
The Broker level security requires all Publishers and Subscribers to have credentials that grant them access to the necessary queue or topic. In addition, all communication with the Broker uses transport level security to ensure confidentiality. The security parameters are specified on the connection and group.
The message security provided by the Publisher is only defined for the UADP message mapping.