Service Discovery
This is a Concept topic for RemObjects SDK for Delphi
Service Discovery Overview
RemObjects SDK for Delphi provides a default infrastructure for discovering servers and services available on the local network. This can be used to automatically detect new servers that have become available if an old server has gone down, or to automatically distribute calls to different servers across the network based on information such as server load or custom criteria.
The Service discovery infrastructure is implemented using standard principles on top of the general RemObjects SDK Architecture - it provides merely a reference implementation, and you could easily implement your own similar or different solution to fit your needs.
Service Discovery Components
Service Discovery is implemented through the TRODiscoveryClient and TRODiscoveryServer components, which handle the client and server side of the discovery, respectively.
These components will use the Broadcast Channel to communicate. The client component will require a Channel and Message to be assigned that will be used to contact the server, while the server will automatically be made available through the standard RemObjects SDK server architecture, if a TROBroadcastServer is configured for your server application.
Publishing Services for Discovery
The discovery server provides two options for configuring the list of available services it will make available:
- using the SupportRegisteredServerClasses property, you can configure if all RemObjects SDK Services registered within the server should automatically be listed as available (the default), or not.
- using the ServiceList string collection, you can provide a custom list of service names that will be made available.
Note that a "service" in this context does not necessarily map directly to a RemObjects SDK Service implemented by your server - you can use service names to reference any concept of services that your client will understand.
For example, you could have a method to query different databases defined in your RemObjects SDK Service, and use the ServiceList to specify which particular data tables are available on the given server - even though the same underlying service method will eventually be used by the client to access the database.
Fine-Tuning Discovery at Runtime
In addition to the above properties, the OnServiceFound event will give you additional control over what services will be published as response to a specific discovery request. This event will fire every time a request service was found on the local server, but will grant your code the final decision on whether the service will be shown as supported, or not.
For example, the event handler could evaluate the current server load, and dynamically decide to hide the service for the moment (allowing the client to direct the request to a different server).
Discovering Services from a Client
Discovering available services is a very straightforward process for the client. After setting ServiceName to the name of the client you are looking for, a call to RefreshServerList will initiate a broadcast request across the network to look for servers implementing the service.
As servers that provide the desired service respond to the request, the OnServiceFound event will fire for each server that is discovered; the server address will also be added to the ServerList property for future reference.
Note that due to the asynchronous nature of the discovery broadcast, theRefreshServerList method will return right away, and the actual responses from the servers (which could be none, one, or more than one) will come in at undetermined intervals, depending on the network structure and load. Since the number of servers on the network is unknown, there is no definitive way to tell at which point all servers have responded and/or no further responses can be expected - although it can be reasonably assumed that responses should come in within a short period of time.
Passing Custom Discovery Options between Clients and Servers
For advanced discovery usage, the discovery components allow passing of custom data to and from individual discovery requests - for example to further qualify the requirements of the service that is being sought or the capabilities of the service that is being returned.
To pass this custom information, one or more structs must be defined in your server's RODL file, descending from TRODiscoveryOptions (defined in Discovery.RODL) and containing whatever custom information you want to pass back and forth. Different specialized struct types may be used for either direction.
Clients can pass this type into their call to RefreshServerList - the data will then be streamed to the server along with the broadcast request. On the server, the information received from the client will be passed into the OnServiceFound event, allowing the server to evaluate the data before making the decision of returning an answer or not (see above under Fine-Tuning Discovery at Runtime).
Finally, the server can pass options back to the client from the OnServiceFound event by either filling or replacing the struct that was originally passed in or by instantiating a new struct.
For example, a chat client might send the name of the chat partner it wants to initiate contact with as part of the custom data. Each server on the network could then determine if the respective user is connected - and only the one server that has a connection to the target user will actually send a discovery response.
See Also
- Lists
- Namespace Lists for .NET — Java
- Interface Lists for .NET — Delphi — Java
- Protocol Lists for Xcode
- Class Lists for .NET — Xcode — Delphi — Java
- Object Lists for JavaScript
- Enum Lists for .NET — Xcode — Java
- Alias Lists for Xcode — Delphi
- Implements Lists for .NET — Xcode — Delphi — Java
- Data Types
- File Types
Product: RemObjects SDK
Available Editions: RemObjects SDK for .NET, Xcode, Delphi, Java and JavaScript
