Behavior of Method Nodes defined in ObjectTypes

[arnoweiss]

Assume the following setup:

The resulting Object does contain a Folder and a Method node, however the behaviour bound to the InstanceDeclaration on the ObjectType level is not passed on to the Object instance. Calling TypeMethod yields the expected behavior, InstanceMethod returns BadNotImplemented.

I'm not sure if this is intended and didn't find anything useful in the Pt.3 of the spec. My expectation would be that all instances of an ObjectType should behave alike and thus the methods should.

[kevinherron]

I don't think the spec indicates you must or must not do this. There are a lot of variations described in the Call service in Part 4 for what you can provide as the objectId and methodId parameter when calling a method.

I think the intention is that you can have something like "static" methods that are invokable by providing the NodeId of ObjectType as the objectId parameter (and the corresponding methodId being the NodeId of the Method hanging off that ObjectType).

This "static" method could have a different implementation than the Methods belonging to Object instances of that ObjectType.

So all that said... I think this just comes down to the implementation choice of the SDK and user expectations. Right now as you can see all Methods need to have their behavior explicitly "installed" on them, regardless of whether they were instantiated as part of a complex type or not.

[arnoweiss]

Understood. Access to the InstanceMethod node is slightly unergonomical. It's either guessing the NodeId of the InstanceMethod (Object's NodeId + ensuing BrowsePath) or traversing and filtering the references starting from Object.

Is there a smarter way I'm not thinking of?

[kevinherron]

Well, I guess it would be a little un-ergonomic if you don't have a code-generated model, because then traversing to find the method is much easier.

The alternative is probably to use the overload of NodeFactory::createNode that accepts a NodeFactory.InstantiationCallback. This has an onMethodAdded callback that hopefully has enough information to figure out which method is being instantiated and add behavior:

/**
 * Called when a {@link UaMethodNode} has been added to a {@link UaObjectNode} somewhere in the instance
 * hierarchy.
 *
 * @param parent   the {@link UaObjectNode} the method was added to.
 * @param instance the {@link UaMethodNode} instance.
 */
default void onMethodAdded(@Nullable UaObjectNode parent, UaMethodNode instance) {}

[kevinherron]

(it's not immediately clear to me why parent might be null for a method... I think that may be a mistake)