The SDK simplifys the implementation of subscriptions tremendously.
The interaction between Server and the Provider is done through three methods of the Provider Interface:
- AddItem
- RemoveItem
- Subscribe
and two functions of the Provider Callback Interface:
- SubscribeComplete
- ItemChanged
This interface is designed to handle two different kinds of providers:
The UA Server hides the complexity if managing multiple subscriptions and monitored items. It uses only one "Provider Subscription" to retrieve updates from a povider. The provider has to take care only about updating this one subscription considering the individual update rate of the items.
AddItem and
RemoveItem work synchronously and are adding or removing single items respectivley. These functions should return immediatly and don't call any long blocking functions. If adding an item is a complicated procedure that you don't want to do for single items you should consider implementing a
Complex Provider.
Subscribe works asynchronously. This means you can start a long running operation but
Subscribe returns immediately. When your long running operation is finished you can signal the completion of this operation by calling the
SubscribeComplete callback function.
If you retrieve new data from you underlying system you should call the
ItemChanged function of the
Provider Callback Interface to inform the server about this data change. This triggers the server to queue the new value into the monitored item queue. On the next publish cycle these value will be sent to the OPC UA Clients that are monitoring that item.
A simple provider is one where it is very easy to add and remove items without influencing the rest of the subscription. Typical cases of such providers are in-memory providers like the
Sample Provider that comes with the SDK, or providers where the underlying protocol supports adding and removing of individual items.
In this case you only have to implement the AddItem and RemoveItem functions and Subscribe can be an empty method that does nothing than sending the SubscribeComplete callback.
For some protocols adding and removing of items are very expensive operations. For example sometimes it is necessarry to remove the complete subscription and to create a new one. In this case you have to implement all three functions
AddItem,
RemoveItem and
Subscribe.
In this szenario AddItem and RemoveItem should just mark the subcsription as 'dirty' and keep account of the changes. AddItem and RemoveItem are called mulitple times from the server until all changes are done. Than Subscribe is called to finalize the changes. This is the place where you now can create a new subscription to the underlying system and clean the 'dirty' flag of your subscription.