| As with any complex process such as deploying a directory, there is always room for improvement. Here are a few words of advice based on lessons learned during the extranet directory deployment at HugeCo. During the design, pilot, and deployment phase, HugeCo developers chose to revisit several decisions they had made in response to the following situations: -
The original namespace design, in which all extranet application data was held within a single ou=Retailers subtree , would not have scaled well as additional types of extranet applications were added. Many additional container entries would have needed to be created at the dc=hugeco,dc=com level of the DIT to accommodate the applications. By placing an additional ou=Extranet container at this level, HugeCo's developers gained additional flexibility to arrange the extranet namespace in a more scalable fashion. -
The original server topology, which tied the extranet and intranet directory data together via referrals, had negative performance implications. The developers chose to keep the intranet and extranet directories separate for the time being because no applications needed to use both sets of directory data. This decision might be revisited in the future if intranet and extranet data needs to be shared between applications. -
Maintaining the quality of the retailer employee information was delegated to the managers at each authorized retailer, but there was initially no way for the manager to find out about stale directory data. A system was developed in which entries automatically expire unless they are reinstated by the manager, who is notified of the impending expiration. -
Associating entries with one another on the basis of location in the DIT proved to be troublesome . It is possible to locate the retailer entry for any given employee by moving up exactly two levels in the DIT. However, what would happen if the layout of directory entries changed? What if all the employee entries were moved beneath another container within the retailer subtree? Retailer entries would then be three levels above, instead of two. A better choice, implemented in the HugeCo HRP extranet, is to place an attribute in an employee's entry that associates it with a particular retailer. The hugeCoHrpRetailerID attribute serves this purpose and decouples the method of locating a retailer's entry from the DIT structure. As new extranet applications are designed and deployed, some of the design decisions will no doubt need to be revisited. The process of incrementally adding new directory-enabled extranet applications is constantly evolving and being refined. |
