rfc2552.txt

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


RFC 2552                          GAIA                        April 1999


   Authentication FUM

   The Authentication FUM provides a mechanism that allows a user to
   prove his identity to the brokerage system.

   Payment FUM

   The Payment FUM provides a mechanism for payment from one actor to
   another.

4.  GAIA Brokerage System Interfaces

   This Chapter describes the internal and external interfaces of the
   GAIA brokerage system.

4.1.  Internal Interfaces

   The definition of communication between functional components within
   the GAIA Broker is based on the OMG CORBA model [2].  Interfaces
   between components are defined in the IDL language specified by OMG.
   Interface calls are passed between components by the Object Request
   Broker (ORB).

   The advantage of this approach is that the specifications of the
   interfaces are platform and programming language independent.  These
   interfaces can be implemented using different programming languages
   on different platforms.  All necessary conversions during interface
   invocations are transparently performed by an ORB.  The CORBA model
   also allows installing different functional components of the GAIA
   Broker on different computers connected by a network.  Interface
   calls will be transferred over the network by an ORB transparently
   for the application.

   The specification of the interfaces between the Kernel and FUMs and
   between each FUM and corresponding FUs is presented in the GAIA
   Standard [1].

4.2.  External protocols

   The GAIA Broker can use existing protocols to communicate with other
   actors.  For example, it can use HTTP for interactions with
   Customers, Z39.50 for search, etc.  As described in the GAIA
   Functional Architecture, support for particular technologies is
   provided by FUs.  A set of supported protocols can be extended by
   attaching the corresponding new FUs to a Broker.  The GAIA Broker can
   support several protocols for each action.  The FUMs will select the
   most appropriate protocol for a transaction.  The more protocols
   supported by the Broker, the better service it can provide to



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


   Customers and Suppliers.

   The GAIA Standard does not limit the set of protocols supported by
   the Broker.  However, for the purpose of interoperability, it
   specifies several GAIA profiles.  These profiles define a common
   subset of protocols (and a common range of protocol parameters) that
   Brokers are encouraged to support in order to make communication
   between GAIA Brokers, and with GAIA-aware Suppliers and Customers,
   possible.

   Existing protocols are not the only way to contact the GAIA Broker.
   The GAIA interfaces have been designed as a generalisation of
   existing interfaces and protocols, so they provide more functionality
   than any particular protocol.  To give access to the full
   functionality of the GAIA Broker, the GAIA Standard allows users
   (Customers and other Brokers) to directly use the CORBA-defined
   Customer interface of the GAIA Broker (interface between the Customer
   FUM and FUs) as shown in Figure 7.  In this case, the Customer system
   gets access to the Customer interface of the Broker using the service
   of an underlying ORB, and can request operations by calling the
   corresponding methods of the interface.  The Customer interface of
   the GAIA Broker is specified in the GAIA Standard [1].

   Where Customer and Supplier systems are not CORBA-aware, they can
   communicate with a GAIA Broker using existing protocols.  If,
   however, they can use the service of an ORB, they are encouraged to
   communicate with a Broker by connecting to its Customer interface.
   This method allows for avoiding convergence between a particular
   protocol and the GAIA interface.  The former method makes
   interactions with all existing types of Customers and Suppliers
   possible using existing and widespread protocols.  The later method
   has been designed to achieve maximum functionality by using native
   GAIA methods for communication with Customers and Suppliers.


















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


                              +----------------+
                              |Broker          |
                              |                |
                              |   --------     |
      +-----------+           |  [ Kernel ]    |
      |  Broker   |           |   --------     |
      |    or     |           |  [Customer]    |
      | Customer  |           |  [  FUM   ]    |
      |           |           |  ========== <-GAIA Customer
      |        *  |           |  *       *     | \interface
      | { O R B *}* * * * * * *{* O  R  B * }  |
      +-----------+    iiop   |            *   |         +----------+
                              |     (Customer) |         | Customer |
                              |     (   FU   ) |         |          |
                              +------------I---+         +----I-----+
                                            \      HTTP      /
                                             - - -      - - -

      Figure 7 External protocols and the GAIA Customer interface

5.  GAIA Standard Profiles

   The GAIA Standard defines a number of profiles, which a Broker may
   support in order to achieve interoperability with other GAIA actors
   (Customers, Suppliers and other Brokers).  The complexity of the
   profile chosen by a Broker depends on the level and type of service
   which the Broker wishes to deliver in a GAIA-conformant manner.  The
   higher the level of service that a Broker provides to a Customer, and
   the greater the length of the supply chain which the Broker wishes to
   support, the more advanced the profile and/or the greater the number
   of extension modules the Broker must support.

5.1.  Supply Chains

   The GAIA profile definition approach is based on the possible types
   of supply chain that a brokerage system can be a part of.

   The operations of a brokerage system can be broken into three
   categories:

   - interactions with the Customer
   - interactions with other Brokers
   - interactions with Suppliers

   The first and last of these occur at the two ends of a supply chain,
   while interbroker operations take place at other points in the chain.
   The supply chain may take a number of different forms:




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


   - a minimal chain, where the Customer and the Broker are the ends of
     the chain and there are no intervening links.  In this case, the
     Broker plays the role of Supplier to the Customer.

   - a three-piece chain, where the Broker deals with the Customer and
     the Supplier but not with any other Broker.

   - a longer chain, with one or more interbroker operations.

      Minimal Supply Chain:
          +--------+         +-------------+
          |Customer| <=====> | Broker      |
          +--------+         |(as Supplier)|
                             +-------------+
      3-piece Supply Chain:
          +--------+       +--------+       +--------+
          |Customer| <===> | Broker | <===> |Supplier|
          +--------+       +--------+       +--------+
      Longer Supply Chain:
          +--------+       +--------+   +--------+       +--------+
          |Customer| <===> | Broker |<=>| Broker | <===> |Supplier|
          +--------+       +--------+   +--------+       +--------+

      Figure 8 Supply Chains

