RFC 2970 (rfc2970) - Page 3 of 18

Architecture for Integrated Directory Services - Result from TISDAG

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