DESIGN AND IMPLEMENTATION OF TRANSACTIONAL X.500 DIRECTORY SERVICE

Abstract

X.500 Directory is a set of international standards produced by ISO and CCITT. The standards provide powerful global information look-up services. With the rapid expansion in electronic communications, there is a growing need for such a Directory and X.500 Directory is playing a significant role in open network communication. In recent years, a number of implementations and applications of the Directory with some non-standard extensions have been made to provide users a powerful service for information look-up. In the 1993 version of X.500, information can be replicated among several Directory Service Agents (DSAs). The standard provides a shadow mechanism for replicating Directory information. However, there is no time constraint to achieve consistency among the replicas. This is often not acceptable when the consistency of replicated information is detrimental to applications such as security system and network management system. In this study, a non-standard extension to X.500 is made to ensure the strong consistency among the relevant DSAs when Directory modification operations apply. This is accomplished by incorporating a Distributed Transaction Processing model to the X.500. This model provides all-or-none behavior to Directory modification operations. With the adoption of the general X/Open Distributed Transaction Processing model and the OMT object-oriented modeling methodology, four kinds of primary objects have been identified. These are transaction manager object, resource manager object, communication object and application object. The modeling begins with the transaction manager object. The transaction manager object is inserted in each DSA to control and coordinate the distributed transaction using the two-phase commit protocol. Next, the resource manager object which consists or database objects with a transactional API and the underlying DBM is implemented to ensure ACID properties for each DSA's local database. After that, Ros-objects as defined in X.500 are modeled as the application objects. These Ros-objects are mapped directly to the application processes and handle the major part of the Directory information processing activities. Lastly, each application association is modeled as a Single Association Object (SAO). Four kinds of SAOs have been identified, viz. DAP-SAO, DSP-SAO, DISP-SAO, and DOP-SAO. In order to track and transfer the atomic transaction messages, the DISP and DOP are enhanced by adding OSI-CCR ASE to their application context. These SAOs constitute the communication object. Based on the designed object model, the transactional X.500 Directory has been implemented using Borland C++ 1.0 on OS/2 Warp operation system running on Pentium PCs over an Ethernet network system. It is developed on top of the architecture of the entire ISO-OSI protocol suite (7 layers in all) which was built to meet both the criteria of modularity and efficiency. The implementation effort also involves porting the source code of the earlier project from 16-bit to 32-bit. After that, a thorough testing has been conducted to ensure the correct operations of the transaction facility which was incorporated in the X.500 system. The tradeoff of strong consistency will be the transaction processing time which will be longer than usual. To estimate the efficiency of the transactional X.500 Directory, a performance measurement has been carried out. By analyzing the measured data, the overhead of the transaction processing for commitment is estimated to be around 31% and the overhead of the transaction processing for roll back is estimated to be 13%. The bottleneck areas are primarily the database management system for local database access and the Directory Bind operations. The total response time rises linearly with the number or DSAs. The increase is greater for linear network than the star network. In conclusion, it is significant to incorporate the transaction capability to the X.500 Directory service in order to support the requirements or strong consistency. This feature will be particularly useful when • the underlying database manager can perform efficiently • the number of replicas is not very large • the star topology arrangement is adopted for the replicas • the communication is fast and reliable in the high speed network environment such as LAN or ATM