rfc2970.txt

RFC 的详细文档！

Network Working Group                                          L. Daigle
Request for Comments: 2970                                      T. Eklof
Category: Informational                                     October 2000


  Architecture for Integrated Directory Services - Result from TISDAG

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   A single, unified, global whitepages directory service remains
   elusive.  Nonetheless, there is increasing call for participation of
   widely-dispersed directory servers (i.e., across multiple
   organizations) in large-scale directory services.  These services
   range from national whitepages services, to multi-national indexes of
   WWW resources, and beyond.  Drawing from experiences with the TISDAG
   (Technical Infrastructure for Swedish Directory Access Gateways)
   ([TISDAG]) project, this document outlines an approach to providing
   the necessary infrastructure for integrating such widely-scattered
   servers into a single service, rather than attempting to mandate a
   single protocol and schema set for all participating servers to use.

1. Introduction

   The TISDAG project addressed the issue of providing centralized
   access to distributed information for whitepages information on a
   national scale.  The specification of the eventual system is
   presented in [TISDAG], and [DAGEXP] outlines some of the practical
   experience already gained in implementing a system of this scale and
   nature.  [DAG-Mesh] considers the issues and possibilities of
   networking multiple DAG services.  Following on from those, this
   document attempts to describe some of the architectural underpinnings
   of the system, and propose directions in which the approach can be
   generalized, within the bounds of applicability.








Daigle & Eklof               Informational                      [Page 1]

RFC 2970       Architecture for IDS - Result from TISDAG    October 2000


   The proposed architecture inserts a coordinated set of modules
   between the client access software and participating servers.  While
   the client software interacts with the service at a single entry
   point, the remaining modules are called upon (behind the scenes) to
   provide the necessary application support.  This may come in the form
   of modules that provide query proxying, schema translation, lookups,
   referrals, security infrastructure, etc.

   Part of this architecture is an "internal protocol" -- called the
   "DAG/IP" in the TISDAG project.  This document also outlines the
   perceived requirements for this protocol in the extended DAG.

