OPC UA notifications

As mentioned in the previous section, the client can define one or more subscriptions within an active session. For each subscription, it can create monitored items, which produce notifications that are stored in specific queues. According to the frequency specified by the publish interval, for every subscription, the current contents of all queues of the monitored items related to the subscription are merged into a NotificationMessage, to be delivered to the client. In OPC Classic, this information was sent through callbacks, which allowed the server to invoke methods on the client. In OPC UA, the communication mechanism is based on unidirectional connections that don't use the callback mechanism. This means it can easily be managed by firewalls and is independent of the underlying transport layer.

Through the Publish Service request, the client sends a request to the server, expecting to receive a Publish Service response that contains a NotificationMessage within the expiration time specified by the publishing interval. A Publish Service request does not refer to a specific subscription, but just to the session in which the request has been submitted. So, for each Publish Service request, the server will be required to forward to the client a NotificationMessage from those produced by the subscriptions of the active session. If several NotificationMessage have been produced and are ready to be transmitted, the server will decide which NotificationMessage to send to the client, either according to the priority of the subscription or by using a Round Robin algorithm.

The following diagram shows the notification mechanism we just described. For each Publish Request received, the server selects a subscription, picks a NotificationMessage, and is sent a Publish Response. The following diagram also shows a Publish Request queue, in which all requests that are advanced by the client and received in the session are queued: