Hello Luke,

Thank you for a detailed explanation and a good question.

The strategy 2 is the one you should use. In practice, it’s also the only convenient strategy. In other words, this strategy means that you use UaNode-based node objects to cache all values in memory. You don’t need to do anything else than provide new values to the objects to make your server work as expected.

You can use

or

to provide new samples to the Variables.

Alternatively, if you cannot use the UaNode based approach, you can implement a fully customized node manager, as described in chapter “Custom Node Manager” of the server tutorial document. This approach will be beneficial in case you have your data already in a background system and do not wish to replicate the data in the node objects. You will need to implement all node handling yourself, but you don’t need to instantiate a UaNode object in the memory for every node. The SDK does provide an example implementation of this approach, called MyBigNodeManager.

Hi,

In your original post, I think the strategy 1 only covers implementing read calls and not subscriptions. If we consider a generic OPC UA server implementation, it’s kind of assumed that the server needs to implement a subscription mechanism and the client application then decides if it issues read calls or creates subscriptions.

I’m actually going to answer more generically and maybe not exactly to the direct question here. The point being that a generic OPC UA server basically has three possible types of variables:

a) Internal data. This kind of variable values are not read from an external data source but it’s completely internal to the server application. For example, the standardized ServerStatus node (browse path Objects->Server->ServerStatus) typically contains only data that is internal to the server application.

b) Variables that are updated by external events. In the context of Prosys OPC UA Java SDK, this strategy means that you use UaNode-based node objects to cache all values in memory. This strategy also requires that the external system can actively update the values to the OPC UA server or that the OPC UA server application has internal logic (such as a timer) which updates the values to UaNode objects. In the context of Prosys OPC UA Java SDK, this is the most typical case because the SDK is designed so that this is the most easiest approach to implement.

c) Variables which poll external devices. In this case, the OPC UA server fetches the value directly from an underlying system and not from it’s own cache. In the context of the original forum post, this external device would be the temperature sensor. This approach will be beneficial in case you have your data already in a background system and do not wish to replicate the data in the node objects. You can implement this approach with Prosys OPC UA Java SDK if you implement a fully customized node manager. However, with the current Java SDK this requires a lot of work and for this reason in the context of Prosys OPC UA Java SDK this approach is used much less than the UaNode based memory cache.

It’s hard to say what strategy would be “more used” generally. Different approaches have their own benefits.

Hi Mike,

Typically the value should be written directly to the device (sensor/actuator) without delay. The normal place to intercept the write calls in your implementation of IoManagerListener and write the value to the underlying device.

In OPC UA, there’s also a return value for a successful operation that completes asynchronously. So it’s also a valid scenario that you have a separate logic for making the writes to underlying device. But as said, the most typical scenario is to write directly to the data source.