5.1.1.  Minimal Supply Chains

   As discussed in the GAIA Reference Model, a GAIA transaction is
   composed of a number of actions, such as search, order, and delivery.
   Each transaction is initiated by the Customer who makes a request to
   the Broker.  In the event that the Broker is able to fulfil the
   request, the transaction involves no other actors.

   In this simple case, the GAIA transaction involves the Customer and
   the Broker.  The only protocol which needs to be standardised is that
   between the Customer and the Broker.  This is specified in the GAIA
   Standard Minimal profile below.

5.1.2.  Longer Supply Chains

   In the event that the Broker is not able to fulfil a request, the
   action may be propagated on to other Brokers, with the original
   Broker playing the Customer role.  Each of these Brokers may in turn
   propagate the request if they cannot fulfil it.

   Eventually, if the action is successful, a Supplier will be found who
   can fulfil the request.  The supply chain is thus made up a single
   Customer, one or more Suppliers, and one or more Brokers.



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


   In order to propagate an action from one Broker to another, a
   standardised communication protocol must be defined for broker-broker
   interaction.  This is specified in the Basic profile, below.  This
   profile is based on CORBA.

   Supplier and Brokers, however, are not obliged to support the Basic
   profile of the GAIA Standard.  They may instead use another, more
   traditional, protocol such as Z39.50 for discovery, or ISO ILL for
   ordering.  The Extension Modules to the GAIA Standard specify the
   profiles to be used for various brokerage functions.

5.2.  Introduction to the GAIA Standard Profiles and Modules

   The profiles specified are

   - The Minimal profile, which is the very least to which a GAIA Broker
     must conform
   - The Basic Profile, which allows inter-broker communication
   - A number of Extension Modules, which allow the Broker to provide
     various services, and to interoperate with Suppliers, Brokers and
     Customers using protocols specified in the modules
   - A set of Interface Modules, that defines which particular
     Functional Unit CORBA interfaces are supported by the Broker

   Each Broker must conform at least to the Minimal profile to provide a
   web-based user interface.  In addition, to take part in inter-broker
   communications, the Basic profile is recommended.  For interaction
   with non-CORBA-aware entities, and for the use of advanced services,
   there are other modules of the standard to which the Broker may
   conform.  These are denoted "Extension Modules", and they
   characterise the protocols and standards in a particular area of
   functionality.  A Broker can choose an appropriate set of Extension
   Modules to conform to according to the functionality it wishes to
   achieve.

   The GAIA Standard specifies all interfaces between FUM and FUs for
   the GAIA Broker.  However, it would be too much to require every
   Broker to implement all of them.  The GAIA Standard decomposes all
   interfaces into a number of Interface Modules.  A Broker can choose a
   subset of Interface Modules that are more important in its area of
   operation, and implement interfaces defined in these modules.  These
   interfaces are important only inside the broker system and do not
   play any role in communication with other GAIA actors.  However, a
   declaration of supported interfaces is important for the
   administrator to find the areas in which the functionality of the
   Broker can be extended by attaching GAIA-conformant FUs.





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


5.3.  Minimal Profile

   The minimum functionality that a Broker must support will allow it to
   provide services to the Customer as a part of a minimal chain.  In
   this case, what is required of the Broker is simply a user interface
   for the Customer.  Any further operations take place within the
   Broker, and so do not come within the scope of the standard.

   The Minimal profile requires the Broker to implement a user interface
   based on the HTTP 1.1 protocol, defined in RFC 2068 [3], and HTML
   2.0, defined in RFC 1866 [4].  It means that a Customer should be
   able to access the basic functionality of the GAIA Broker by using a
   HTTP 1.1 and HTML 2.0 conformant web-browser.

   It should be possible for Customers to locate a GAIA Broker.  Thus a
   GAIA Broker should be registered in a Directory Service using a
   schema specified in the GAIA Standard [1].

   +-------------------------------------------------+
   | Minimal Profile                                 |
   +------------------------+------------------------+
   | Customer               | HTTP 1.1 (server),     |
   |                        | HTML 2.0               |
   +------------------------+------------------------+

5.4.  Basic Profile

   While the minimal functionality is sufficient to allow a Broker to
   function, an important aspect of any GAIA Broker functionality is
   dealing with other Brokers.  The goal of the Basic profile is to
   achieve federation between Brokers.  Every GAIA Broker can use the
   service of other GAIA Brokers in order to fulfil a request of a
   Customer.  That Broker in turn can use the service of the third GAIA
   Broker.  So every request can be chained by several Brokers.  This
   extends the abilities of every GAIA action (Search, Locate, Order,
   etc.).  Chained transactions are particularly important in the
   discovery phase of a transaction, where a Broker unable to fulfil a
   particular information requirement passes on the search to another
   Broker.

   The Basic profile requires the Broker to implement the GAIA Customer
   interface defined in terms of CORBA.  This interface is described in
   more detail in Section 4.2 above.  The Basic profile also requires
   the Broker to implement interface requestor procedures, i.e. to be
   able to connect to the Customer interfaces of other Brokers.  The ORB
   used by the Broker should be conformant to the CORBA 2.0
   specification [2] and use IIOP protocol for inter-ORB communications
   [2].



Blinov, et al.                                                 [Page 18]