153021169001182127177100019128036004029190136140232051053062216123029245039111197220076128
Summary and Lessons Learned 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, including the following: -
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 reinstated by the manager, who is notified of the impending expiration. -
Associating entries with one another based on 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 happens if the layout of directory entries changes at some point? What if all the employee entries are 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 hcHrpRetailerID 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 a process of constant evolution and refinement. The Big Picture Overall, the HugeCo HRP extranet was an excellent first step into the world of extranet applications, and it expanded on the expertise developed when HugeCo designed and deployed its intranet directory service. The expertise developed should serve HugeCo well as it moves forward and leverages its directory to enable even more interesting extranet applications.
|
Understanding and Deploying LDAP Directory Services, 2002 New Riders Publishing | |
