| Platform SDK: Active Directory, ADSI, and Directory Services |
When you publish your service using service connection points, you need to consider how clients will locate the SCP for your service. If multiple instances of the service exist, you must consider how clients will distinguish the service with the desired capabilities from similar services with different capabilities. If you are publishing a replicated service, you must consider how a client will choose a replica. This topic discusses these issues for various types of services.
For a replicable service there can be one or many instances (replicas) of the service, and clients don't care which replica they connect to because each provides the same service. Active Directory is an example of a replicated service: all domain controllers for a given domain hold identical data (subject to replication latency) and provide identical services.
Replicable services can store the SCPs and other service-specific objects for multiple replicas in a single container. The setup program for the first replica can create the container as a child of the local domain's System container, as described in Publishing in a Domain's System Container. Make sure that the security descriptor on your container allows the setup programs for subsequent replicas to create their objects in the same container. You should enable the installing administrator to specify the users or groups who are allowed to create or modify objects in the container.
One strategy for a replicable service is to create an SCP for each replica. When a client queries for the service's product GUID or other identifying keyword, it finds the SCP objects for all replicas and selects one at random or using some load-balancing algorithm. For example, an administrator could specify priority and load-balancing information for each replica, similar to the priority and weight fields of a DNS SRV record. The service's setup program can store this information in the serviceBindingInformation attribute of each replica's SCP. Clients retrieve the information from each SCP and use it to select a replica.
Another strategy is to create a single SCP for all replicas and set the SCP serviceDNSName attribute to the name of a DNS SRV record. Then the setup program for each replica simply registers a SRV record with that name. When a client finds the service's lone SCP, the client retrieves the name of the SRV record and uses the DnsQuery function to retrieve the array of SRV records for the replicas. Each SRV record contains the name of a host computer and additional information that the client can use to select a replica.
Different instances of a database service may contain entirely different data, even though they are all the same kind of service (usually called service class). To publish this kind of service, the keywords attribute of the SCP can identify both the service class and the specific database. A general-purpose client that knows only the GUID of the service class can query for all databases published by that service class, and then present a user interface to allow the user to select one. For a client that's designed specifically for the target database, you can hard-code the database GUID into the client's code.
Host-based services are services that are closely tied to a single host computer. You can install instances of the service class on many computers and each instance provides services that are identified with its host computer.
Each instance of a host-based service should create it's own SCP under the computer object of its host. Clients who use a product GUID to search for the SCP of a host-based service will typically find many instances of the service class throughout the enterprise forest. Clients can then use the serviceDNSName attribute of the SCPs to find the SCP for the service instance on the desired host computer.