rfc2552.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Blinov, et al.                                                  [Page 6]

RFC 2552                          GAIA                        April 1999


   Security

   As part of any GAIA Action, it may be necessary to carry out some
   security operations, such as encryption of data, verification of
   source and content integrity of Product, or digital signature of some
   data entity or entities.  The particular security services and
   mechanisms which may be required, or the manner in which they may be
   provided, is outside the scope of this document.

3.  The GAIA Functional Architecture

3.1.  The Concept

   The GAIA Functional Architecture decomposes the overall functionality
   of the GAIA Broker into a number of components and describes the
   roles and relationships of these components, and the manner in which
   they interoperate.

   To work in a heterogeneous environment the GAIA Functional
   Architecture introduces three levels of abstract elements of the
   Broker: the Kernel, Functional Unit Managers (FUMs), and Functional
   Units (FUs) (see Figure 2).

       GAIA Broker:
       ------------
                      [  Kernel  ]                Kernel
                        /       \                 level
                       /         \
        [Functional Unit]     [Functional Unit]   Technology-independent
        [    Manager    ]     [    Manager    ]   action-dependent
             /    \                 /    \        level
            /      \               /      \
    [Functional][Functional] [Functional][Functional]  Technology
    [Unit      ][Unit      ] [Unit      ][Unit      ]  dependent
                                                       level
    Figure 2 Levels of the architecture

   Functional Units are the technology dependent parts of the
   architecture.  They perform required transactions in terms of a
   particular protocol.  All FUs are covered by a technology independent
   interface.  FUs are grouped according to the trading action they
   participate in, e.g. search FUs or locate FUs.  Each group of FUs is
   governed by the corresponding Functional Unit Manager.

   Functional Unit Managers contain technology independent functions for
   particular actions.  To use a particular technology an FUM uses the
   services of attached FUs.  There may be several FUs associated with
   an FUM, allowing the FUM to operate in different technology contexts.



Blinov, et al.                                                  [Page 7]

RFC 2552                          GAIA                        April 1999


   There is one FUM in the system for every area of functionality, e.g.
   search, locate, and order.  The Kernel is responsible for managing
   the activity of different FUMs (corresponding to different actions)
   and synchronising events between them.

   The GAIA Functional Architecture establishes relationships between
   the existing technologies (standards and protocols) that are combined
   in the GAIA Standard, in the context of a brokerage system.  It is to
   be expected that new technologies will evolve which will be viable
   alternatives to those selected.  The abstract and modular nature of
   the Functional Architecture allows the replacement of one technology
   with a new one without disruption to the rest of the brokerage
   system.

3.2.  Functional Units

   The brokerage system provides a number of services to its users.
   These services are supported by the functions of the brokerage
   system.  These include, for example,

   - searching
   - ordering
   - payment

   Each of these functions can be provided by a number of different
   candidate technologies.  However, the operations that are required to
   be carried out remain the same.  Regardless of the selected
   technologies, the functional requirements do not change.  The
   required operations are described in terms of abstract primitives,
   which can be mapped to the protocol instructions of the technology
   selected to support the function.  A mapping component, called a
   Functional Unit (FU), is defined for each candidate technology, and
   converts calls to abstract primitives into protocol instructions.
   The FU acts as an adaptor between its particular technology and the
   rest of the brokerage system.

   Functional Units are defined for each candidate technology that can
   be used to fulfil a particular functional need of the brokerage
   system.  A Functional Unit accepts abstract primitive invocations,
   and maps them to calls to the particular technology to which it is
   dedicated.  The results of these calls are translated into the
   corresponding abstract primitives and returned by the FU, as shown in
   Figure 3.








Blinov, et al.                                                  [Page 8]

RFC 2552                          GAIA                        April 1999


             * The rest of the Broker *
                    ^
                    |  -abstract primitives
                    v
                 +------------+
                 | Functional |
                 |    Unit    |
                 +------------+
                    ^
                    |  -technology-specific commands
                    v
             * Technology functions *

   Figure 3 GAIA Functional Unit

3.3.  Functional Unit Managers

   As noted above, a number of different candidate technologies can be
   used to fulfil a particular functional requirement of the brokerage
   system.  Depending on the details of the GAIA transaction (underlying
   network, Customer system capabilities, etc.), different technologies
   may be more useful during different transactions.  As a result, each
   candidate technology has its own Functional Unit, which is invoked
   when that particular technology is required.

   A number of different Functional Units can exist which fulfil the
   same functional requirement of the brokerage system.  To select the
   most appropriate FU (and technology), the brokerage system needs to
   know which is the most useful at any particular time; in general this
   is the technology supported by the target Supplier system.  This is
   the responsibility of the Functional Unit Manager, or FUM.  Each
   function of the brokerage system has a single FUM, which is invoked
   using abstract primitives by the Broker Kernel.  This FUM selects the
   most appropriate of the candidate technologies, and calls the
   corresponding FU (see Figure 4).

   The interface between the FUM and the corresponding FUs is defined
   for every FUM in an open, platform independent, and programming
   language independent manner.  These interfaces do not depend on any
   particular technology.  It allows for configuring the set of
   technologies supported by the Broker, by attaching different subsets
   of FUs.  If a new technology is to be supported by a Broker, a new FU
   implementing this technology can be created according to the
   specification of the interface, and attached to the corresponding
   FUM.






