This Service is implemented by Discovery Servers.
This Service registers a Server with a Discovery Server. This Service will be called by a Server or a separate configuration utility. Clients will not use this Service.
A Server shall establish a SecureChannel with the Discovery Server before calling this Service. The SecureChannel is described in 5.5. The Administrator of the Server shall provide the Server with an EndpointDescription for the Discovery Server as part of the configuration process. Discovery Servers shall reject registrations if the serverUri provided does not match the applicationUri in Server Certificate used to create the SecureChannel.
This Service can only be invoked via SecureChannels that support Client authentication (i.e. HTTPS cannot be used to call this Service).
A Server only provides its serverUri and the URLs of the DiscoveryEndpoints to the Discovery Server. Clients shall use the GetEndpoints Service to fetch the most up to date configuration information directly from the Server.
The Server shall provide a localized name for itself in all locales that it supports.
Servers shall be able to register themselves with a Discovery Server running on the same machine. The exact mechanisms depend on the Discovery Server implementation and are described in OPC 10000-6.
There are two types of Server applications: those which are manually launched including a start by the operating system at boot and those that are automatically launched when a Client attempts to connect. The registration process that a Server shall use depends on which category it falls into.
The registration process for manually launched Servers is illustrated in Figure 11.
Figure 11 – The Registration Process – Manually Launched Servers
The registration process for automatically launched Servers is illustrated in Figure 12.
Figure 12 – The Registration Process – Automatically Launched Servers
The registration process is designed to be platform independent, robust and able to minimize problems created by configuration errors. For that reason, Servers shall register themselves more than once.
Under normal conditions, manually launched Servers shall periodically register with the Discovery Server as long as they are able to receive connections from Clients. If a Server goes offline then it shall register itself once more and indicate that it is going offline. The period of the recurring registration should be configurable; however, the maximum is 10 minutes. If an error occurs during registration (e.g. the Discovery Server is not running) then the Server shall periodically re-attempt registration. The frequency of these attempts should start at 1 second but gradually increase until the registration frequency is the same as what it would be if no errors occurred. The recommended approach would be to double the period of each attempt until reaching the maximum.
When an automatically launched Server (or its install program) registers with the Discovery Server it shall provide a path to a semaphore file which the Discovery Server can use to determine if the Server has been uninstalled from the machine. The Discovery Server shall have read access to the file system that contains the file.
Table 6 defines the parameters for the Service.
Table 6 – RegisterServer Service Parameters
|requestHeader||RequestHeader||Common request parameters. The authenticationToken is always null.The type RequestHeader is defined in 7.33.|
|Server||RegisteredServer||The Server to register. The type RegisteredServer is defined in 7.32.|
|ResponseHeader||ResponseHeader||Common response parameters. The type ResponseHeader is defined in 7.34.|
Table 7 – RegisterServer Service Result Codes
|Bad_InvalidArgument||See Table 182 for the description of this result code.|
|Bad_ServerUriInvalid||See Table 182 for the description of this result code.|
|Bad_ServerNameMissing||No ServerName was specified.|
|Bad_DiscoveryUrlMissing||No discovery URL was specified.|
|Bad_SemaphoreFileMissing||The semaphore file specified is not valid.|