RFC 2970 (rfc2970) - Page 3 of 18
Architecture for Integrated Directory Services - Result from TISDAG
Alternative Format: Original Text Document
RFC 2970 Architecture for IDS - Result from TISDAG October 2000 A "system architecture" identifies specific software components, their behavior, communication channels and messages needed to fulfill a particular service's needs. The TISDAG specification [TISDAG] includes just such a description, defining a software system that will meet the needs of a national whitepages directory service. Here, we outline some of the general principles which lead to that specific system architecture and discuss ways in which the principles can be applied in other contexts. Looking at this bigger picture, we present a "service architecture", or a framework for assembling components into systems that meet the needs of a wider variety of services. This is not a question of developing one or more new protocols for services, but rather to examine a useful framework of interoperating components. The goal is to reduce the overall number of (specialized) protocols that are developed requiring incorporation of some very general concepts that are common to all protocols. 3.0 TISDAG -- a first implementation, and some generalizations The Swedish TISDAG project (described in detail in [TISDAG], with some experiences reported in [DAGEXP]) was designed to fulfill the requirements of a particular national directory service. The experience of developing component-based system for providing a directory service through a uniform interface (client access point) provided valuable insight into the possibilities of extending the system architecture so that services with different base requirements can benefit from many of the same advantages. 3.1 Deconstructing the TISDAG architecture In retrospect, we can describe the TISDAG system architecture in terms of 3 key requirements and 4 basic design principles: R1. The service had to function with (several) existing client and server software for the white pages application. R2. It had to be possible to extend the service to accommodate new client and server protocols if and when they became relevant. R3. The service had to be easily reconfigurable -- to accommodate more machines (load-sharing), etc. D1. As a design principle, it was important to consider the possibility that queries and information templates (schema) other than the originally-defined set might eventually be supported. Daigle & Eklof Informational