2.0 Some terminology

   Terms used in this document are compliant with those set out in
   [ALVE]. For the purposes of this document, important distinctions and
   relationships are defined between applications, services, servers and
   systems.  These are defined as follows:

   Application:  this is meant in the general sense, as a solution to a
     particular (set of) user need(s).  That is, the definition is not
     tied to a particular piece of software (as in "application
     program").

     The definition of an application includes the type(s) of
     information to be exchanged, expected behavior, etc.  Thus, a
     whitepages (search) application may expect to receive a name as
     input to a query engine, and will return all information associated
     with the name.  By contrast, a specific security application might
     use the same input name to verify access controls.

   Service:  an operational system providing (controlled) access to
     fulfill a particular application's needs.

     One service may be changed by configuring location, access
     controls, etc.  Changing application means changing the service.

   Server:  a single component offering access through a dedicated
     protocol, without regard to a specific service (or services) it may
     be supporting in a given configuration. Typically programmed for a
     particular application.

   System:  a set of components with established interconnections.

     Thus, a service can be split between several servers.  A collection
     of services (independently, or interrelated through specified
     agreements) act as an implementation of an application.  A system
     is composed of one or more servers and services.



Daigle & Eklof               Informational                      [Page 2]

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                      [Page 3]

RFC 2970       Architecture for IDS - Result from TISDAG    October 2000


      D2. As the architecture was already modular and geared towards
          extensibility, it seemed important to keep in mind that the
          same (or a similar) system could be applied to other (non-
          white pages) applications.

      D3. There is an "inside" and an "outside" to the service --
          distinguishing between components that are accessible to the
          world at large and those that are open only to other
          components of the system.

      D4. Internally, there is a single protocol framework for all
          communications -- this facilitates service support functions
          (e.g., security of transmission), ensures distributability,
          and provides the base mechanism for allowing/ascertaining
          interoperability of components.

   The resulting system architecture featured modular component (types)
   to fulfill a small number of functional roles, interconnected by a
   generic query-response language.  The functional roles were defined
   as:

      CAPs -- "client access points" -- responsible for accepting and
      responding to incoming requests through programmed and configured
      behavior -- to translate the incoming query into some set of DAG-
      internal actions (queries) and dealing with the responses,
      filtering and recombining them in such a way as to fulfill the
      client request within the scope of the service.  In the TISDAG
      system, all CAPs are responsible for handling whitepages queries,
      but the CAPs are distinguished by the application protocol in
      which they will receive queries (e.g., LDAPv2, LDAPv3, HTTP, etc).
      To the client software, the TISDAG system appears as a server of
      that particular protocol.  In the more general case, CAPs may be
      configured to handle different aspects of a service (e.g.,
      authenticated vs.  non-authenticated access).  While the TISDAG
      CAPs all had a simple control structure, the more general case
      would also see CAPs drawing on different subsets of DAG (internal)
      servers in order to handle different query types.  (See the
      "Operator Service" example, in section 5.2 below).

      SAPs -- "service access points" -- responsible for proxying DAG-
      internal queries to specified services.  These are resources drawn
      upon by other components within the system.  Through programmed
      and configured behavior, they translate queries in the internal
      protocol into actions against (typically external) servers, taking
      care of any necessary overhead or differences in interaction
      style, and converting the responses back into the internal
      protocol.  In the TISDAG system, all SAPs are responsible for
      handling whitepages queries, but they are distinguished by the



Daigle & Eklof               Informational                      [Page 4]

RFC 2970       Architecture for IDS - Result from TISDAG    October 2000


      application protocol in which they will access remote services.
      Further distinctions could be made based on the (remote service's)
      schema mappings they handle, and other service differentiators.

      Internal Servers respond to queries in the internal protocol and
      provide specific types of information.  In the TISDAG system,
      there is one internal server which provides referral information
      in response to queries.

   Note that all these components are defined by the functional roles
   they play in the system, not the particular protocols they handle, or
   even the aspect of the service they are meant to support.  That is, a
   client access point is responsible for handling client traffic,
   whether its for searching, establishing security credentials, or some
   other task.

3.2 Some generalizations

   The Requirements and Design principles outlined above are not
   particular to a national whitepages service.  They are equally
   applicable in any application based on a query-response model, in
   services where multiple protocols need to be supported, and/or when
   the service requires specialized behavior "behind the scenes".  In
   the TISDAG project, this last was inherent in the way the service
   first looks for referrals, then makes queries as appropriate.  For
   protocols that don't handle the referral concept natively, the TISDAG
   system proxies the queries.

   Because of its particular application to query-response situations,
   the term "Directory Access Gateway", or "DAG" still fits as a label
   for this type of system architecture.

   Internet applications are evolving, and require more sophisticated
   features (e.g., security mechanisms, accounting mechanisms,
   integration of historical session data).  Continuing to develop a
   dedicated protocol per application type results in encumbered and
   unwieldy protocols, as each must implement coverage of all of these
   common aspects.  But creating a single multi-application protocol
   seems unlikely at best.  The implicit proposal here is that, rather
   than overloading protocols to support multiple aspects of a service,
   those aspects can be managed by breaking the service into multiple
   supporting components to carry out the specialized tasks of
   authentication, etc.








Daigle & Eklof               Informational                      [Page 5]

RFC 2970       Architecture for IDS - Result from TISDAG    October 2000


3.3 A Word on DAG/IP

   In the TISDAG project, the choice was made to use a single "internal
   protocol" (DAG/IP).  The particular protocol used is not relevant to
   the architecture, but the principle is important.  By selecting a
   single query-response transaction protocol, the needs of the
   particular application could be mapped onto it in terms of queries
   and data particular to the application.  This makes the internal
   communications more flexible for configuration to other environments
   (services, applications).

   It is common today to select an existing, widely deployed protocol
   for transferring commands and data between client and server -- e.g.,
   HTTP.  However, apart from any issues of the appropriateness (or
   inappropriateness) of extending HTTP to this use, the work would have
   remained to define all the transaction types and data types over that
   protocol -- the specification of the interaction semantics and
   syntax.

3.4 Perceived benefits

   Apart from the potential to divide and conquer service aspects, as
   described above, this approach has many perceived benefits:

      - For multi-protocol environments, it requires on the order of
        N+M inter-protocol mappings, not NxM.
      - distribution of development
      - distribution of operation
      - eventual possibilities of hooking together different
        systems (of different backgrounds)
      - separation of
              - architectural principles
              - implementation to a specific application
              - configuration for a given service

   It is not the goal to say that a standardized system architecture can
   be made so that single components can be built for all possible
   applications.  However, this approach in general permits the
   decoupling of access protocols from specific applications, and
   facilitates the integration of necessary infrastructure independently
   of access protocol (e.g., referrals, security, lookup services,
   distribution etc).









Daigle & Eklof               Informational                      [Page 6]