You are here: irt.org | RFCs | RFC2552 [ previous next ]
Network Working Group M. Blinov
Request for Comments: 2552 M. Bessonov
Category: Informational C. Clissmann
Teltec UCD-CS
Ireland
April 1999
Architecture for Information Brokerage
in the ACTS Project GAIA
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 (1999). All Rights Reserved.
Abstract
This memo introduces a domain and supplier independent generic
architecture for information brokerage, designed as part of the ACTS
project GAIA (Generic Architecture for Information Availability).
1. Introduction
Today a huge number of goods and services are offered on the
electronic market by a large, and ever-increasing, number of
suppliers. However, there is still no efficient way for a customer
to find a product or information, he/she is interested in and a
supplier that can provide that product. Customers and suppliers
already can not deal with the quantity of available information by
themselves. The high heterogeneity of existing protocols, formats,
and underlying networks also limits development of the electronic
market.
This results in a demand for brokerage systems that can work as
intermediary entities between customers and content suppliers.
Brokerage systems assist a customer during the trading process and
hide the heterogeneity and distribution of information from the
customer. The design of domain and supplier independent generic
architecture for such brokerage systems is an objective of the
project GAIA (Generic Architecture for Information Availability).
GAIA received part funding from the EU ACTS programme for Research
and Technological Development. The GAIA brokerage system allows a
customer to
Blinov, et al. [Page 1]
RFC 2552 GAIA April 1999 - search for a particular "product" (information, content or services) that he/she is interested in - locate the product, i.e. find supplier(s) from whom the product is available - order the product from the supplier - receive delivery of the product by digital means All these actions are carried out by the broker in response to requests from the customer. Broker services are accessible to the customer through the unified user interface. The customer system does not have to support all the protocols involved in the trading process. Full specification of the GAIA Architecture is available in the GAIA Standard [1]. The GAIA Standard includes a description of the GAIA Reference Model, GAIA Functional Architecture, GAIA Standard Profiles, and specification of the GAIA interfaces. This memo does not aim to include the whole text of the GAIA Standard, but to present the basic ideas and concepts of this standard. The structure of this memo follows the structure of the GAIA Standard: 1. The GAIA Reference Model provides a common basis for the description and specification of brokerage systems, including the GAIA system. 2. The GAIA Functional Architecture defines functional elements of the GAIA Broker, their roles and relationships. 3. The GAIA Brokerage System Interfaces describes internal and external interfaces of the GAIA brokerage system. 4. The GAIA Standard Profiles specifies mandatory and optional profiles to which brokerage systems may conform. 2. The GAIA Reference Model The Generic Architecture for Information Availability (GAIA) Reference Model outlines the operations and actors involved in finding, ordering, and delivering physical and digital objects and services ("Products") in a global brokered distributed information environment. It provides an overall view of the GAIA environment, and illustrates the respective roles of and relationships between its Blinov, et al. [Page 2]
RFC 2552 GAIA April 1999 components. Further work on standards and frameworks for individual components of the GAIA environment uses the model and terminology provided by the Reference Model. The GAIA environment is a collection of actors and functions that are combined to support a procedure for information and services discovery, order, and delivery. The actors play roles in the procedure, including initiation and execution of the Actions which are combined to make up the overall transaction. The GAIA architecture provides a standardised and widely applicable framework for the provision and implementation of the brokered search and retrieve applications in a large-scale networked environment. 2.1. GAIA Roles The GAIA model considers three principal roles that can be played by the GAIA actors. These are the Customer, the Broker and the Supplier. These Roles are shown in Figure 1 below. It also considers a further class of active entities who play supporting roles in the Actions. This latter class is known as GAIA "Helpers" and includes, for example, authentication and payment. The actors are organisations and individuals in the supply chain. Every GAIA actor plays at least one role at any given time. 2.1.1. The Customer The aim of the Customer is to obtain some Products or information about some Products. The Customer role initiates the GAIA transaction by requesting one or more GAIA Actions, and receives the results of the transaction. The Customer may deal with actors playing either of the other two roles: the Broker or the Supplier. These actors may themselves play the role of the Customer while requesting further services from other Brokers. 2.1.2. The Broker The Broker provides brokerage services to the Customer and the Supplier. It responds to requests from the Customer to provide Products, or information about Products. The Products that the Broker supplies to the Customer may originate from one or more Suppliers and/or Brokers. The Broker's primary role is to act as a collector and collator of information from a number of different Suppliers, and to supply this information to the Customer, thus obviating the need for the Customer to deal with a variety of Suppliers. A Broker can also be considered to act on behalf of a Supplier, distributing information about the Products available. The actor playing the role of the Broker may play the role of a Supplier Blinov, et al. [Page 3]
RFC 2552 GAIA April 1999 to a Customer or other Broker at the same time. The Broker may play the role of a Customer while interacting with another Broker or with a Supplier. 2.1.3. The Supplier The Supplier is the source of the Product supplied to the Customer. The Supplier provides the Broker with information about the Product that it can supply. The Supplier may supply its Product directly to the Customer, or to the Broker for forwarding to the Customer. An actor playing the role of a Supplier may also play the role of a Broker. A Supplier may deal with a large number of Brokers and Customers over a number of GAIA transactions. 2.1.4. Helpers A Helper is an application layer entity playing a supporting role in a GAIA transaction. Helpers provide some service needed in the supply chain, but outside the core functionality of the Broker. Examples include a global directory service, payment service, or authentication service. The authentication Helper is concerned with facilitating the authentication of one actor to another. The payment Helper is concerned with supporting a mechanism for payment to one actor by another. In any given GAIA transaction, there will be one or more Customers (usually one), one or more Brokers, and one or more Suppliers. A description of the Product sought by the Customer is provided by the Customer to the Broker. The Broker may involve other Brokers in the search for the Product. When a Supplier of the Product is discovered by the Broker, this information is included in the response of the Broker to the Customer. During the course of the Action, it may be necessary to call upon the services of one or more Helpers. 2.2. GAIA Actions Each GAIA transaction is made up of one or more Actions. These Actions are requests by the Customer to the Broker or the Supplier to carry out some operation and to return a response. Four Actions are defined: - Search - Locate - Order - Deliver Blinov, et al. [Page 4]
RFC 2552 GAIA April 1999 These Actions are shown in Figure 1. +--------+ . . +--------+ . . +-----------+ | |-- Search -->| |-- Search -->| |+ | | : : | | : : | || | |-- Locate -->| |-- Locate -->| || |Customer| : : | Broker | : : |Supplier(s)|| | |-- Order --->| |-- Order --->| || | | : : | | : : | || | |<- Deliver --| |<- Deliver --| || +--------+ : : +--------+ : : +-----------+| : : : : +-----------+ Helpers Helpers <Authentication> <Payment> <Security> Figure 1 GAIA Roles and Actions 2.2.1. Search The Search Action is carried out when the Customer asks the Broker to find some information on its behalf. To do this, the Customer provides the Broker with some description of the Product it requires. On the basis of this description, the Broker carries out a search on behalf of the Customer and returns the result. The result of a Search Action is a set of unique identifiers referencing the Products matching the description provided by the Customer. 2.2.2. Locate The Locate Action is carried out when the Customer asks the Broker to provide it with information regarding the location and source of some Product. To allow the Broker to do this, the Customer provides an unambiguous identification of the Product, which may be the result of a Search Action. The Broker returns information to the Customer about a source or sources for the Product. These data include the Terms of Availability information such as available methods of delivery, time of delivery, costs, etc. However, this information can not be considered final since some special terms and conditions may apply, e.g. discounts for some categories of Customers. The final version of the Terms of Availability is established during the negotiation phase of the Order Action. 2.2.3. Order The Order Action is carried out when the Customer asks the Broker to obtain a Product on its behalf, or asks the Supplier to sell the Product directly to the Customer. To enable an Order, the Customer provides the Broker/Supplier with Product source information, which Blinov, et al. [Page 5]
RFC 2552 GAIA April 1999 may be a result of a Locate Action. The Order Action consists of a negotiation phase and (possibly) a purchase phase. During the negotiation phase the Customer obtains the quotation that contains the final version of the Terms of Availability for the (batch of) Products he is considering purchasing. If the Customer finds these conditions satisfactory, he commits to the purchase. Alternatively, if the Broker or Supplier supports telepresence services for the human interaction with the Supplier or Broker representatives, these may be used during the negotiations. 2.2.4. Deliver The Deliver Action is carried out when the Broker provides the Customer with some requested Product. The Product may be information, some physical object, or metadata. The Deliver Action may be in response to an Order Action, a Search Action, or a Locate Action. While the Actions presented in this section may logically be taken to form an integrated sequence, this is not necessarily the case. Actions may take place independently, rather than as a part of a four-Action whole. For example, Order and Deliver Actions may occur on the basis of information obtained by the Customer using some other mechanism than GAIA Search and Locate Actions. 2.3. GAIA Helper Events During any of the GAIA Actions outlined above, it may be necessary to carry out some supporting activity. These activities are called GAIA Helper events. They include, for example, authentication and payment. The Helper entities are involved in the GAIA events to provide services, additional to the GAIA Actions, to the GAIA actors. Authentication In order to verify the identity of one GAIA actor to another, an authentication exchange may need to take place. This may occur during any of the GAIA Actions. The manner or method of authentication is outside the scope of this document. Payment It may be necessary for payment to take place during a GAIA transaction. In this situation, one GAIA actor pays one or more other GAIA actors. The manner or method of payment is outside the scope of this document. 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]
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]
RFC 2552 GAIA April 1999 A full specification of the GAIA Customer interface is presented in the GAIA Standard [1]. A GAIA Broker should be able to find other Brokers and Suppliers. It should also allow other participants to find it. Thus a GAIA Broker should support a directory service. The Basic profile includes a directory access protocol for this purpose. The actual choice of protocol is not standardised, because the choice does not influence the success of the Broker's inter-operation with other Brokers. The directory schema, which should be used, is specified in the GAIA Standard. The Basic profile suggested for a Broker to allow it to interoperate with other GAIA Brokers is as follows. +----------------------------------------------------------------+ | Basic Profile | +------------------------+---------------------------------------+ | Customer | GAIA Customer interface/IIOP (server) | | Search and Locate | GAIA Customer interface/IIOP (client) | | (Discovery) | | | Order | GAIA Customer interface/IIOP (client) | | Directory | Some directory access protocol, | | | such as LDAP | +------------------------+---------------------------------------+ 5.5. Extension Modules In order to allow Brokers to interoperate with other Brokers that do not support the Basic profile, and to allow Brokers to deal with Suppliers and Customers who are not CORBA-aware, as well as to allow delivery of items and data streams via the Broker, other open technologies are suggested as extensions to the Basic and Minimal profiles. These technologies reflect the results of the technology evaluation carried out as part of the project GAIA. The extra protocols are grouped into Extension Modules. Support of these Extension Modules is optional. A Broker can choose an appropriate set of Extension Modules to conform to according to the functionality it wishes to achieve. There is one Extension Module for each of the functional areas which are not covered by the Basic and Minimal Profiles, and also one Extension Module for each of the existing areas (Customer, Discovery, and Order) to allow the use of protocols other than GAIA abstract primitives. Blinov, et al. [Page 19]
RFC 2552 GAIA April 1999 The following Extension Modules are defined. - Discovery Extension Module - Order Extension Module - Discrete Delivery Extension Module - Stream Delivery Extension Module - Security Extension Module - Payment Extension Module - Alerting Extension Module - Customer Discovery Extension Module 5.5.1. Discovery Extension Module The Discovery Extension Module specifies the technologies to be used in searching for and locating products and services. This Extension Module requires the Broker to support the client part of the Z39.50 protocol, as defined in [5]. The following subset of the protocol is required: - Init, Search, and Present services - GRS-1 record syntax Z39.50 protocol PDUs should be carried using TCP/IP network protocols. +-------------------------------------------------+ | Discovery Extension Module | +------------------------+------------------------+ | Searching, | Z39.50 (client) | | Locating | | +------------------------+------------------------+ 5.5.2. Order Extension Module The Order Extension Module specifies the protocols to be used to order products and services from a Supplier. This Extension Module requires the Broker to support all mandatory services of the client part of the ISO ILL protocol [6]. Basic conformance criteria should be adhered to. ISO ILL protocol PDUs should be carried using TCP/IP network protocols. Blinov, et al. [Page 20]
RFC 2552 GAIA April 1999 +-------------------------------------------------+ | Order Extension Module | +------------------------+------------------------+ | Order | ISO ILL (client) | +------------------------+------------------------+ 5.5.3. Discrete Delivery Extension Module The Discrete Delivery Extension Module specifies the protocols and standards to be used for the delivery of on-line products and services to the Customer. There are two delivery scenarios considered - Direct Supplier to Customer delivery The delivery may be a single-step operation, with the Supplier supplying his product directly to the Customer without the involvement of any Broker in the delivery process. The Broker may have acted to refer the Customer to the Supplier. In this case, where the Broker is not involved in delivery, the Discrete Delivery Extension Module does not apply. - Delivery over a supply chain with one or more Brokers involved In the event of the Broker being the central link in a supply chain of the form of Supplier-Broker-Customer, the Broker will use the protocols specified in the Discrete Delivery Extension Module to receive the product from the Supplier, and to provide the product to the Customer. The Discrete Delivery Extension Module requires the Broker to provide both FTP client and FTP server functionality [7], to allow the Broker to receive and to transmit files using FTP. The Discrete Delivery Extension Module also requires the GAIA Broker to be able to accept and to generate e-mail messages. The e-mail protocol specified is Internet e-mail, based on the SMTP protocol [8] and mail data formats specified in RFC 822 [9]. This protocol is sufficient for the creation, transmission, and management of textual e-mail messages. However, for the transmission of data files of various types, extensions to the SMTP/RFC822 protocols are required. The mail extensions specified by the Discrete Delivery Extension Module are based on MIME (Multipurpose Internet Mail Extensions), defined in RFCs 2045-2049 [10]. Thus a GAIA Broker must be able to send and receive "simple" SMTP/RFC822 mail, and also be able to deal with RFC 2045-2049 MIME mail extensions. For electronic document delivery the Discrete Delivery Extension Module requires the support of GEDI version 3.0. Blinov, et al. [Page 21]
RFC 2552 GAIA April 1999 +--------------------------------------------------------+ | Discrete Delivery Extension Module | +------------------------+-------------------------------+ | FTP profile | FTP (client+server) | | Email profile | Internet e-mail [SMTP,RFC822] | | | (receiver+sender), | | | MIME | | Document delivery | GEDI version 3.0 | +------------------------+-------------------------------+ 5.5.4. Stream Delivery Extension Module This Extension Module is intended to support real-time delivery of multimedia by the GAIA Broker. Several scenarios of stream delivery are considered. A stream can be delivered - directly from a Supplier to a Customer The Broker does not take part in the stream delivery process; this scenario is out of scope of this standard. - from a Supplier to a Customer via a Broker The Broker can add value to the stream delivery process by implementing cache algorithms, mixing streams, branching one stream to several Customers, etc. - from a Broker to a Customer The Broker can keep a small amount of multimedia data (e.g. audio examples) in its own database and deliver it to a Customer upon request. The Stream Delivery Extension Module is recommended to be implemented by a Broker in order to provide the last two scenarios of real-time multimedia delivery. The Stream Delivery Extension Module requires the Broker to support the following technologies: - Compression MPEG-2 Audio Layer 3, specified in ISO/IEC 13818-3 [11]. Only support of constrained parameter streams (CSPS) is required. - Data transfer protocol RTP protocol over UDP/IP, defined in RFC 1889 [12] (both client and server parts). It is recommended that the full behaviour of an RTP application service entity ("translator" or "mixer") is supported but it is not required. Blinov, et al. [Page 22]
RFC 2552 GAIA April 1999 - Mapping RTP payload format for MPEG Audio (MPA), defined in RFC 2250 [13]. - Session control protocol RTCP, specified in RFC 1889 [12]. This profile provides delivery of high quality audio over networks with non-guaranteed quality of service such as the Internet. +----------------------------------------------------+ | Stream Delivery Extension Module | +--------------------------+-------------------------+ | Compression | MPEG-2 Audio Layer 3 | | Data transfer | RTP (client+server) | | Mapping | RFC 2250 | | Session control protocol | RTCP | +--------------------------+-------------------------+ 5.5.5. Security Extension Module The basic security services required for GAIA are - Authentication of users, remote servers (both as entity authentication and as bilateral peer-to-peer authentication), senders and receivers in network transactions, as well as the authentication of documents. Authentication is required for three situations: authentication at the user workstation when starting the session, authentication in a local environment (client/server authentication) and authentication in a global, open network (Internet). - Confidentiality and integrity of all resources transferred over the network or handled locally at application servers and user workstations. - Control of access to services and resources. - Non-repudiation of transactions, participants, and sensitive documents. This module allows a Broker to secure communications with other participants. It provides channel security, authentication, and certificate exchange. The Security Extension Module specifies the following protocols and algorithms: - Privacy, integrity, non-repudiation Blinov, et al. [Page 23]
RFC 2552 GAIA April 1999 SSL v3.0 protocol, defined in [14]. PKCS #7, defined in [15]. - Remote, client/server authentication GSS v5, specified in RFC 1508 [16]. - Certification services PKIX certification protocol, specified in [17]. +-----------------------------------------------------------+ | Security Extension Module | +--------------------------------------+--------------------+ | Privacy, integrity, non-repudiation | SSL v 3.0, PKCS #7 | | Remote, client/server authentication | GSS v5 | | Certification services | PKIX certification | | | protocol | +--------------------------------------+--------------------+ 5.5.6. Payment Extension Module This module allows a Broker to perform electronic payment operations with Customers, Suppliers, and other Brokers. Such operations may take place at any stage during a GAIA transaction, during a Search, Locate, Order, or Deliver Action. The GAIA Standard does not specify the tariffing or charging model to be used by a Broker; this is considered to be an internal matter. However, when a bill has been agreed, payment must take place in a secure and mutually acceptable manner. The payment procedure specified in the GAIA Standard makes use of the SET specification. The Payment Extension Module requires a Broker to support SET v1.0 merchant's server and SET certification protocol, specified in [18]. +----------------------------------------------------+ | Payment Extension Module | +------------------------+---------------------------+ | Payment | SET v 1.0 : | | | 1) CA server for banks | | | 2) Cardholder wallet | | | 3) Merchant Server | | | 4) Payment Gateway server | +------------------------+---------------------------+ Blinov, et al. [Page 24]
RFC 2552 GAIA April 1999 5.5.7. Alerting Extension Module The Alerting Extension Module specifies the protocols to notify Customers about changes that can be interesting for them. This Extension Module requires the support of the following technologies: - Internet e-mail, based on SMTP protocol [8], and mail data formats specified in RFC 822 [9]. The Broker should be able to generate and send e-mail messages. - SMS (Short Message Service), specified in [19]. +-----------------------------------------------------+ | Alerting Extension Module | +-----------+-----------------------------------------+ | Alerting | Internet e-mail [SMTP,RFC822] (sender), | | | SMS | +-----------+-----------------------------------------+ 5.5.8. Customer Discovery Extension Module The Customer Discovery Extension Module allows Z39.50 clients to use the service of the GAIA Broker. This Extension Module requires the Broker to support the server part of the Z39.50 protocol, as defined in [5]. The following subset of the protocol is required: - Init, Search, and Present services - GRS-1 record syntax Z39.50 protocol PDUs should be carried using TCP/IP network protocols. +----------------------------------------------------+ | Discovery Extension Module | +------------------------+---------------------------+ | Searching, | Z39.50 (server) | | Locating | | +------------------------+---------------------------+ 5.6. Interface Modules For the purpose of conformance, all interfaces between FUMs and FUs, specified by the GAIA Standard, are grouped into GAIA Interface Modules. These modules are recommended to be supported by a GAIA Broker, but they are not mandatory. A Broker can choose a subset of Blinov, et al. [Page 25]
RFC 2552 GAIA April 1999 Interface Modules that are more important in its area of operation, and implement interfaces defined in these modules. A full specification of the Functional Unit interfaces is presented in the GAIA Standard [1]. The following table defines Interface Modules and specifies which interfaces have to be supported in each of them. +--------------------+------------------------------------+ | Interface Module | Interfaces that are required to be | | | supported in this module | +--------------------+------------------------------------+ | Search | Search FU interface | | Locate | Locate FU interface | | Order | Order FU interface | | Discrete Delivery | Discrete Delivery FU interface | | Stream Delivery | Stream Delivery FU interface | | Customer | Customer FU interface | | Alerting | Alerting FU interface | | Directory Services | Directory Services FU interface | | Authentication | Authentication FU interface | | Payment | Payment FU interface | +--------------------+------------------------------------+ 6. Acknowledgement We wish to express our gratitude to all members of the GAIA Consortium for a very lively discussion and their valuable direct and indirect input in the design process of the GAIA Standard. 7. Security Considerations Security issues related to the electronic brokerage are discussed in Sections 2.1.4, 2.3 and 5.4.5. 8. References [1] GAIA Consortium, Deliverable 0403, "GAIA Standard (Final)", December 1998, see also <http://www.syspace.co.uk/GAIA/>. [2] Object Management Group, "CORBA 2.0 Specification", July 1996, See <ftp://ftp.omg.org/pub/docs/formal/97-02-25.pdf>. [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. Blinov, et al. [Page 26]
RFC 2552 GAIA April 1999 [4] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995. [5] ANSI/NISO Z39.50-1995 or ISO 23950 "Information Retrieval: Application Service Definition and Protocol Specification". [6] ISO 10161:1997 "Information and documentation -- Open Systems Interconnection -- Interlibrary Loan Application Protocol Specification". [7] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985. [8] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. [9] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [10] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996. Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996. [11] ISO/IEC IS 13818 "Information technology -- Coding of moving pictures and associated audio information" Part 1: Systems Part 2: Video Part 3: Audio Part 4: Conformance testing Part 5: Software simulation Blinov, et al. [Page 27]
RFC 2552 GAIA April 1999 [12] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [13] Hoffman, D., Fernando, G., Goyal, V. and M. Civanlar, "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998. [14] Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol - Version 3.0", Work in Progress, Transport Layer Security Working Group, November 1996, See <http://home.netscape.com/eng/ssl3/index.html>. [15] PKCS #7: Cryptographic Message Syntax Standard. Version 1.5, November 1993. [16] Linn, J., "Generic Security Service Application Program Interface", RFC 1508, Geer Zolot Associate, September 1993. [17] Public-Key Infrastructure (X.509) IETF Working Group, <http://www.ietf.org/html.charters/pkix-charter.html>, July 98. [18] "SET Secure Electronic Transaction Specification", Version 1.0, MasterCard and Visa, May 97. [19] Digital Cellular Telecommunications System (Phase 2+): Technical Realization of the Short Message Service (SMS) Point-to-Point (PP) (GSM 3.40). Version 5.2.0. European Telecommunications Standards Institute. May 1996. Blinov, et al. [Page 28]
RFC 2552 GAIA April 1999 9. Authors' Addresses Mikhail Blinov Computer Science Department University College Dublin Belfield, Dublin 4, Ireland Phone: +353 1-706-2488 Fax: +353 1-269-7262 EMail: mch@net-cs.ucd.ie Mikhail Bessonov Computer Science Department University College Dublin Belfield, Dublin 4, Ireland Phone: +353 1-706-2488 Fax: +353 1-269-7262 EMail: mikeb@net-cs.ucd.ie Ciaran Clissmann Computer Science Department University College Dublin Belfield, Dublin 4, Ireland Phone: +353 1-706-2488 Fax: +353 1-269-7262 EMail: ciaranc@net-cs.ucd.ie Blinov, et al. [Page 29]
RFC 2552 GAIA April 1999 10. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Blinov, et al. [Page 30]