📄 rfc2552.txt
字号:
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.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -