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