[要約] 要約: RFC 2552は、ACTSプロジェクトGAIAの情報仲介のためのアーキテクチャについての規格です。 目的: このRFCの目的は、GAIAプロジェクトにおける情報仲介のアーキテクチャを定義し、効果的な情報の共有と統合を実現することです。
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.
著作権（C）インターネット協会（1999）。全著作権所有。
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).
このメモはACTSプロジェクトGAIA（情報の可用性のための汎用アーキテクチャ）の一部として設計された情報仲介のためのドメインおよびサプライヤーの独立した汎用的なアーキテクチャを紹介します。
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
これは、顧客とコンテンツ供給業者との間の仲介事業体として働くことができる仲介システムの需要につながります。仲介システムは、取引プロセスの間に、顧客を支援し、顧客からの異質性と情報の配信を非表示にします。そのような仲介システムのドメインおよびサプライヤーの独立した汎用アーキテクチャの設計は、プロジェクトGAIA（情報の可用性のための汎用アーキテクチャ）の目的です。 GAIAは、研究と技術開発のためのEU ACTSプログラムから一部の資金を受け取りました。 GAIAの仲介システムは、顧客ができるようになります
- 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.
GAIAアーキテクチャの完全な仕様はGAIA標準[1]で入手可能です。 GAIA標準GAIA参照モデル、GAIA機能アーキテクチャ、GAIA標準プロファイル、及びGAIAインタフェースの仕様の記述を含みます。
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.
このメモはGAIA標準のテキスト全体を含めることを目的としませんが、この規格の基本的なアイデアやコンセプトを提示します。
The structure of this memo follows the structure of the GAIA Standard:
このメモの構造は、GAIAの標準の構造を、次のとおりです。
1. The GAIA Reference Model provides a common basis for the description and specification of brokerage systems, including the GAIA system.
1. GAIA参照モデルは、GAIAシステムを含む仲介システムの説明および仕様のための共通の基礎を提供します。
2. The GAIA Functional Architecture defines functional elements of the GAIA Broker, their roles and relationships.
2. GAIA機能アーキテクチャは、GAIAブローカーの機能要素、その役割との関係を定義します。
3. The GAIA Brokerage System Interfaces describes internal and external interfaces of the GAIA brokerage system.
3. GAIAブローカーシステムインターフェースはGAIA仲介システムの内部および外部インターフェースを記述する。
4. The GAIA Standard Profiles specifies mandatory and optional profiles to which brokerage systems may conform.
4. GAIA標準プロファイルは、仲介システムが適合性のある必須および任意のプロファイルを指定します。
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 components. Further work on standards and frameworks for individual components of the GAIA environment uses the model and terminology provided by the Reference Model.
情報の可用性のための汎用アーキテクチャ（GAIA）参照モデルは、発見発注、およびグローバル仲介分散型情報環境における物理的およびデジタル・オブジェクトおよびサービス（「製品」）を提供に関わる業務や俳優の概要を説明します。これは、GAIA環境の全体的なビューを提供し、それぞれの役割とその構成要素間の関係を示す図です。 GAIA環境の個々のコンポーネントのための基準や枠組みのさらなる作業がリファレンスモデルによって提供されるモデルと用語を使用しています。
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.
GAIA環境は、情報やサービスの発見、順序、および配信のための手続きをサポートするために結合されている俳優や関数の集まりです。俳優が開始と全体的なトランザクションを作るために結合されているアクションの実行を含む、手順に役割を果たしています。 GAIAアーキテクチャは、仲介検索の提供と実施のための標準化され、広く適用可能なフレームワークを提供し、大規模なネットワーク化環境でアプリケーションを検索します。
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.
GAIAモデルはGAIA俳優が演じることができる3つの主要な役割を検討します。これらは、顧客、ブローカーとサプライヤーです。これらの役割は、以下の図1に示されています。また、アクションでサポートする役割を果たしているアクティブなエンティティの更なるクラスを考えています。この後者のクラスはGAIA「ヘルパー」として知られており、例えば、認証及び支払いを含みます。俳優たちは、サプライチェーンの組織や個人です。すべてのGAIA俳優は、任意の時点で少なくとも一つの役割を果たしています。
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.
お客様の目的は、いくつかの製品に関するいくつかの製品や情報を得ることです。顧客役割は、一つ以上のGAIAアクションを要求することによりGAIAトランザクションを開始し、トランザクションの結果を受け取ります。ブローカーまたはサプライヤー：お客様は、他の2つの役割のいずれかを再生する俳優に対処することがあります。他のブローカーからの更なるサービスを要求しながら、これらの俳優たちは、それ自体が顧客の役割を果たしている可能性があります。
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 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.
ブローカーは顧客とサプライヤーに仲介サービスを提供しています。これは、製品、または製品に関する情報を提供するために、お客様からのリクエストに応答します。お客様へのブローカーの供給は、1つまたは複数のサプライヤー、および/またはブローカーに由来してもよい製品。ブローカーの主な役割は、異なるサプライヤーの数からコレクターや情報の丁合いとして機能するため、お客様はサプライヤーの多様に対処するための必要性をなくす、お客様にこの情報を提供することです。ブローカーはまた、利用可能な製品についての情報を配布、サプライヤーの代理として行動すると考えることができます。ブローカーの役割を果たしている俳優は、同時にお客様や他のブローカーへのサプライヤーの役割を果たしている可能性があります。別のブローカーまたはサプライヤーとの対話中ブローカーは顧客の役割を果たしている可能性があります。
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.
サプライヤーは、顧客に供給された製品の供給源です。サプライヤーは、それが供給できる製品に関する情報をブローカーを提供します。サプライヤーは、お客様への転送のためにお客様へ、またはブローカーに直接その製品を供給することができます。サプライヤーの役割を果たしている俳優はまた、ブローカーの役割を果たしている可能性があります。サプライヤーは、GAIAトランザクションの数を超えるブローカーと顧客の大多数を扱うことがあります。
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.
ヘルパーはGAIA取引における支持役割を果たしているアプリケーション層のエンティティです。ヘルパーは、サプライチェーンに必要ないくつかのサービスを提供するが、ブローカのコア機能外部。例としては、グローバルディレクトリサービス、決済サービス、または認証サービスが含まれます。
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.
支払ヘルパーは別で1つのアクターに支払いのための支持機構に関するものです。
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.
任意のGAIA取引では、一つ以上の顧客（通常は1）、一つ以上のブローカー、および1社のまたは複数のサプライヤーがあるでしょう。顧客が求める製品の説明は、ブローカーにお客様により提供されます。ブローカーは、製品の検索で、他のブローカーを含むことができます。製品のサプライヤーは、ブローカーによって発見された場合、この情報はお客様へのブローカーの応答に含まれています。アクションの過程で、一つ以上のヘルパーのサービス時にコールする必要があるかもしれません。
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:
各GAIAトランザクションは、1つまたは複数のアクションで構成されています。これらのアクションは、ブローカーまたはいくつかの操作を実行すると応答を返すためにサプライヤーに顧客によって要求されています。 4つのアクションが定義されています。
- Search - Locate - Order - Deliver
- 検索 - 検索します - ご注文 - お届け
These Actions are shown in Figure 1.
これらのアクションは、図1に示されています。
+--------+ . . +--------+ . . +-----------+
| |-- Search -->| |-- Search -->| |+
| | : : | | : : | ||
| |-- Locate -->| |-- Locate -->| ||
|Customer| : : | Broker | : : |Supplier(s)||
| |-- Order --->| |-- Order --->| ||
| | : : | | : : | ||
| |<- Deliver --| |<- Deliver --| ||
+--------+ : : +--------+ : : +-----------+|
: : : : +-----------+
Helpers Helpers
<Authentication> <Payment> <Security>
Figure 1 GAIA Roles and Actions
図1 GAIAの役割とアクション
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.
検索アクションは、お客様がその代表していくつかの情報を見つけるためにブローカーを要求したときに行われます。これを行うには、顧客は、それが必要とする製品のいくつかの説明とブローカーを提供します。この説明に基づき、ブローカーは顧客に代わって検索を行い、結果を返します。検索アクションの結果は、お客様により提供された記述に合致する製品を参照する一意の識別子のセットです。
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.
お客様は、いくつかの製品の場所とソースに関する情報とそれを提供するためにブローカーを要求したとき見つけてアクションが実行されます。ブローカーは、これを実行できるようにするには、お客様は検索行動の結果である可能性が製品の明確な識別を提供します。ブローカーは、製品のソースまたはソースについて顧客に情報を返します。これらのデータは、いくつかの特別な契約条件は、例えば、適用することができるので、この情報は、最終的と考えることができない等の送達の利用可能な方法、配信の時間、コスト、などの状況情報の条件を含みますお客様のいくつかのカテゴリの割引。ご利用規約の最終版は、注文アクションのネゴシエーションフェーズ中に確立されます。
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 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.
お客様がその代表して製品を得るためにブローカーに依頼する、またはお客様に直接製品を販売するサプライヤーに要求したときに注文のアクションが行われます。注文を有効にするには、お客様が探してアクションの結果である可能性がある製品のソース情報、とブローカー/サプライヤーが提供されます。注文アクションは（おそらく）ネゴシエーションフェーズと購入段階から構成されています。ネゴシエーションフェーズ中に顧客は、彼が購入を検討している製品（バッチ）の入手可能性の規約の最終版が含まれている引用を取得します。お客様がこれらの条件が満足見つけた場合、彼が購入にコミットします。ブローカーやサプライヤーがサプライヤーまたはブローカーの代表者と人間との対話のためのテレプレゼンスサービスをサポートしている場合あるいは、これらは、交渉中に使用することができます。
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.
このセクションで提示アクションが論理的に統合されたシーケンスを形成するために取ることができるが、これは必ずしもそうではありません。アクションではなく、4-アクション全体の一部としてよりも、独立して行われてもよいです。たとえば、アクションがGAIA検索以外の何らかのメカニズムを使用してお客様が取得した情報に基づいて発生し、アクションを見つけて注文して配信します。
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.
上記で概説したGAIAアクションのいずれかの間に、いくつかの支持活動を行うことが必要であってもよいです。これらの活動は、GAIAヘルパーイベントと呼ばれています。それらは、例えば、認証および支払いのために、含まれています。ヘルパーエンティティはGAIA俳優に、GAIAアクションへの追加サービスを、提供するために、GAIAイベントに関与しています。
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.
別のGAIA俳優の身元を確認するためには、認証交換は、場所を取る必要があるかもしれません。これは、GAIAのアクションのいずれかの間に発生する可能性があります。認証の方法または方法は、この文書の範囲外です。
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.
支払いはGAIAトランザクション中に場所を取ることが必要になることがあります。このような状況では、1人のGAIA俳優が一人の以上の他のGAIA俳優を支払います。支払方法や方法は、この文書の範囲外です。
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.
あらゆるGAIAアクションの一部として、そのようないくつかのデータエンティティまたはエンティティのデータの暗号化、製品のソースと内容の整合性の検証、またはデジタル署名など、いくつかのセキュリティ操作を、実行する必要があるかもしれません。特定のセキュリティサービスおよびメカニズム必要とされ得るか、またはそれらが提供される方法は、この文書の範囲外です。
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.
GAIA機能アーキテクチャは、コンポーネントの数にGAIAブローカーの全体的な機能を分解し、役割と、これらのコンポーネントの関係、それらが相互運用する方法を説明します。
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機能アーキテクチャは、ブローカーの抽象要素3つのレベルの紹介：カーネル、機能ユニットマネージャ（FUMs）、および機能ユニット（のFUを）（図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.
機能ユニットは、アーキテクチャの技術に依存する部分です。彼らは、特定のプロトコルの面で必要な取引を行います。すべてのFUは、技術に依存しないインタフェースによって覆われています。 FUは、例えば、彼らが参加し、取引のアクションに応じてグループ化されています検索のFUまたはのFUを探します。 FUの各グループは、対応する機能ユニットマネージャによって支配されています。
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.
機能ユニットマネージャは、特定のアクションのための技術の独立した関数が含まれています。特定の技術を使用するにはFUMは、添付のFUのサービスを使用しています。 FUMは異なる技術のコンテキストで動作できるように、FUMに関連するいくつかのFUがあるかもしれません。
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.
機能のすべての領域のためのシステム内の1つのFUMは、例えば、あります検索では、検索し、オーダー。カーネルは異なるFUMs（異なるアクションに相当）の活動を管理し、それらの間のイベントを同期させる責任があります。
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.
GAIA機能アーキテクチャは、仲介システムの文脈では、GAIA標準で組み合わせられる既存の技術（標準とプロトコル）の間の関係を確立します。これは、新しい技術は、選択したものに実行可能な代替される進化していくことが予想されます。機能アーキテクチャの抽象とモジュール性は仲介システムの残りの部分を中断せずに新しいものと一つの技術の交換を可能にします。
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.
これらの各関数は異なる候補技術の数によって提供することができます。しかし、実行することが必要とされる操作は同じまま。かかわらず、選択した技術の、機能要件は変更されません。必要な操作は、機能をサポートするために、選択された技術のプロトコル命令にマッピングすることができる抽象プリミティブの観点から説明されています。機能ユニット（FU）と呼ばれるマッピングコンポーネントは、各候補技術のために定義され、かつプロトコル命令に抽象プリミティブへの呼び出しに変換されます。 FUは、その特定の技術や仲介システムの残りの部分との間のアダプタとして機能します。
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.
機能ユニットが仲介システムの特定の機能の必要性を満たすために使用することができ、各候補技術のために定義されています。機能ユニットは、抽象プリミティブ呼び出しを受け入れ、そしてそれが専用されている特定の技術への呼び出しにマップします。これらの呼び出しの結果は、対応する抽象プリミティブに翻訳され、図3に示すように、FUによって返されます。
* The rest of the Broker *
^
| -abstract primitives
v
+------------+
| Functional |
| Unit |
+------------+
^
| -technology-specific commands
v
* Technology functions *
Figure 3 GAIA Functional Unit
図3 GAIA機能ユニット
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.
上述のように、異なる候補技術の数は、仲介システムの特定の機能要件を満たすために使用することができます。 GAIA取引（基盤となるネットワーク、顧客のシステム機能、など）の内容に応じて、異なる技術は、異なるトランザクションの間に、より有用である可能性があります。その結果、各候補技術は、特定の技術が必要とされたときに呼び出される独自の機能ユニットを、持っています。
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).
異なる機能ユニットの数は、仲介システムの同一の機能要件を満たすが存在することができます。最も適切FU（技術）を選択するには、仲介システムは、任意の特定の時間に最も有用であるかを知る必要があります。一般的に、これはターゲット・サプライヤ・システムでサポートされている技術です。これは、機能ユニットマネージャ、あるいはFUMの責任です。仲介システムの各機能は、ブローカカーネルによって抽象プリミティブを使用して起動される単一のFUMを有しています。このFUMは、候補技術の最も適切なを選択し、（図4参照）に対応するFUを呼び出します。
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.
FUMと対応のFUとの間のインターフェースは、すべてのオープンな、プラットフォームに依存しないでFUM、プログラミング言語に依存しない方法のために定義されています。これらのインタフェースは、任意の特定の技術に依存しません。それはのFUの異なるサブセットを取り付けることで、ブローカーでサポートされているテクノロジのセットを設定することができます。新技術は、ブローカーでサポートされている場合は、この技術を実装する新しいFUは、インターフェースの仕様に従って作成され、対応するFUMに取り付けることができます。
+--------------------------------------+
| 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
図4機能ユニットマネージャー
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).
仲介システムのカーネルはFUMs間の抽象プリミティブを伝送するためのバスとして機能します。各FUMはFUMは、システムの他の部分から受信することを期待するそれらのサービスを表す抽象プリミティブのセットをインポートします。 FUMは、仲介システムの他の要素に提供する用意があるサービスは、エクスポートされた抽象プリミティブの形で提示されています。これらのすべての抽象プリミティブはからインポート、およびに輸出され、カーネルは（図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
図5ブローカーカーネル
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
1.ユーザインターフェースを提供する連続メディアストリーム6として項目形式で5配信情報を情報配信製品4を注文することを可能にする。3.ユーザーに知られている識別れたユーザの説明2ソーシング製品に合う製品を検索します仲介サービス他の俳優の9認証10.支払業務の外部ディレクトリサービスとの相互作用情報8の利用可能性など7.警告するユーザー
Each of these activities is carried out by the corresponding FUM as described below and shown in Figure 6.
以下に記載し、図6に示すように、これらの活性の各々は、対応するFUMによって行われます。
Search FUM
検索SMOKE
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.
検索FUMは、特定のユーザーの記述に合う製品の検索を実行するための要求を受け入れます。それは説明に合う製品の識別子のリストを返します。
Locate FUM
FUMを探します
The Locate FUM accepts Product identifiers and discovers where they may be obtained. It returns lists of Suppliers and locations for the Product.
探してFUMは、彼らが取得することができる製品の識別子と発見を受け入れます。これは、製品のサプライヤーと場所のリストを返します。
Order FUM
オーダー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.
注文FUMは、契約は製品の特定の製品またはグループの可用性の条件に到達することができるようにするために、顧客とサプライヤー間の交渉を管理します。ネゴシエーションフェーズに続いて、注文FUMは、顧客からの購入契約を受け入れ、サプライヤーに転送します。これは、注文のアクションの状態の通知を返します。
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
図6 GAIA機能アーキテクチャ
Discrete Delivery FUM
離散配信FUM
The Discrete Delivery FUM manages the delivery of discrete items to the Customer.
離散配達FUMは、顧客への個別の項目の配信を管理します。
Stream Delivery FUM
ストリーム配信FUM
The Stream Delivery FUM manages the delivery of real-time multimedia data streams to the Customer.
ストリーム配信FUMは、顧客へのリアルタイムのマルチメディア・データ・ストリームの配信を管理します。
Customer FUM
カスタマーFUM
The Customer FUM provides an interface to support the Customer's systems interaction with the brokerage system.
カスタマーFUMは仲介システムをお客様のシステムとの対話をサポートするためのインタフェースを提供します。
Alerting FUM
アラートFUM
The Alerting FUM notifies Customers about changes that may interest them.
アラートFUMは彼らの関心も変更についてお客様に通知します。
Directory Services FUM
ディレクトリサービスFUM
The Directory Services FUM provides an interface between an external directory service and the brokerage system.
ディレクトリサービスFUMは、外部ディレクトリサービスと仲介システム間のインタフェースを提供します。
Authentication FUM
認証FUM
The Authentication FUM provides a mechanism that allows a user to prove his identity to the brokerage system.
認証FUMは、ユーザーが仲介システムへの彼の身元を証明することを可能にするメカニズムを提供します。
Payment FUM
支払FUM
The Payment FUM provides a mechanism for payment from one actor to another.
支払FUMは1人の俳優から他への支払いのためのメカニズムを提供します。
This Chapter describes the internal and external interfaces of the GAIA brokerage system.
この章では、GAIAの仲介システムの内部および外部インタフェースについて説明します。
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).
GAIA Broker内の機能構成要素との間の通信の定義は、OMG CORBAモデルに基づいている[2]。コンポーネント間のインタフェースは、OMGによって指定されたIDL言語で定義されています。インターフェースコールは、オブジェクト・リクエスト・ブローカー（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.
このアプローチの利点は、インターフェースの仕様は、プラットフォーム及びプログラミング言語独立であることです。これらのインタフェースは、異なるプラットフォーム上の異なるプログラミング言語を用いて実現することができます。インターフェース呼び出しの間、すべての必要な変換を透過ORBによって行われます。 CORBAモデルは、ネットワークで接続された別のコンピュータ上のGAIAブローカの異なる機能コンポーネントをインストールすることができます。インターフェース呼び出しは、アプリケーションに透過的にORBによって、ネットワーク上で転送されます。
The specification of the interfaces between the Kernel and FUMs and between each FUM and corresponding FUs is presented in the GAIA Standard [1].
カーネルとFUMs間及び各FUMと対応のFUの間のインターフェースの仕様はGAIA規格に提示されている[1]。
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
GAIA Brokerは他の俳優と通信するために既存のプロトコルを使用することができます。例えば、GAIA機能アーキテクチャに記載されているように、特定の技術のためのサポートがのFUによって提供されるなど、検索のために、顧客との相互作用のためにZ39.50をHTTPを使用することができます。サポートされるプロトコルのセットは、ブローカに対応する新規のFUを取り付けることによって拡張することができます。 GAIA Brokerは、各アクションのためのいくつかのプロトコルをサポートすることができます。 FUMsは、トランザクションのために最も適切なプロトコルを選択します。ブローカー、それが提供することができ、より良いサービスでサポートされている複数のプロトコル
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.
GAIA標準Brokerによってサポートされるプロトコルのセットを制限するものではありません。しかし、相互運用性のために、それはいくつかのGAIAプロファイルを指定します。これらのプロファイルは、ブローカーがGAIAブローカーとの間で通信を行うためにサポートすることが奨励されていることプロトコルの共通部分集合（及びプロトコルパラメータの共通の範囲）を定義し、GAIA対応サプライヤーや顧客と、可能。
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].
既存のプロトコルは、GAIAブローカーに連絡する唯一の方法ではありません。 GAIAインタフェースは、既存のインタフェースおよびプロトコルの一般化として設計されているので、彼らは、任意の特定のプロトコルよりも多くの機能を提供します。 GAIAブローカの全機能へのアクセスを与えるために、GAIAスタンダードは、図7に示すように、ユーザ（顧客及び他のブローカー）を直接GAIAブローカ（顧客FUMとのFUとの間のインタフェース）のCORBA定義の顧客インターフェースを使用することができこの場合には、顧客システムは、基礎となるORBのサービスを使用して、ブローカーの顧客インターフェースへのアクセスを取得し、インタフェースの対応するメソッドを呼び出すことにより、操作を要求することができます。 GAIAブローカーの顧客インターフェースをGAIA規格に規定されている[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.
顧客とサプライヤーのシステムはCORBA-認識していない場合、これらは既存のプロトコルを使用してGAIA Brokerと通信することができます。 、しかし、彼らはORBのサービスを利用できる場合は、それらがその顧客のインターフェースに接続することにより、ブローカーと通信することが奨励されています。この方法は、特定のプロトコルとGAIAインタフェースとの間の収束を回避することを可能にします。前者の方法は、既存および広範囲のプロトコルを使用可能、お客様の既存のすべての種類との相互作用を作ります。後者の方法は、顧客やサプライヤーとの通信のためのネイティブGAIAの方法を使用して最大の機能を実現するために設計されています。
+----------------+
|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
図7外部プロトコルとGAIA顧客インタフェース
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.
GAIAの標準は、ブローカは、他のGAIA俳優（顧客、サプライヤー、他のブローカー）との相互運用性を実現するためにサポートしてプロファイルの数を、定義されています。ブローカによって選択されたプロファイルの複雑さは、ブローカがGAIAに準拠した方法で配信することを希望するサービスのレベル及びタイプに依存します。ブローカがサポートすることを望むサプライチェーンの長ブローカーが顧客に提供するサービスのレベルが高いほど、より大きな、より多くのプロファイルを前進及び/又はより大きな拡張の数は、ブローカがサポートしなければならないモジュール。
The GAIA profile definition approach is based on the possible types of supply chain that a brokerage system can be a part of.
GAIAプロファイル定義のアプローチは、仲介システムがその一部であることができるサプライチェーンの可能なタイプに基づいています。
The operations of a brokerage system can be broken into three categories:
仲介システムの動作は、次の3つのカテゴリに分けることができます。
- 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:
interbroker操作がチェーン内の他の点で行われながら第一及びこれらの最後は、サプライチェーンの両端に発生します。サプライチェーンは、多数の異なる形態をとることができます。
- 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.
- 一つ以上のinterbroker操作で長いチェーン、。
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
図8サプライチェーン
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.
GAIAリファレンスモデルで説明したように、GAIAトランザクションは、そのような検索、注文、配送などのアクションの数で構成されています。各トランザクションは、ブローカーへの要求を行う顧客によって開始されます。ブローカーが要求を満たすことが可能である場合には、トランザクションは、他の俳優が含まれていません。
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.
このような単純なケースでは、GAIAトランザクションは、顧客とブローカーを必要とします。標準化される必要がある唯一のプロトコルは、その顧客とブローカーの間です。これは、以下GAIA標準最小プロファイルに指定されています。
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.
アクションが成功した場合、最終的に、サプライヤーは、要求を満たすことができる人見つけられるでしょう。サプライチェーンは、このように単一の顧客、一つ以上のサプライヤー、および1つのまたは複数のブローカーを作っています。
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.
別のブローカーからアクションを伝達するために、標準化された通信プロトコルは、ブローカー・ブローカとの相互作用のために定義されなければなりません。これは、以下に、基本的なプロファイルに指定されています。このプロファイルは、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.
サプライヤーとブローカーらは、しかし、GAIA標準の基本プロファイルをサポートする義務はありません。彼らは代わりに、このような順序付けのための発見のためのZ39.50、またはISO ILLなどの別の、より伝統的な、プロトコルを使用してもよいです。 GAIA規格の拡張モジュールは、様々な仲介機能のために使用されるプロファイルを指定します。
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
- 間ブローカー通信を可能にする基本プロファイル、 - - GAIA Brokerが従う必要のある最低限である最小プロファイル、ブローカは、様々なサービスを提供するために、サプライヤとの相互運用を可能にする拡張モジュールの数を、特定の機能ユニットCORBAインタフェースは、ブローカによってサポートされている定義インターフェイスモジュールのセット、 - ブローカー及びモジュールで指定されたプロトコルを使用しているお客様
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.
各ブローカは、Webベースのユーザインタフェースを提供するために、少なくとも最小限のプロファイルに準拠する必要があります。また、インターブローカー通信に参加するために、基本的なプロファイルが推奨されます。非CORBAを意識した事業体との相互作用のために、高度なサービスの利用のために、ブローカが準拠する可能性があるために、標準の他のモジュールがあります。これらは、「拡張モジュール」を付し、彼らは、機能の特定の領域にプロトコルと標準を特徴付けます。ブローカーは、それが実現したい機能に応じに準拠するように拡張モジュールの適切なセットを選択することができます。
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.
GAIA標準GAIA BrokerのFUMとのFUの間のすべてのインタフェースを指定します。しかし、それらのすべてを実装するために、すべてのブローカーを必要とするためにあまりにも多くのだろう。 GAIA標準インタフェースモジュールの数にすべてのインタフェースを分解する。ブローカーはその動作領域においてより重要であるインタフェースモジュールのサブセットを選択し、これらのモジュールで定義されたインターフェースを実装することができます。これらのインタフェースは、唯一のブローカーシステム内の重要であり、他のGAIA俳優と通信している任意の役割を果たしていません。管理者は、ブローカの機能はGAIA準拠のFUを取り付けることによって拡張することが可能な領域を見つけるために、しかしながら、サポートされているインターフェースの宣言が重要です。
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.
Brokerがサポートしなければならない最低限の機能は、それが最小限のチェーンの一部としてお客様にサービスを提供できるようになります。この場合、どのようなブローカーに求められているだけで顧客のためのユーザインタフェースです。任意の更なる操作は、ブローカー内で行われ、その標準の範囲内にありません。
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.
最小プロファイルは、RFC 2068で定義されたHTTP 1.1プロトコルに基づいてユーザインタフェースを実装するブローカが必要[3]、及びHTML 2.0、RFC 1866で定義された[4]。これは、お客様がHTTP 1.1とHTML 2.0準拠のWebブラウザを使用してGAIAブローカーの基本的な機能にアクセスできるようにする必要があることを意味します。
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].
お客様はGAIAブローカーを検索することが可能でなければなりません。したがってGAIA BrokerはGAIA標準[1]で指定されたスキーマを使用して、ディレクトリサービスに登録されなければなりません。
+-------------------------------------------------+
| Minimal Profile |
+------------------------+------------------------+
| Customer | HTTP 1.1 (server), |
| | HTML 2.0 |
+------------------------+------------------------+
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.
最小限の機能は、ブローカーを機能させるのに十分であるが、任意のGAIA Brokerの機能の重要な側面は、他のブローカーを扱っています。基本プロファイルの目標は、ブローカー間の連携を実現することです。すべてのGAIA Brokerは顧客の要求を満たすために他のGAIAブローカーのサービスを利用することができます。代わって、そのブローカーは、第三GAIAブローカーのサービスを利用することができます。だから、すべての要求は、いくつかのブローカーによって連鎖させることができます。これは、すべてのGAIAアクションの能力（検索は、探して、注文など）を拡張します。連鎖トランザクションは、要件が別のブローカーへの検索に渡し、特定の情報を満たすためにブローカができない取引の発見フェーズでは特に重要です。
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].
基本的なプロファイルは、CORBAで定義GAIA顧客インタフェースを実装するためにブローカーが必要です。このインタフェースは、上記セクション4.2でより詳細に説明します。基本的なプロファイルは、すなわち他のブローカーの顧客のインターフェースに接続できるように、インタフェースリクエスタ手順を実装するためにブローカーを必要とします。ブローカによって使用されるORBは、CORBA 2.0仕様に準拠すべきである[2]及びORB間の通信にIIOPプロトコルを使用する[2]。
A full specification of the GAIA Customer interface is presented in the GAIA Standard [1].
GAIA顧客インターフェースの完全な仕様はGAIA規格に提示されている[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.
GAIA Brokerは、他のブローカーやサプライヤーを見つけることができるはずです。また、他の参加者がそれを見つけることができるはずです。このようにGAIA Brokerは、ディレクトリサービスをサポートする必要があります。基本的なプロファイルは、この目的のためにディレクトリアクセスプロトコルを含んでいます。選択は、他のブローカーとブローカーの相互運用の成功に影響を与えないため、プロトコルの実際の選択は、標準化されていません。使用されるディレクトリスキーマは、GAIA規格に規定されています。
The Basic profile suggested for a Broker to allow it to interoperate with other GAIA Brokers is as follows.
次のようにブローカーのための提案の基本的なプロファイルは、それが他のGAIAブローカーと相互運用できるようにすることです。
+----------------------------------------------------------------+
| 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 |
+------------------------+---------------------------------------+
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.
、ブローカーは基本プロファイルをサポートしていない、とブローカーらは、CORBA-気づいていないサプライヤーや顧客に対処できるようにするだけでなく、ブローカーを介した項目とデータ・ストリームの配信を可能にするために、他のブローカーと相互運用できるようにするためには、他のオープンな技術を基本と最小のプロファイルへの拡張として提案されています。これらの技術は、プロジェクト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.
余分なプロトコルは拡張モジュールにグループ化されています。これらの拡張モジュールのサポートはオプションです。ブローカーは、それが実現したい機能に応じに準拠するように拡張モジュールの適切なセットを選択することができます。基本的な最小限のプロファイルによってカバーされていない機能領域ごとに1つの拡張モジュール、および既存の領域ごとに、一つの拡張モジュールがあります（お客様は、ディスカバリー、および受注は）GAIA以外のプロトコルの使用を許可します抽象プリミティブ。
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
- ディスカバリー拡張モジュール - 注文拡張モジュール - ディスクリート配達拡張モジュール - ストリーム配信拡張モジュール - セキュリティ拡張モジュール - 支払い拡張モジュール - カスタマーディスカバリー拡張モジュール - 拡張モジュールを警告
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:
[5]で定義されたように、この拡張モジュールは、Z39.50プロトコルのクライアント部分をサポートするためにブローカーが必要です。プロトコルの次のサブセットが必要です。
- Init, Search, and Present services - GRS-1 record syntax
- 初期化、検索、および現在サービス - GRS-1レコード構文
Z39.50 protocol PDUs should be carried using TCP/IP network protocols.
Z39.50プロトコルのPDUは、TCP / IPネットワークプロトコルを使用して行うべきです。
+-------------------------------------------------+
| Discovery Extension Module |
+------------------------+------------------------+
| Searching, | Z39.50 (client) |
| Locating | |
+------------------------+------------------------+
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.
この拡張モジュールは、ISO ILLプロトコル[6]のクライアント部分のすべての必須のサービスをサポートするためにブローカーが必要です。基本的な適合基準を厳守しなければなりません。 ISO ILLプロトコルのPDUは、TCP / IPネットワークプロトコルを使用して行うべきです。
+-------------------------------------------------+
| Order Extension Module |
+------------------------+------------------------+
| Order | ISO ILL (client) |
+------------------------+------------------------+
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
離散配信拡張モジュールは、お客様へのオンライン製品およびサービスの提供のために使用されるプロトコルと標準を指定します。みなさ2つの配信シナリオがあります。
- 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.
- サプライヤー・ブローカー・カスタマーの形のサプライチェーンにおける中央リンクであるブローカーのイベントに関与する1つのまたは複数のブローカーとのサプライチェーンの上に配信、Brokerは離散配信拡張モジュールで指定されたプロトコルに使用されますサプライヤーからの製品を受け取り、お客様に製品を提供します。
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.
離散配信拡張モジュールは、ブローカが受信すると、FTPを使用してファイルを送信できるようにするために、[7] FTPクライアントと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.
離散配信拡張モジュールも受け入れることと、電子メールメッセージを生成することができるようにGAIAブローカーが必要です。指定された電子メールプロトコルはSMTPプロトコルに基づいて、インターネット電子メールである[8]、RFC 822で指定されたメールデータフォーマット[9]。このプロトコルは、テキスト電子メールメッセージの作成、伝送、および管理のために十分です。しかし、様々な種類のデータファイルを送信するために、SMTP / RFC822プロトコルへの拡張が必要とされています。離散配信拡張モジュールにより指定されたメールの拡張子をMIME（多目的インターネットメール拡張）に基づいており、2045年から2049年のRFC [10]で定義されました。このようにGAIA Brokerは、「シンプル」SMTP / RFC822メールを送受信できるようにする必要があり、また、RFCで2045年から2049年MIMEメールの拡張子を扱うことができるように。
For electronic document delivery the Discrete Delivery Extension Module requires the support of GEDI version 3.0.
電子文書配信のための離散配達拡張モジュールは、GEDIバージョン3.0のサポートが必要です。
+--------------------------------------------------------+
| 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 |
+------------------------+-------------------------------+
This Extension Module is intended to support real-time delivery of multimedia by the GAIA Broker.
この拡張モジュールは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.
- 直接Brokerは、ストリーム配信プロセスに関与しない顧客へのサプライヤーから。このシナリオでは、この標準の範囲外です。
- 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.
- Brokerブローカーを介して顧客への供給業者からなど、キャッシュアルゴリズムを実装するストリームを混合、複数の顧客に一つのストリームを分岐することにより、ストリーム配信プロセスに値を追加することができ
- 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.
ストリーム配信拡張モジュールは、リアルタイムマルチメディア配信の最後の2つのシナリオを提供するために、ブローカーによって実装されることをお勧めします。
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.
- ISO / IEC 13818-3で指定された圧縮MPEG-2オーディオレイヤ3、[11]。制約されたパラメータストリーム（CSPS）の唯一のサポートが必要です。
- 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.
- RFC 1889で定義されたUDP / IP上のデータ転送プロトコルRTPプロトコル、[12]（クライアントとサーバー部分の両方）。 RTPアプリケーションサービスエンティティ（「翻訳者」または「ミキサー」）の完全な動作がサポートされていること、それが推奨されますが、必須ではありません。
- Mapping RTP payload format for MPEG Audio (MPA), defined in RFC 2250 [13].
- MPEGオーディオ（MPA）のマッピングRTPペイロードフォーマットは、RFC 2250 [13]で定義されます。
- Session control protocol RTCP, specified in RFC 1889 [12].
- セッション制御プロトコルRTCP、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 |
+--------------------------+-------------------------+
The basic security services required for GAIA are
GAIAのために必要な基本的なセキュリティサービスがあります
- 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).
- ネットワーク・トランザクションにおいて、ユーザーは、リモートサーバ（エンティティ認証等の両側ピアツーピア認証の両方）、送信者と受信者の認証、ならびに文書の認証。ユーザワークステーションでの認証グローバル、オープンネットワーク（インターネット）でセッションを開始し、ローカル環境（クライアント/サーバー認証）で認証し、認証：認証は3つの状況のために必要とされます。
- 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
- プライバシー、整合性、否認防止
SSL v3.0 protocol, defined in [14]. PKCS #7, defined in [15].
[14]で定義されたSSL V3.0プロトコル。 [15]で定義されたPKCS＃7、。
- Remote, client/server authentication GSS v5, specified in RFC 1508 [16].
- リモート、クライアント/サーバー認証RFC 1508で指定されたGSSのV5、[16]。
- Certification services PKIX certification protocol, specified in [17].
- [17]で指定された認証サービスPKIX認証プロトコル。
+-----------------------------------------------------------+
| Security Extension Module |
+--------------------------------------+--------------------+
| Privacy, integrity, non-repudiation | SSL v 3.0, PKCS #7 |
| Remote, client/server authentication | GSS v5 |
| Certification services | PKIX certification |
| | protocol |
+--------------------------------------+--------------------+
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.
このモジュールは、ブローカーは顧客、サプライヤー、およびその他のブローカーでの電子決済操作を実行することができます。このような操作は、検索の際に、GAIAトランザクション中にいずれかの段階で行われ、注文を見つけ、またはアクションを配信することができます。
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.
GAIA標準ブローカによって使用される料金表または充電モデルを指定していません。これは、内部の問題であると考えられています。法案が合意されたときしかし、支払いが安全かつ相互に受け入れ可能な方法で行われなければなりません。 GAIA標準で指定された支払い手続きがSET仕様を利用します。
The Payment Extension Module requires a Broker to support SET v1.0 merchant's server and SET certification protocol, specified in [18].
支払拡張モジュールは、[18]で指定SET v1.0の商人のサーバーおよびSET認証プロトコルをサポートするためにブローカーが必要です。
+----------------------------------------------------+
| Payment Extension Module |
+------------------------+---------------------------+
| Payment | SET v 1.0 : |
| | 1) CA server for banks |
| | 2) Cardholder wallet |
| | 3) Merchant Server |
| | 4) Payment Gateway server |
+------------------------+---------------------------+
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].
- RFC 822で指定されたSMTPプロトコル[8]、及びメールデータフォーマットに基づいて、インターネット電子メール、[9]。ブローカーは、生成し、電子メールメッセージを送信することができるはずです。 - [19]で指定されたSMS（ショートメッセージサービス）。
+-----------------------------------------------------+
| Alerting Extension Module |
+-----------+-----------------------------------------+
| Alerting | Internet e-mail [SMTP,RFC822] (sender), |
| | SMS |
+-----------+-----------------------------------------+
The Customer Discovery Extension Module allows Z39.50 clients to use the service of the GAIA Broker.
カスタマーディスカバリー拡張モジュールはZ39.50クライアントはGAIAブローカーのサービスを利用することができます。
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:
[5]で定義されるように、この拡張モジュールは、Z39.50プロトコルのサーバ部分をサポートするためにブローカーを必要とします。プロトコルの次のサブセットが必要です。
- Init, Search, and Present services - GRS-1 record syntax
- 初期化、検索、および現在サービス - GRS-1レコード構文
Z39.50 protocol PDUs should be carried using TCP/IP network protocols.
Z39.50プロトコルのPDUは、TCP / IPネットワークプロトコルを使用して行うべきです。
+----------------------------------------------------+
| Discovery Extension Module |
+------------------------+---------------------------+
| Searching, | Z39.50 (server) |
| Locating | |
+------------------------+---------------------------+
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
適合の目的のために、FUMsとのFUの間のすべてのインターフェイスは、GAIA規格で規定され、GAIAインタフェースモジュールにグループ化されます。これらのモジュールはGAIA Brokerによってサポートされることをお勧めしますが、それらは必須ではありませんされています。ブローカーはのサブセットを選択することができます
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].
機能ユニットインターフェイスの完全な仕様はGAIA規格に提示されている[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 |
+--------------------+------------------------------------+
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.
我々は非常に活発な議論とGAIA標準の設計プロセスにおける貴重な直接的および間接的な入力のためのGAIAコンソーシアムのすべてのメンバーに感謝の意を表したいです。
Security issues related to the electronic brokerage are discussed in Sections 2.1.4, 2.3 and 5.4.5.
電子証券会社に関連するセキュリティ問題はセクション2.1.4、2.3および5.4.5で議論されています。
[1] GAIA Consortium, Deliverable 0403, "GAIA Standard (Final)", December 1998, see also <http://www.syspace.co.uk/GAIA/>.
[1] GAIAコンソーシアム、成果物0403を、 "GAIA標準（最終）" は1998年12月、<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>.
[2]オブジェクト管理グループ、 "CORBA 2.0仕様"、1996年7月に、<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.
[3]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、RFC 2068、1997年1月。
[4] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995.
[4]バーナーズ - リー、T.およびD.コノリー、 "ハイパーテキストマークアップ言語 - 2.0"、RFC 1866、1995年11月。
[5] ANSI/NISO Z39.50-1995 or ISO 23950 "Information Retrieval: Application Service Definition and Protocol Specification".
[5] ANSI / NISO Z39.50-1995またはISO 23950 "情報検索：アプリケーション・サービスの定義およびプロトコル仕様"。
[6] ISO 10161:1997 "Information and documentation -- Open Systems Interconnection -- Interlibrary Loan Application Protocol Specification".
[6] ISO 10161：1997「情報とドキュメンテーション - 開放型システム間相互接続 - 相互貸借応用プロトコル仕様」。
[7] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[7]ポステル、J.、およびJ.レイノルズ、 "ファイル転送プロトコル"、STD 9、RFC 959、1985年10月。
[8] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[8]ポステル、J.、 "簡易メール転送プロトコル"、STD 10、RFC 821、1982年8月。
[9] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[9]クロッカー、D.、 "ARPAインターネットテキストメッセージの形式の規格"、STD 11、RFC 822、1982年8月。
[10] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[10]解放され、N.、およびN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
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.
ムーア、K.、「MIME（多目的インターネットメール拡張）パート3：非ASCIIテキストのためのメッセージヘッダの拡張」、RFC 2047、1996年11月。
Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996.
解放された、N.、Klensin、J.、およびJ.ポステル、 "多目的インターネットメール拡張（MIME）第四部：登録手順"、RFC 2048、1996年11月。
Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
解放された、N.、およびN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート5：適合基準と例"、RFC 2049、1996年11月。
[11] ISO/IEC IS 13818 "Information technology -- Coding of moving pictures and associated audio information"
[11] ISO / IEC 13818はIS「情報技術 - 動画の符号化および関連するオーディオ情報」
Part 1: Systems
Part 2: Video
Part 3: Audio
Part 4: Conformance testing
Part 5: Software simulation
[12] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[12] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 1889、1996年1月。
[13] Hoffman, D., Fernando, G., Goyal, V. and M. Civanlar, "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998.
[13]ホフマン、D.、フェルナンド、G.、Goyal氏、V.とM. Civanlar、 "MPEG1 / MPEG2ビデオのためのRTPペイロードフォーマット"、RFC 2250、1998年1月。
[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>.
[14]フライアー、A.、Karlton、P.およびP.コッヘル、 "SSLプロトコル - バージョン3.0"、進捗状況、トランスポート層セキュリティワーキンググループ、1996年11月での作業、参照してください。<http://home.netscape.com /eng/ssl3/index.html>。
[15] PKCS #7: Cryptographic Message Syntax Standard. Version 1.5, November 1993.
[15] PKCS＃7：暗号メッセージ構文標準。バージョン1.5、1993年11月。
[16] Linn, J., "Generic Security Service Application Program Interface", RFC 1508, Geer Zolot Associate, September 1993.
[16]リン、J.、 "ジェネリックセキュリティーサービス適用業務プログラムインタフェース"、RFC 1508、ギヤーZolotアソシエイト、1993年9月。
[17] Public-Key Infrastructure (X.509) IETF Working Group, <http://www.ietf.org/html.charters/pkix-charter.html>, July 98.
[17]公開鍵基盤（X.509）IETFワーキンググループ、<http://www.ietf.org/html.charters/pkix-charter.html>、7月98。
[18] "SET Secure Electronic Transaction Specification", Version 1.0, MasterCard and Visa, May 97.
[18]「安全な電子商取引の仕様を設定する」、バージョン1.0、マスターカードとビザ、月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.
[19]デジタルセルラー通信システム（フェーズ2+）：ショートメッセージサービス（SMS）の技術的実現ポイントツーポイント（PP）（GSM 3.40）。バージョン5.2.0。欧州電気通信標準化協会。 1996年5月。
Mikhail Blinov Computer Science Department University College Dublin Belfield, Dublin 4, Ireland
ミハイルBlinovコンピュータサイエンス学部ユニバーシティ・カレッジ・ダブリンベルフィールド、ダブリン4、アイルランド
Phone: +353 1-706-2488 Fax: +353 1-269-7262 EMail: mch@net-cs.ucd.ie
電話：+353 1-706-2488ファックス：+353 1-269-7262 Eメール：mch@net-cs.ucd.ie
Mikhail Bessonov Computer Science Department University College Dublin Belfield, Dublin 4, Ireland
ミハイルBessonovコンピュータサイエンス学部ユニバーシティ・カレッジ・ダブリンベルフィールド、ダブリン4、アイルランド
Phone: +353 1-706-2488 Fax: +353 1-269-7262 EMail: mikeb@net-cs.ucd.ie
電話：+353 1-706-2488ファックス：+353 1-269-7262 Eメール：mikeb@net-cs.ucd.ie
Ciaran Clissmann Computer Science Department University College Dublin Belfield, Dublin 4, Ireland
シアランClissmannコンピュータサイエンス学部ユニバーシティ・カレッジ・ダブリンベルフィールド、ダブリン4、アイルランド
Phone: +353 1-706-2488 Fax: +353 1-269-7262 EMail: ciaranc@net-cs.ucd.ie
電話：+353 1-706-2488ファックス：+353 1-269-7262 Eメール：ciaranc@net-cs.ucd.ie
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。