02/24/2014
I find it weird that there is no ApplicationUri field in the ServerOnNetwork structure. This structure is returned from the FindServersOnNetwork service, and from the GDS QueryServers method.
I have always thought that ApplicationUri-s are meant for long-term persistence of "server references" on the client side. That is, a client would not (necessarily) have to persist the URL of the server itself, because the larger system may be reconfigured in the future, and the URL would change, but the ApplicationUri would be a logical identifier that won't change. A smart client would have an ability to persist the ApplicationUri, and then use the discovery mechanism to convert that to a discovery URL of the server. This has been possible with the FindServers methods, where one of the inputs is a serverUri[] array, therefore the client can use that to look up the server by its ApplicationUri.
Now, let's say I want to write a client that uses the FindServersOnNetwork, or GDS QueryServers. The user of the client should be able configure it to connect to a specific server, and a reference to that server should be persisted in the client. With the GDS at least, that should even work when the server itself is off-line: It should be sufficient that the GDS has a knowledge of it.
So, not knowing much about the server, the client calls FindServersOnNetwork, or GDS QueryServers. It gets back an array, ServerOnNetwork[]. Using information in this array, it can select the server and connect to it (because there is a discoveryUrl in its elements). But how to obtain the ApplicationUri for long-term persistence? It's not in ServerOnNetwork. And no piece of information in ServerOnNetwork would allow access to it. For example, the GDS FindApplications method (which, in theory, provides more detailed info about the server), needs applicationUri on its input. How can the client use this method, when the ApplicationUri is nowhere to get?
Either I have overlooked something, or the ApplicationUri-s were never meant for this use case. If so, how to achieve such thing in OPC UA?
Also note that ServerUri-s are used (indirectly) in relation to expanded Node IDs for "cross-server" references, which is a somewhat related use case. The expanded node ID has an index into a Server Table, and the Server Table contains Server URIs. I see this as a confirmation of my assumption that the ApplicationUri-s (ServerUri-s) were meant for the persistence of the "server references", because they are what the server (indirectly) provides in the expanded Node ID.
Thanks for any help or opinion.
05/12/2015
FindServersOnNetwork is a thin wrapper over mDNS which is a lightweight protocol for multicast discovery.
The operative word is 'lightweight' which means there was no space to broadcast the long application URI strings in the mDNS packets.
If you need the ApplicationUri you must call FindServers on the URL provided by FindServersOnNetwork.
05/12/2015
Sorry for the late reply.
We wanted QueryServers and FindServersOnNetwork to have the same returned structure so the processing could be the same for either code path. Both methods return endpoints for servers which means multiple entries could refer to the same server. Only you have the discovery url you need to use FindServers to get additional metadata.
I see why you are asking for what you are asking for. Perhaps a mantis issue on part 12 for a new method.
02/24/2014
Thank you.
This is now Mantis 3584, https://opcfoundation-onlineap.....hp?id=3584 .
1 Guest(s)