Blinov, et al.                                                  [Page 9]

RFC 2552                          GAIA                        April 1999


             +--------------------------------------+
             |       Functional Unit Manager        |
             +--------------------------------------+
                    ^                       ^
                    | -abstract primitives- |
                    v                       v
               +------------+        +------------+
               | Functional |        | Functional |
               |    Unit    |        |    Unit    |
               +------------+        +------------+
                ^                                ^
                | -technology-specific commands- |
                v                                v
              * Technology *          * Technology *
              * functions  *          * functions  *

   Figure 4 Functional Unit Manager

3.4.  The Kernel

   The Kernel of the brokerage system acts as a bus for the transmission
   of abstract primitives between FUMs.  Each FUM imports a set of
   abstract primitives representing those services which the FUM expects
   to receive from some other part of the system.  The services that the
   FUM is prepared to provide to other elements of the brokerage system
   are presented in the form of exported abstract primitives.  All these
   abstract primitives are imported from, and exported to, the Kernel
   (see Figure 5).

   The Kernel is also responsible for synchronisation of different
   actions within a transaction and for maintaining a common context
   between actions.

             +-------------------------------------+
             |           Broker Kernel             |
             +-------------------------------------+
                  ^            ^              ^
                  | -abstract- | -primitives- |
                  v            v              v
              +-------+     +-------+     +-------+
              |  FUM  |     |  FUM  |     |  FUM  |
              +-------+     +-------+     +-------+

   Figure 5 Broker Kernel







Blinov, et al.                                                 [Page 10]

RFC 2552                          GAIA                        April 1999


3.5.  Description of FUMs

   The core activities of the brokerage system include:

   1.  searching for Products that fit a user description
   2.  sourcing Products the identification of which is known
   3.  allowing users to order Products
   4.  delivering information in item format
   5.  delivering information as a continuous media stream
   6.  providing a user interface to the brokerage services
   7.  alerting users as to the availability of information
   8.  interacting with external directory services
   9.  authentication of other actors
   10.  payment operations

   Each of these activities is carried out by the corresponding FUM as
   described below and shown in Figure 6.

   Search FUM

   The Search FUM accepts requests to carry out a search for Products
   that fit a particular user description.  It returns lists of
   identifiers of Products that fit the description.

   Locate FUM

   The Locate FUM accepts Product identifiers and discovers where they
   may be obtained.  It returns lists of Suppliers and locations for the
   Product.

   Order FUM

   The Order FUM manages negotiations between a Customer and a Supplier
   in order that agreement may be reached on the terms of availability
   of a particular Product or group of Products.  Following the
   negotiation phase, the Order FUM accepts purchase commitments from
   the Customer and forwards them to the Supplier.  It returns a
   notification of the status of the Order Action.













Blinov, et al.                                                 [Page 11]

RFC 2552                          GAIA                        April 1999


                        The GAIA Broker:
                        ----------------
   (Customer))   (Alerting))  (  DS   ))  (Auth))  (Payment))
   (   FUs  ))   (   FUs  ))  (  FUs  ))  ( FUs))  (  FUs  ))
   (e.g.HTTP))   (e.g. SMS))  (eg LDAP))  (    ))  (e.g.SET))
       \/            \/           \/        \/        \/
   [Customer]     [Alerting]    [ DS  ]  [ Auth ]  [Payment]
   [  FUM   ]     [  FUM   ]    [ FUM ]  [  FUM ]  [  FUM  ]
       |              |            |         |         |
    +----------------------------------------------------------+
    |                  Broker Kernel                           |
    +----------------------------------------------------------+
       |             |            |            |            |
   [ Search ]    [ Locate ]    [ Order ]   [ Stream ]   [Discrete]
   [  FUM   ]    [  FUM   ]    [  FUM  ]   [Delivery]   [Delivery]
   [        ]    [        ]    [       ]   [  FUM   ]   [  FUM   ]
       /\            /\           /\           /\           /\
   ( Search  ))  ( Locate  ))  (  Order   ))  ( SD   ))  ( DD   ))
   (   FUs   ))  (   FUs   ))  (  FUs     ))  ( FUs  ))  ( FUs  ))
   (eg Z39.50))  (eg Z39.50))  (eg ISO ILL))  (eg RTP))  (eg FTP))

   Figure 6 GAIA Functional Architecture


   Discrete Delivery FUM

   The Discrete Delivery FUM manages the delivery of discrete items to
   the Customer.

   Stream Delivery FUM

   The Stream Delivery FUM manages the delivery of real-time multimedia
   data streams to the Customer.

   Customer FUM

   The Customer FUM provides an interface to support the Customer's
   systems interaction with the brokerage system.

   Alerting FUM

   The Alerting FUM notifies Customers about changes that may interest
   them.

   Directory Services FUM

   The Directory Services FUM provides an interface between an external
   directory service and the brokerage system.



Blinov, et al.                                                 [Page 12]