IS 04 Registry

Please refer to the Generic API Server page as a starting point before considering the specifics below.

Best Practice

Multiple Network Interfaces

Registration APIs can safely be implemented on hosts with multiple network interfaces, exposing both the API and any mDNS announcements via all available interfaces.

Query APIs can be implemented on hosts with multiple network interfaces, but care should be taken around generation of WebSocket subscription URLs. Each subscription URL is generated using an absolute address. As such, the IP address or DNS name used for each subscription must match the address of the network interface which the subscription request arrived on. A Query API may choose to expose a different list of WebSocket subscriptions on each of its network interfaces in order to avoid confusion when debugging (in essence running a separate Query API on each interface).

Hints for Large Systems

• Providing support for the basic and advanced query capabilities is key
• Registration and Query APIs can be scaled independently
• APIs do not need to be resident on the same host(s) as the registry database
• Advanced control systems may interact with the registry directly to gain the benefits of a database query language, however registry implementations are vendor specific so this should only be used where absolutely necessary
• The specifications do not mandate that the Query API surfaces everything in the registry to everyone. For example, segmentation of studios in a facility could be achieved using the Registration and Query API interfaces, but only exposing each studio's resources in that scope. Alternatively (and perhaps more likely) a control system may provide this segmentation facility.
• Permit configuration of the 'garbage collection' interval for missed heartbeats. Some systems may prefer a longer interval before removing Nodes which are failing to heartbeat from the registry. This could provide time to alert a user to the issue such that they could resolve it and avoid an outage.
• Support multiple versions of the specification at once. This permits seamless upgrades of facilities as-per the Upgrade Path
• Ensure that system clocks are synchronised on clustered registries as this may cause issues with certain forms of replication or with garbage collection timers.

Adding Value

Dependent upon the intended users of your registry application, it may be more critical to add some features which go beyond the scope of the interoperable specification. Some such features are identified below, but these are far from exhaustive:

• Dashboards & Monitoring

  • Heartbeat Checks: Flagging to the user the frequency of heartbeats received from each Node, whether any have been missed, and whether any Nodes are in danger of becoming unregistered as a result. This could additionally notify of any 'flapping' Nodes which regularly re-register.
  • Version Reports: Identifying for each Node in the system, which API version is has registered using.
  • Connection Reports: Identifying for each Node or registry client in the system, which instance of a federated registry it is currently connected to.
  • Missing Nodes: Business critical Nodes may be identified and require immediate notification to an external monitoring application if they become unresponsive.

• High Availability & Scaling

  • Replication: Federating the registry's data store between several registry instances. This could be used to provide a load balancing function, or to ensure there is always a registry available to fail over onto if one develops a fault.