node manager

[oroulet]

@einarmo since you advertise for your node managers in fork README. I would like to hear your rational for implementing these. What is your goal?

[einarmo]

The idea is to make server node hierarchies composable.

In general, in an OPC-UA server, different parts of the node hierarchy are obtained in different ways.

• You have the core node hierarchy, which is hard-coded.
• You have the diagnostics namespace, which is dynamic based on the connected clients.
• You may have the core nodes for one or more hard-coded/static companion standards.
• And on top of all this you have your application node hierarchy.

This means that "Browse" can mean radically different things depending on where in the hierarchy you are looking:

• In the core node hierarchy it's a simple lookup in the hard coded table of nodes.
• In the diagnostics node manager it may involve looking in the subscriptions or session tables for the server.
• In the companion standards it may also be hard coded, but a different subset than the one in the core node manager.

Finally, in your own application namespace there are many different ways nodes may be obtained:

• Large complex servers may store their nodes in a database, so a browse translates to one or more queries.
• Servers may wrap other OPC-UA servers, so a browse call may result in one or more browse calls to other servers.
• Servers may dynamically map one or more underlying systems they communicate with over a different protocol, so browse may result in a call over Modbus or HTTP or anything else under the sun. OPC-UA is after all a standard for developing a standard interface.

To simplify some common use cases we have the InMemoryNodeManager which simplifies the fetching of nodes to storing them in memory, but leaves the fetching of values to user defined callbacks, and SimpleNodeManager which lets users define simple per-node callbacks and stores all nodes in memory.

The point is that an OPC-UA server can be a great many different things, and the node manager abstraction is intended to make it possible to develop these servers. You can probably see how a server that dynamically gets its node hierarchy from a hundred PLCs on a slow industrial network cannot possibly constantly query them to stay up to date, or that some servers may need special ways to sample data from underlying systems.

It's been on my TODO to write a server demonstrating some of the crazier ways this can be used, but it hasn't been high priority.