RFC2552 日本語訳
2552 Architecture for the Information Brokerage in the ACTS ProjectGAIA. M. Blinov, M. Bessonov, C. Clissmann. April 1999. (Format: TXT=65172 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Blinov
Request for Comments: 2552 M. Bessonov
Category: Informational C. Clissmann
Teltec UCD-CS
Ireland
April 1999
Blinovがコメントのために要求するワーキンググループM.をネットワークでつないでください: 2552年のM.Bessonovカテゴリ: 情報のC.Clissmann Teltec UCD-Csアイルランド1999年4月
Architecture for Information Brokerage
in the ACTS Project GAIA
行為プロジェクトGAIAの情報仲買人のための構造
Status of this Memo
この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.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
This memo introduces a domain and supplier independent generic architecture for information brokerage, designed as part of the ACTS project GAIA (Generic Architecture for Information Availability).
このメモは条例プロジェクトGAIA(情報Availabilityのための一般的なArchitecture)の一部として設計された情報仲買人でドメインと供給者の独立している一般的な構造を紹介します。
1. Introduction
1. 序論
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(情報Availabilityのための一般的なArchitecture)の目的です。 GAIAはResearchとTechnological DevelopmentのためにEU条例計画からの部分基金を受けました。 システムが顧客を許容するGAIA仲買業
Blinov, et al. [Page 1] RFC 2552 GAIA April 1999
Blinov、他 [1ページ]RFC2552GAIA1999年4月
- 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 Architectureの完全な仕様はGAIA Standard[1]で利用可能です。 GAIA StandardはGAIAインタフェースのGAIA Reference Model、GAIA Functional Architecture、GAIA Standard Profiles、および仕様の記述を含んでいます。
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 Standardの全文を含むように目的とするのではなく、この規格の基本的な考え方と概念を提示するために目的とされます。
The structure of this memo follows the structure of the GAIA Standard:
このメモの構造はGAIA Standardの構造に従います:
1. The GAIA Reference Model provides a common basis for the
description and specification of brokerage systems, including the
GAIA system.
1. GAIA Reference ModelはGAIAシステムを含む仲買業システムの記述と仕様の共有基準を提供します。
2. The GAIA Functional Architecture defines functional elements of
the GAIA Broker, their roles and relationships.
2. GAIA Functional ArchitectureはそれらのGAIA Brokerの機能要素、役割、および関係を定義します。
3. The GAIA Brokerage System Interfaces describes internal and
external interfaces of the GAIA brokerage system.
3. GAIA Brokerage System InterfacesはGAIA仲買業システムの内部の、そして、外部のインタフェースについて説明します。
4. The GAIA Standard Profiles specifies mandatory and optional
profiles to which brokerage systems may conform.
4. GAIA Standard Profilesは仲買業システムが一致するかもしれない義務的で任意のプロフィールを指定します。
2. The GAIA Reference Model
2. 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
情報Availability(GAIA)参照ModelのためのGeneric Architectureはグローバルな仲介された分散環境情報で物理的でデジタルの物とサービス(「製品」)を見つけて、注文して、届けるのにかかわる操作と俳優について概説します。 GAIA環境の全体図を提供して、それぞれの役割を例証する、間の関係、それ
Blinov, et al. [Page 2] RFC 2552 GAIA April 1999
Blinov、他 [2ページ]RFC2552GAIA1999年4月
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環境の個々のコンポーネントのための規格と枠組みに対するさらなる仕事はReference Modelによって提供されたモデルと用語を使用します。
The GAIA environment is a collection of actors and functions that are combined to support a procedure for information and services discovery, order, and delivery. The actors play roles in the procedure, including initiation and execution of the Actions which are combined to make up the overall transaction. The GAIA architecture provides a standardised and widely applicable framework for the provision and implementation of the brokered search and retrieve applications in a large-scale networked environment.
GAIA環境は、情報のために手順を支持するために結合される俳優と機能の収集と、サービス発見と、注文と、配送です。 俳優は手順における役割を果たします、総合的な取引を作るために結合されるActionsの開始と実行を含んでいて。 GAIA構造は標準化されて広く適切な枠組みを仲介された検索の支給と実現に提供します、そして、大規模なネットワークでつながれた環境におけるアプリケーションを検索してください。
2.1. GAIA Roles
2.1. 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つの主要な役割を考えます。 これらは、Customerと、BrokerとSupplierです。 これらのRolesは以下の図1で見せられます。 また、それはActionsで脇役をプレーするアクティブな実体のさらなるクラスを考えます。 この後者のクラスは、GAIA「アシスタント」として知られていて、例えば認証と支払いを含んでいます。 俳優は、サプライ・チェーンで機構と個人です。 すべてのGAIA俳優がその時々で1つの役割で最も最少に上演されます。
2.1.1. The Customer
2.1.1. 顧客
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.
Customerの目的はいくつかのProductsの何らかのProductsか情報を入手することです。 Customerの役割は、1GAIA Actionsを要求することによってGAIA取引を開始して、取引の結果を受けます。 Customerは他の2つの役割のどちらかをプレーしている俳優に対応するかもしれません: ブローカーか供給者。 これらの俳優がそうするかもしれない、自分たち、他のBrokersからさらなるサービスを要求している間、Customerの役割を果たしてください。
2.1.2. The Broker
2.1.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
BrokerはCustomerに対する仲買業サービスとSupplierを提供します。 それは、Productsに関してProducts、または情報を提供するためにCustomerから要求に応じます。 BrokerがCustomerに供給するProductsは1Suppliers、そして/または、Brokersから発するかもしれません。 Brokerの第一の役割は、多くの異なったSuppliersからの情報のコレクタと照合者として機能して、この情報をCustomerに供給することです、その結果、CustomerがさまざまなSuppliersに対処する必要性を取り除きます。 また、BrokerがSupplier、Productsに関する情報伝達を代表して利用可能に行動すると考えることができます。 Brokerの役割を果たしている俳優はSupplierの役割を果たすかもしれません。
Blinov, et al. [Page 3] RFC 2552 GAIA April 1999
Blinov、他 [3ページ]RFC2552GAIA1999年4月
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.
同時間のCustomerか他のBrokerに。 Brokerは別のBrokerかSupplierと共に相互作用している間、Customerの役割を果たすかもしれません。
2.1.3. The Supplier
2.1.3. 供給者
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.
SupplierはCustomerに供給されたProductの源です。 Supplierはそれが供給できるProductの情報をBrokerに提供します。 Supplierは直接Customer、または、BrokerへのProductをCustomerへの推進に供給するかもしれません。 また、Supplierの役割を果たしている俳優はBrokerの役割を果たすかもしれません。 Supplierは多くのGAIA取引の上で多くのBrokersとCustomersに対処するかもしれません。
2.1.4. Helpers
2.1.4. アシスタント
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.
HelperはGAIA取引で脇役を務める応用層実体です。 サプライ・チェーンで必要であるサービスをいくつかに提供しますが、アシスタントはBrokerに関する中心となる機能性を外部に提供します。 例はグローバルな電話番号案内、支払いサービス、または認証サービスを含んでいます。
The authentication Helper is concerned with facilitating the authentication of one actor to another.
認証Helperは別のものの1人の俳優の認証を容易にするのに関係があります。
The payment Helper is concerned with supporting a mechanism for payment to one actor by another.
別のものは支払いで1人の俳優にメカニズムをサポートするのに支払いHelperを関係があらせます。
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取引にも、1Customers(通常1)、1Brokers、および1Suppliersがあるでしょう。 Customerによって探されたProductの記述はCustomerによってBrokerに提供されます。 Brokerは他のBrokersにProductの検索にかかわるかもしれません。 ProductのSupplierがBrokerによって発見されるとき、この情報はCustomerへのBrokerの応答に含まれています。 Actionのコースの間、1Helpersのサービスを訪問するのが必要であるかもしれません。
2.2. GAIA Actions
2.2. GAIA動作
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取引は1Actionsで作られます。 これらのActionsはBrokerかSupplierへのCustomerによる何らかの操作を行って、応答を返すという要求です。 4Actionsが定義されます:
- Search - Locate - Order - Deliver
- 探してください--、場所を見つける、--注文してください--配送してください
Blinov, et al. [Page 4] RFC 2552 GAIA April 1999
Blinov、他 [4ページ]RFC2552GAIA1999年4月
These Actions are shown in Figure 1.
これらのActionsは図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の役割と動作
2.2.1. Search
2.2.1. 検索
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.
Customerが、そのに代わって何らかの情報を見つけるようにBrokerに頼むとき、検索Actionが行われます。 これをするために、Customerはそれが必要とするProductの何らかの記述をBrokerに提供します。 この記述に基づいて、BrokerはCustomerを代表して検索を行って、結果を返します。 検索Actionの結果はCustomerによって提供された記述に合っているProductsに参照をつける1セットのユニークな識別子です。
2.2.2. Locate
2.2.2. 場所を見つけます。
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.
Customerが、いくらかのProductの位置と源の情報をそれに提供するようにBrokerに頼むとき、Locate Actionが行われます。 Brokerがこれをするのを許容するために、CustomerはProductの明確な同定を提供します。(Productは検索Actionの結果であるかもしれません)。 BrokerはProductのためにソースかソースに関して情報をCustomerに返します。 これらのデータはAvailability情報の配送の利用可能な方法、納期、コストなどのTermsを含んでいます。 しかしながら、何らかの特別な条件が適用されるかもしれないので、最終的であるとこの情報を考えることができません、例えば、Customersのいくつかのカテゴリのための割り引き。 AvailabilityのTermsの最終版はOrder Actionの交渉段階の間、確立されます。
2.2.3. Order
2.2.3. オーダー
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
Customerが、そのに代わってProductを入手するようにBrokerに頼むか、または直接CustomerにProductを販売するようにSupplierに頼むとき、Order Actionが行われます。 Orderを有効にするために、CustomerがProductソース情報をBroker/供給者に提供する、どれ
Blinov, et al. [Page 5] RFC 2552 GAIA April 1999
Blinov、他 [5ページ]RFC2552GAIA1999年4月
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.
Locate Actionの結果はそうです。 Order Actionは交渉フェーズと(ことによると)購買フェーズから成ります。 CustomerがAvailabilityのTermsの最終版を含む見積りを得る交渉フェーズ、(バッチ、)、彼が購入していると考えている製品。 Customerが、これらの状態が満足できるのがわかるなら、彼は購買に公約します。 あるいはまた、BrokerかSupplierがSupplierかBroker代表との人間の交流のためのテレプレゼンスサービスを支持するなら、これらは交渉の間、使用されるかもしれません。
2.2.4. Deliver
2.2.4. 配送してください。
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.
Brokerがいくらかの要求されたProductをCustomerに提供するとき、Deliver Actionが行われます。 Productは何らかの情報、対象物、またはメタデータであるかもしれません。 Deliver ActionはOrder Action、検索Action、または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.
統合系列を形成するためにこのセクションに示されたActionsを論理的に取るかもしれませんが、これは必ずそうであるというわけではありません。 動作はむしろ4動作の全体の一部より独自に行われるかもしれません。 例えば、OrderとDeliver ActionsはGAIA検索とLocate Actionsよりある他のメカニズムを使用することでCustomerによって得られた情報に基づいて起こるかもしれません。
2.3. GAIA Helper Events
2.3. 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 Actionsのいずれの間も、いくつかを行うのが、活動を支持しながら、必要であるかもしれません。 これらの活動はGAIA Helper出来事と呼ばれます。 彼らは例えば認証と支払いを含んでいます。 Helper実体はサービスを提供するためにGAIA出来事にかかわります、GAIA Actionsに追加しています、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.
別のものの1人のGAIA俳優のアイデンティティについて確かめるために、認証交換は、行われる必要があるかもしれません。 これはGAIA Actionsのいずれの間も、起こるかもしれません。 このドキュメントの範囲の外に認証の方法か方法があります。
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俳優が他の1人以上のGAIA俳優に支払います。 このドキュメントの範囲の外に方法か支払方法があります。
Blinov, et al. [Page 6] RFC 2552 GAIA April 1999
Blinov、他 [6ページ]RFC2552GAIA1999年4月
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 Actionの一部としても、いくつかのセキュリティ操作を行うのが必要であるかもしれません、データの暗号化やソースの検証やProductの満足している保全や、いくつかのデータ実体か実体のデジタル署名などのように。 このドキュメントの範囲の外に特定のセキュリティー・サービスと必要であるかもしれないメカニズムか、それらが提供されるかもしれない方法があります。
3. The GAIA Functional Architecture
3. GAIA機能的な建築
3.1. The Concept
3.1. 概念
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 Functional ArchitectureはGAIA Brokerの総合的な機能性を多くのコンポーネントに分解して、これらのコンポーネントの役割と関係、および彼らが共同利用する方法を説明します。
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 Functional Architectureを扱うのは3つのレベルのBrokerの抽象的な要素を紹介します: カーネル、機能的なユニットマネージャ(FUMs)、および機能的なユニット(FUs)(図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
GAIAは以下を仲介します。 ------------ 図2 構造の[カーネル]カーネル/\レベル/\[機能的なUnit][機能的なUnit]技術から独立している[マネージャ][マネージャ]動作依存する/\/\レベル/\/\[機能的][機能的な][機能的な][機能的な]の技術[ユニット][ユニット][ユニット][ユニット]依存するレベルLevels
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.
機能的なUnitsは構造の技術に依存する部分です。 彼らは特定のプロトコルで必要な取引を実行します。 すべてのFUsが技術インディペンデント・インタフェースで覆われています。 FUsは彼らが参加する取り引き動作、例えば、検索FUsによると、分類されるか、またはFUsの場所を見つけます。 FUsの各グループは対応するFunctional Unitマネージャによって支配されます。
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.
機能的なUnitマネージャは特定の動作のための技術の独立している機能を含みます。 特定の技術を使用するために、FUMは付属FUsのサービスを利用します。 FUMが異なった技術文脈で作動するのを許容して、FUMに関連している数個のFUsがあるかもしれません。
Blinov, et al. [Page 7] RFC 2552 GAIA April 1999
Blinov、他 [7ページ]RFC2552GAIA1999年4月
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.
1FUMが例えば機能性のあらゆる領域のシステムにそこに、あります。捜して、場所を見つけて、命令します。 Kernelはそれらの間の異なった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 Functional ArchitectureはGAIA Standardで結合される既存の技術(規格とプロトコル)の間の関係を確立します、仲買業システムの文脈で。 選択されたものへの実行可能な代案になる新技術が発展すると予想されることになっています。 Functional Architectureの抽象的でモジュールの自然は仲買業システムの残りの分裂なしで新しいものとの1つの技術の交換を許します。
3.2. Functional Units
3.2. 機能的なユニット
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 Unit(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.
機能的なUnitsは仲買業システムの特別の機能的な必要性を充足するのに使用できる各候補者技術のために定義されます。 Functional Unitはそれがひたむきである特定の技術への呼び出しに抽象的な原始の実施を受け入れて、それらを写像します。 これらの呼び出しの結果は、対応する抽象的な基関数に翻訳されて、FUによって返されます、図3に示されるように。
Blinov, et al. [Page 8] RFC 2552 GAIA April 1999
Blinov、他 [8ページ]RFC2552GAIA1999年4月
* The rest of the Broker *
^
| -abstract primitives
v
+------------+
| Functional |
| Unit |
+------------+
^
| -technology-specific commands
v
* Technology functions *
* The rest of the Broker * ^ | -抽象的な基関数対+------------+ | 機能的| | ユニット| +------------+ ^ | -技術特有のコマンド対*技術機能*
Figure 3 GAIA Functional Unit
図3 GAIAの機能的なユニット
3.3. Functional Unit Managers
3.3. 機能的なユニットマネージャ
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取引(基本的なネットワーク、Customerシステム能力など)の詳細によって、異なった技術は異なった取引の間、より役に立つかもしれません。 その結果、各候補者技術にはそれ自身のFunctional Unitがあります。(その特定の技術が必要であるときに、Functional Unitは呼び出されます)。
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).
仲買業システムに関する同じ機能条件書を充足する多くの異なったFunctional Unitsが存在できます。 最も適切なFU(そして、技術)を選択するために、仲買業システムは、どれが特定の何時でも最も役に立つかを知る必要があります。 一般に、これは目標Supplierシステムによって支持された技術です。 これはFunctional Unitマネージャ、またはFUMの責任です。 仲買業システムの各機能には独身のFUMがあります。(FUMは、Broker Kernelで抽象的な基関数を使用することで呼び出されます)。 このFUMは候補技術における最も好個を選択して、対応するFUを呼びます(図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.
FUMと対応するFUsとのインタフェースは開いているプラットホーム独立者、およびプログラミング言語の独立している方法によるあらゆるFUMのために定義されます。 これらのインタフェースはどんな特定の技術にもよりません。 それは、Broker、FUsの付けの異なった部分集合によって支持された技術のセットを構成すると考慮します。 新技術がBrokerによって支持されることであるなら、この技術を実行する新しいFUはインタフェースの仕様通りに作成して、対応するFUMに取り付けることができます。
Blinov, et al. [Page 9] RFC 2552 GAIA April 1999
Blinov、他 [9ページ]RFC2552GAIA1999年4月
+--------------------------------------+
| Functional Unit Manager |
+--------------------------------------+
^ ^
| -abstract primitives- |
v v
+------------+ +------------+
| Functional | | Functional |
| Unit | | Unit |
+------------+ +------------+
^ ^
| -technology-specific commands- |
v v
* Technology * * Technology *
* functions * * functions *
+--------------------------------------+ | 機能的なユニットマネージャ| +--------------------------------------+ ^ ^ | -要約基関数| v対+------------+ +------------+ | 機能的| | 機能的| | ユニット| | ユニット| +------------+ +------------+ ^ ^ | -技術特有のコマンド| v*技術**技術**機能**機能*に対して
Figure 4 Functional Unit Manager
図4 機能的なユニットマネージャ
3.4. The Kernel
3.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).
仲買業システムのKernelはFUMsの間の抽象的な基関数の伝達のためのバスとして機能します。各FUMはFUMがシステムのある他の部分から受けると予想するそれらのサービスを表す1セットの抽象的な基関数を輸入します。 FUMが仲買業システムの他の原理に提供するように準備されるサービスは輸出された抽象的な基関数の形に提示されます。 Kernelはこれらのすべての抽象的な基関数に輸入されて、輸出されました(図5を見てください)。
The Kernel is also responsible for synchronisation of different actions within a transaction and for maintaining a common context between actions.
また、Kernelも取引の中の異なった動作の連動と動作の間で一般的な文脈を維持するのに責任があります。
+-------------------------------------+
| Broker Kernel |
+-------------------------------------+
^ ^ ^
| -abstract- | -primitives- |
v v v
+-------+ +-------+ +-------+
| FUM | | FUM | | FUM |
+-------+ +-------+ +-------+
+-------------------------------------+ | ブローカーカーネル| +-------------------------------------+ ^ ^ ^ | -要約| -基関数| v対+に-------+ +-------+ +-------+ | FUM| | FUM| | FUM| +-------+ +-------+ +-------+
Figure 5 Broker Kernel
図5 ブローカーカーネル
Blinov, et al. [Page 10] RFC 2552 GAIA April 1999
Blinov、他 [10ページ]RFC2552GAIA1999年4月
3.5. Description of FUMs
3.5. 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
1. 3 6 7 他の俳優10支払い操作の外部の電話番号案内9認証と対話しながら情報8の有用性に関してユーザを警告しながら仲買業サービスにユーザーインタフェースを提供しながら連続したメディアの流れとして情報を配布しながら項目形式5で情報を配布しながらユーザがProducts4を注文するのを許容しながらそれの識別が知られているユーザ記述2ソーシングProductsに合うProductsを捜し求めること。
Each of these activities is carried out by the corresponding FUM as described below and shown in Figure 6.
それぞれのこれらの活動が以下で説明されて、図6に示されるように対応するFUMによって行われます。
Search FUM
検索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.
検索FUMは特定のユーザ記述に合うProductsの検索を行うという要求を受け入れます。 それは人相書きに一致しているProductsに関する識別子のリストを返します。
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.
Locate FUMは、Product識別子を受け入れて、それらがどこで得られるかもしれないかを発見します。 それはProductのためにSuppliersと位置のリストを返します。
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.
Order FUMは、Productsの特定のProductかグループの有用性に関する諸条件で合意に達することができるようにCustomerとSupplierとの交渉を管理します。 交渉フェーズに続いて、Order FUMはCustomerから購買委託を受け入れて、それらをSupplierに送ります。 それはOrder Actionの状態の通知を返します。
Blinov, et al. [Page 11] RFC 2552 GAIA April 1999
Blinov、他 [11ページ]RFC2552GAIA1999年4月
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))
GAIAブローカー: ---------------- (顧客)) (警告)) (DS)) (Auth)) (支払い)) (FUs)) (FUs)) (FUs)) (FUs)) (FUs)) (例えば、HTTP)) (例えば、SMS)) (eg LDAP)) ( )) (例えば、セット)) \/\/\/\/\/[顧客][警告します][DS][Auth][支払い][FUM][FUM][FUM][FUM][FUM]| | | | | +----------------------------------------------------------+ | ブローカーカーネル| +----------------------------------------------------------+ | | | | | [検索][場所を見つけます][オーダー][ストリーム][離散的な][FUM][FUM][FUM][配送][配送][ ][ ][ ][FUM][FUM]/\/\/\/\/\(検索) (場所を見つけます)) (オーダー)) (サウスダコタ)) (DD)) (FUs)) (FUs)) (FUs)) (FUs)) (FUs)) (eg Z39.50)) (eg Z39.50)) (eg ISO病気)) (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.
Discrete Delivery FUMは離散的な項目の配送をCustomerに管理します。
Stream Delivery FUM
ストリーム配送FUM
The Stream Delivery FUM manages the delivery of real-time multimedia data streams to the Customer.
Stream Delivery FUMはリアルタイムのマルチメディアデータ・ストリームの配送をCustomerに管理します。
Customer FUM
顧客FUM
The Customer FUM provides an interface to support the Customer's systems interaction with the brokerage system.
Customer FUMは、仲買業システムとのCustomerのシステム相互作用をサポートするためにインタフェースを提供します。
Alerting FUM
FUMを警告します。
The Alerting FUM notifies Customers about changes that may interest them.
Alerting FUMは彼らを関心があるかもしれない変化に関してCustomersに通知します。
Directory Services FUM
ディレクトリサービスFUM
The Directory Services FUM provides an interface between an external directory service and the brokerage system.
FUMが外部のディレクトリサービスと仲買業システムとのインタフェースを提供するディレクトリサービス。
Blinov, et al. [Page 12] RFC 2552 GAIA April 1999
Blinov、他 [12ページ]RFC2552GAIA1999年4月
Authentication FUM
認証FUM
The Authentication FUM provides a mechanism that allows a user to prove his identity to the brokerage system.
Authentication FUMはユーザが彼のアイデンティティを立証できるメカニズムを仲買業システムに供給します。
Payment FUM
支払いFUM
The Payment FUM provides a mechanism for payment from one actor to another.
Payment FUMは1人の俳優から別の俳優までの支払いにメカニズムを提供します。
4. GAIA Brokerage System Interfaces
4. GAIA仲買業システム・インタフェース
This Chapter describes the internal and external interfaces of the GAIA brokerage system.
この章はGAIA仲買業システムの内部の、そして、外部のインタフェースについて説明します。
4.1. Internal Interfaces
4.1. 内部のインタフェース
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言語で定義されます。 インタフェース呼び出しはコンポーネントの間でObject Request Broker(ORB)によって通過されます。
The advantage of this approach is that the specifications of the interfaces are platform and programming language independent. These interfaces can be implemented using different programming languages on different platforms. All necessary conversions during interface invocations are transparently performed by an ORB. The CORBA model also allows installing different functional components of the GAIA Broker on different computers connected by a network. Interface calls will be transferred over the network by an ORB transparently for the application.
このアプローチの利点はインタフェースの仕様がプラットホームとプログラミング言語独立者であるということです。 異なったプラットホームで異なったプログラミング言語を使用することでこれらのインタフェースを実装することができます。インタフェース実施の間のすべての必要な変換がORBによって透過的に実行されます。 また、CORBAモデルはネットワークによって接続された異なったコンピュータにGAIA Brokerの異なった機能部品を取り付けさせます。 インタフェース呼び出しは透過的にアプリケーションのために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].
KernelとFUMsと各FUMと対応するFUsとのインタフェースの仕様はGAIA Standard[1]に提示されます。
4.2. External protocols
4.2. 外部のプロトコル
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は、他の俳優とコミュニケートするのに既存のプロトコルを使用できます。 例えば、それはCustomers、検索のためのZ39.50などとの相互作用にHTTPを使用できます。 GAIA Functional Architectureで説明されるように、特定の技術のサポートはFUsによって提供されます。 対応する新しいFUsをBrokerに取り付けることによって、1セットのサポートしているプロトコルを広げることができます。 GAIA Brokerは各動作のためにいくつかのプロトコルをサポートできます。 FUMsはトランザクションのために最も適切なプロトコルを選択するでしょう。 それが提供できるBroker、より良いサービスでサポートされたプロトコルは、より多いです。
Blinov, et al. [Page 13] RFC 2552 GAIA April 1999
Blinov、他 [13ページ]RFC2552GAIA1999年4月
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 StandardはBrokerによってサポートされたプロトコルのセットを制限しません。 しかしながら、相互運用性の目的として、それは数個のGAIAプロフィールを指定します。 これらのプロフィールはBrokersがGAIA Brokers、GAIA意識しているSuppliers、およびCustomersとのコミュニケーションを作るためにサポートするよう奨励されるプロトコル(そして、一般的な範囲のプロトコルパラメタ)の一般的な部分集合を定義します、可能です。
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 Brokerに連絡する唯一の方法ではありません。 GAIAインタフェースが既存のインタフェースとプロトコルの一般化として設計されているので、それらはどんな特定のプロトコルより多くの機能性も提供します。 GAIA Brokerの完全な機能性へのアクセスを与えるために、GAIA Standardはユーザ(顧客と他のBrokers)に図7に示されるようにGAIA Broker(Customer FUMとFUsの間で連結する)のCORBAによって定義されたCustomerインタフェースを直接使用させます。 この場合、Customerシステムは、基本的なORBのサービスを利用することでBrokerのCustomerインタフェースに近づく手段を得て、インタフェースの対応するメソッドを呼ぶことによって、操作を要求できます。 GAIA BrokerのCustomerインタフェースはGAIA Standard[1]で指定されます。
Where Customer and Supplier systems are not CORBA-aware, they can communicate with a GAIA Broker using existing protocols. If, however, they can use the service of an ORB, they are encouraged to communicate with a Broker by connecting to its Customer interface. This method allows for avoiding convergence between a particular protocol and the GAIA interface. The former method makes interactions with all existing types of Customers and Suppliers possible using existing and widespread protocols. The later method has been designed to achieve maximum functionality by using native GAIA methods for communication with Customers and Suppliers.
CustomerとSupplierシステムがCORBA意識していないところに、それらは既存のプロトコルを使用するGAIA Brokerで交信できます。 しかしながら、彼らがORBのサービスを利用できるなら、彼らがCustomerインタフェースに接続することによってBrokerとコミュニケートするよう奨励されます。 このメソッドは、特定のプロトコルとGAIAインタフェースの間の集合を避けると考慮します。 CustomersとSuppliersのすべての既存のタイプが可能な状態で前のメソッドは、存在と広範囲のプロトコルを使用することで相互作用を作ります。 後のメソッドは、CustomersとSuppliersとのコミュニケーションに固有のGAIAメソッドを使用することによって最大の機能性を達成するように設計されています。
Blinov, et al. [Page 14] RFC 2552 GAIA April 1999
Blinov、他 [14ページ]RFC2552GAIA1999年4月
+----------------+
|Broker |
| |
| -------- |
+-----------+ | [ Kernel ] |
| Broker | | -------- |
| or | | [Customer] |
| Customer | | [ FUM ] |
| | | ========== <-GAIA Customer
| * | | * * | \interface
| { O R B *}* * * * * * *{* O R B * } |
+-----------+ iiop | * | +----------+
| (Customer) | | Customer |
| ( FU ) | | |
+------------I---+ +----I-----+
\ HTTP /
- - - - - -
+----------------+ |ブローカー| | | | -------- | +-----------+ | [カーネル]| | ブローカー| | -------- | | または| | [顧客]| | 顧客| | [FUM]| | | | ========== <。GAIA顧客| * | | * * | \インタフェース| ○ R B*、********O R B*| +-----------+ iiop| * | +----------+ | (顧客) | | 顧客| | (フー) | | | +------------I---+ +----I-----+ \HTTP/--、--、--、--、--、-
Figure 7 External protocols and the GAIA Customer interface
図7 ExternalプロトコルとGAIA Customerインタフェース
5. GAIA Standard Profiles
5. 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 Standardは多くのプロフィールを定義します。(Brokerは、他のGAIA俳優(顧客、Suppliers、および他のBrokers)と共に相互運用性を達成するためにプロフィールを支えるかもしれません)。 Brokerによって選ばれたプロフィールの複雑さはBrokerがGAIA-conformant方法で提供したがっているサービスのレベルとタイプに頼っています。 サービスのレベルが高ければ高いほど、BrokerがCustomerに供給して、Brokerがサポートしたがっているサプライ・チェーンの長さが大きければ大きいほど、より多くがプロフィールを進めて、Brokerがサポートしなければならない拡大モジュールの数は、より大きいです。
5.1. Supply Chains
5.1. サプライ・チェーン
The GAIA profile definition approach is based on the possible types of supply chain that a brokerage system can be a part of.
GAIAは仲買業システムがaが部分であったならそうすることができる可能なタイプのサプライ・チェーンに基づいてアプローチがある定義の輪郭を描きます。
The operations of a brokerage system can be broken into three categories:
3つのカテゴリを仲買業システムの操作に細かく分けることができます:
- interactions with the Customer - interactions with other Brokers - interactions with Suppliers
- Customerとの相互作用--他のBrokersとの相互作用--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:
これらの1番目と最終はサプライ・チェーンの2つの終わりに起こります、interbroker操作が他のポイントでチェーンで行われますが。 サプライ・チェーンは多くの異なった形を取るかもしれません:
Blinov, et al. [Page 15] RFC 2552 GAIA April 1999
Blinov、他 [15ページ]RFC2552GAIA1999年4月
- 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.
- 最小量のチェーン。(そこには、CustomerとBrokerがチェーンの端であり、介入しているリンクが全くありません)。 この場合、BrokerはSupplierの役割をCustomerに果たします。
- a three-piece chain, where the Broker deals with the Customer and
the Supplier but not with any other Broker.
- スリーピースチェーン。(そこでは、BrokerはCustomerとSupplierに対処しますが、いかなる他のBrokerと共にも対処するというわけではありません)。
- a longer chain, with one or more interbroker operations.
- 1つ以上のinterbroker操作がある、より長いチェーン。
Minimal Supply Chain:
+--------+ +-------------+
|Customer| <=====> | Broker |
+--------+ |(as Supplier)|
+-------------+
3-piece Supply Chain:
+--------+ +--------+ +--------+
|Customer| <===> | Broker | <===> |Supplier|
+--------+ +--------+ +--------+
Longer Supply Chain:
+--------+ +--------+ +--------+ +--------+
|Customer| <===> | Broker |<=>| Broker | <===> |Supplier|
+--------+ +--------+ +--------+ +--------+
最小量のサプライ・チェーン: +--------+ +-------------+ |顧客| <===>| ブローカー| +--------+ |(供給者としての)| +-------------+ 3断片のサプライ・チェーン: +--------+ +--------+ +--------+ |顧客| <==>| ブローカー| <==>| 供給者| +--------+ +--------+ +--------+ より長いサプライ・チェーン: +--------+ +--------+ +--------+ +--------+ |顧客| <==>| ブローカー|<=>| ブローカー| <==>| 供給者| +--------+ +--------+ +--------+ +--------+
Figure 8 Supply Chains
エイト環サプライ・チェーン
5.1.1. Minimal Supply Chains
5.1.1. 最小量のサプライ・チェーン
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 Reference Modelで議論するように、GAIAトランザクションは多くの動作で構成されます、検索や、注文や、配送などのように。 各トランザクションは要求をBrokerにするCustomerによって開始されます。 Brokerが要求を充足できるなら、トランザクションは他の俳優に全くかかわりません。
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トランザクションはCustomerとBrokerにかかわります。 標準化されているのが、CustomerとBrokerの間のそれであるということである必要がある唯一のプロトコル。 これは以下のGAIA Standard Minimalプロフィールで指定されます。
5.1.2. Longer Supply Chains
5.1.2. より長いサプライ・チェーン
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.
Brokerが要求を充足できないなら、動作は他のBrokersに伝播されるかもしれません、オリジナルのBrokerがCustomerの役割を果たしていて。 彼らがそれを充足できないなら、それぞれのこれらのBrokersは順番に要求を伝播するかもしれません。
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.
結局、動作がうまくいくと、要求を充足できるSupplierは見つけられるでしょう。 このようにしてサプライ・チェーンを独身のCustomer、1Suppliers、および1Brokersにします。
Blinov, et al. [Page 16] RFC 2552 GAIA April 1999
Blinov、他 [16ページ]RFC2552GAIA1999年4月
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.
1Brokerから別のBrokerまでの動作を伝播して、ブローカー兼ブローカー相互作用のために標準化された通信プロトコルを定義しなければなりません。 これは以下のBasicプロフィールで指定されます。 このプロフィールは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.
しかしながら、供給者とBrokersがGAIA StandardのBasicプロフィールを支えるのが強いられません。 彼らは代わりに別のものを使用するかもしれなくて、より伝統的であることで、発見のためのZ39.50、または注文するためのISO ILLなどのように議定書を作ってください。 GAIA StandardへのExtension Modulesは、様々な仲買業機能に使用されるためにプロフィールを指定します。
5.2. Introduction to the GAIA Standard Profiles and Modules
5.2. 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が従わなければならないまさしくその最少であるMinimalプロフィール--相互ブローカーにコミュニケーションを許容するBasic Profile--Brokerを様々なサービスを提供して、Suppliersと共に共同利用させる多くのExtension Modules、プロトコルを使用するBrokersとCustomersがモジュールで指定しました--Interface Modulesのセットであり、それは、どの特定のFunctional Unit CORBAインタフェースがBrokerによってサポートされるかを定義します。
Each Broker must conform at least to the Minimal profile to provide a web-based user interface. In addition, to take part in inter-broker communications, the Basic profile is recommended. For interaction with non-CORBA-aware entities, and for the use of advanced services, there are other modules of the standard to which the Broker may conform. These are denoted "Extension Modules", and they characterise the protocols and standards in a particular area of functionality. A Broker can choose an appropriate set of Extension Modules to conform to according to the functionality it wishes to achieve.
各Brokerは、ウェブベースのユーザーインタフェースを提供するために少なくともMinimalプロフィールに従わなければなりません。 さらに、相互ブローカーコミュニケーションに参加するために、Basicプロフィールはお勧めです。 相互作用、非CORBA意識する、実体、高度なサービスの使用のために、Brokerが従うかもしれない規格の他のモジュールがあります。 これらは指示された「拡大モジュール」です、そして、それらは機能性の特定の領域でプロトコルと規格を特徴付けます。 Brokerは適切なExtension Modulesを選ぶことができます。それが達成したがっている機能性に従って従うために。
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 StandardはFUMとFUsとのすべてのインタフェースをGAIA Brokerに指定します。 しかしながら、あらゆるBrokerがそれらを皆、実装するのが必要であるのは、あまりに多くでしょう。 GAIA Standardはすべてのインタフェースを多くのInterface Modulesに分解します。 Brokerは操作の領域では、より重要なInterface Modulesの部分集合を選んで、これらのモジュールで定義されたインタフェースを実装することができます。 これらのインタフェースは、ブローカーシステムだけの中で重要であり、他のGAIA俳優とのコミュニケーションでどんな役割も果たしません。 しかしながら、管理者がGAIA-conformant FUsを取り付けることによってBrokerの機能性を広げることができる領域を見つけるように、サポートしているインタフェースの宣言は重要です。
Blinov, et al. [Page 17] RFC 2552 GAIA April 1999
Blinov、他 [17ページ]RFC2552GAIA1999年4月
5.3. Minimal Profile
5.3. 最小量のプロフィール
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がサポートしなければならない最小の機能性で、それは最小量のチェーンの一部としてCustomerに対するサービスを提供できるでしょう。 この場合、Brokerが要求されることは単にCustomerのためのユーザーインタフェースです。 もう、何も操作は、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.
Minimalプロフィールは、BrokerがRFC2068[3]で定義されたHTTP1.1プロトコルに基づくユーザーインタフェースとRFC1866[4]で定義されたHTML2.0を実装するのを必要とします。 それは、CustomerがHTTP1.1を使用することによってGAIA Brokerに関する基本機能にアクセスできて、HTML2.0conformantウェブブラウザであるべきであることを意味します。
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].
CustomersがGAIA Brokerの場所を見つけるのは、可能であるべきです。 したがって、GAIA Brokerは、ディレクトリサービスでGAIA Standard[1]で指定された図式を使用することで登録されるべきです。
+-------------------------------------------------+ | Minimal Profile | +------------------------+------------------------+ | Customer | HTTP 1.1 (server), | | | HTML 2.0 | +------------------------+------------------------+
+-------------------------------------------------+ | 最小量のプロフィール| +------------------------+------------------------+ | 顧客| HTTP1.1(サーバ)| | | HTML2.0| +------------------------+------------------------+
5.4. Basic Profile
5.4. 基準山形
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.
最小量の機能性がBrokerが機能するのを許容するために十分である間、どんなGAIA Brokerの機能性の重要な一面も他のBrokersに対処しています。 Basicプロフィールの目標はBrokersの間で連邦を達成することです。 あらゆるGAIA Brokerが、Customerの要求を充足するのに他のGAIA Brokersのサービスを利用できます。 そのBrokerは順番に第3GAIA Brokerのサービスを利用できます。 それで、数個のBrokersがあらゆる要求をチェーニングできます。 これはあらゆるGAIA動作(検索、Locate、Orderなど)の能力を広げています。 チェーニングされたトランザクションはトランザクションの発見フェーズで特に重要です。そこでは、特定の情報必須条件を充足できないBrokerが別の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].
Basicプロフィールは、BrokerがCORBAに関して定義されたGAIA Customerインタフェースを実装するのを必要とします。 このインタフェースはさらに詳細に上のセクション4.2で説明されます。 また、Basicプロフィールは、Brokerがインタフェース要請者手順を実装して、すなわち、他のBrokersのCustomerインタフェースに接続できるのを必要とします。 Brokerによって使用されたORBはCORBA2.0仕様[2]へのconformantであり、相互ORBコミュニケーション[2]にIIOPプロトコルを使用するはずです。
Blinov, et al. [Page 18] RFC 2552 GAIA April 1999
Blinov、他 [18ページ]RFC2552GAIA1999年4月
A full specification of the GAIA Customer interface is presented in the GAIA Standard [1].
GAIA Customerインタフェースの完全な仕様は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.
GAIA Brokerは他のBrokersとSuppliersを見つけるはずであることができます。 また、それで、他の関係者はそれを見つけることができるべきです。 したがって、GAIA Brokerはディレクトリサービスをサポートするはずです。 Basicプロフィールはこのためにディレクトリアクセス・プロトコルを含んでいます。 プロトコルの実際の選択は標準化されません、選択が他のBrokersとのBrokerの相互操作の成功に影響を及ぼさないので。 ディレクトリ図式(使用されるべきである)はGAIA Standardで指定されます。
The Basic profile suggested for a Broker to allow it to interoperate with other GAIA Brokers is as follows.
Basicプロフィールは、Brokerが他のGAIA Brokersと共に共同利用させるのが以下の通りであると示唆しました。
+----------------------------------------------------------------+ | 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 | +------------------------+---------------------------------------+
+----------------------------------------------------------------+ | 基準山形| +------------------------+---------------------------------------+ | 顧客| GAIA顧客インタフェース/IIOP(サーバ)| | 捜して、場所を見つけます。| GAIA顧客インタフェース/IIOP(クライアント)| | (発見) | | | オーダー| GAIA顧客インタフェース/IIOP(クライアント)| | ディレクトリ| 何らかのディレクトリアクセス・プロトコル| | | LDAPのように| +------------------------+---------------------------------------+
5.5. Extension Modules
5.5. 拡大モジュール
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.
Brokersが、Basicプロフィールを支えない他のBrokersと共に共同利用して、BrokersがCORBA意識していないSuppliersとCustomersに対処して、Brokerを通して項目とデータ・ストリームの配送を許すのを許容するのを許容するために、他の開いている技術は拡大としてBasicとMinimalプロフィールに示されます。 これらの技術はプロジェクト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.
付加的なプロトコルはExtension Modulesに分類されます。 これらのExtension Modulesのサポートは任意です。 Brokerは適切なExtension Modulesを選ぶことができます。それが達成したがっている機能性に従って従うために。 それぞれの既存の領域(顧客、ディスカバリー、およびOrder)がGAIAの抽象的な基関数以外のプロトコルの使用を許すように、BasicとMinimal Profilesでカバーされていないそれぞれの機能的な領域への1Extension Module、および1Extension Moduleもあります。
Blinov, et al. [Page 19] RFC 2552 GAIA April 1999
Blinov、他 [19ページ]RFC2552GAIA1999年4月
The following Extension Modules are defined.
以下のExtension Modulesは定義されます。
- 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
5.5.1. 発見拡大モジュール
The Discovery Extension Module specifies the technologies to be used in searching for and locating products and services.
ディスカバリーExtension Moduleは製品とサービスを捜し求めて、場所を見つける際に使用されるべき技術を指定します。
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:
このExtension Moduleは、[5]で定義されるようにBrokerがZ39.50プロトコルのクライアント部分をサポートするのを必要とします。 プロトコルの以下の部分集合が必要です:
- Init, Search, and Present services - GRS-1 record syntax
- イニット、検索、およびPresentサービス--GRS-1は構文を記録します。
Z39.50 protocol PDUs should be carried using TCP/IP network protocols.
Z39.50プロトコルPDUsは、TCP/IPネットワーク・プロトコルを使用することで運ばれるべきです。
+-------------------------------------------------+ | Discovery Extension Module | +------------------------+------------------------+ | Searching, | Z39.50 (client) | | Locating | | +------------------------+------------------------+
+-------------------------------------------------+ | 発見拡大モジュール| +------------------------+------------------------+ | 探すこと| Z39.50(クライアント)| | 場所を見つけること| | +------------------------+------------------------+
5.5.2. Order Extension Module
5.5.2. オーダー拡大モジュール
The Order Extension Module specifies the protocols to be used to order products and services from a Supplier.
Order Extension Moduleは、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.
このExtension Moduleは、BrokerがISO ILLプロトコル[6]のクライアント部分のすべての義務的なサービスをサポートするのを必要とします。 基本的な順応評価基準は固く守られるべきです。 ISO ILLプロトコルPDUsは、TCP/IPネットワーク・プロトコルを使用することで運ばれるべきです。
Blinov, et al. [Page 20] RFC 2552 GAIA April 1999
Blinov、他 [20ページ]RFC2552GAIA1999年4月
+-------------------------------------------------+ | Order Extension Module | +------------------------+------------------------+ | Order | ISO ILL (client) | +------------------------+------------------------+
+-------------------------------------------------+ | オーダー拡大モジュール| +------------------------+------------------------+ | オーダー| ISOの病気の(クライアント)| +------------------------+------------------------+
5.5.3. Discrete Delivery Extension Module
5.5.3. 離散的な配送拡大モジュール
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
Discrete Delivery Extension Moduleは、オンライン製品の、そして、Customerに対するサービスの配送に使用されるためにプロトコルと規格を指定します。 考えられた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.
- Supplierが配送における、どんなBrokerのかかわり合いなしでも彼の製品をCustomerに直接供給しているシングルステップ操作が加工処理していたなら配送がそうするかもしれないCustomer配送にSupplierを向けてください。 Brokerは、SupplierをCustomerを参照するために行動したかもしれません。 この場合、Brokerが配送にかかわらないところでDiscrete Delivery Extension Moduleは適用しません。
- 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.
- 1BrokersのかかわったInに伴うSupplierブローカーの顧客のフォーム、Brokerのサプライ・チェーンで中央のリンクであるBrokerのイベントがそうするサプライ・チェーンの配送はSupplierから製品を受け取って、製品をCustomerに供給するためにDiscrete Delivery Extension Moduleで指定されたプロトコルを使用します。
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.
Discrete Delivery Extension Moduleは、Brokerが、FTPクライアントとFTPサーバの機能性[7]の両方を前提として、Brokerが受信して、ファイルを送るのを許容するのを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.
また、Discrete Delivery Extension Moduleは、GAIA Brokerが、受け入れて、メールがメッセージであると生成することができるのを必要とします。 指定されたメールプロトコルはインターネット電子メールです、RFC822[9]で指定されたSMTPプロトコル[8]とメールデータ形式に基づいて。 このプロトコルは原文のメールメッセージの作成、トランスミッション、および管理に十分です。 しかしながら、様々なタイプに関するデータファイルの伝達において、SMTP/RFC822プロトコルへの拡大が必要です。 Discrete Delivery Extension Moduleによって指定されたメール拡張子はRFCs2045-2049[10]で定義されたMIME(マルチパーパスインターネットメールエクステンション)に基づいています。 したがって、GAIA Brokerは「簡単な」SMTP/RFC822メールを送って、受け取ることができて、また、RFC2045-2049MIMEメール拡張子に対処できなければなりません。
For electronic document delivery the Discrete Delivery Extension Module requires the support of GEDI version 3.0.
電子化文書配送のために、Discrete Delivery Extension ModuleはGEDIバージョン3.0のサポートを必要とします。
Blinov, et al. [Page 21] RFC 2552 GAIA April 1999
Blinov、他 [21ページ]RFC2552GAIA1999年4月
+--------------------------------------------------------+ | 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 | +------------------------+-------------------------------+
+--------------------------------------------------------+ | 離散的な配送拡大モジュール| +------------------------+-------------------------------+ | FTPプロフィール| FTP(クライアント+サーバ)| | メールプロフィール| インターネット電子メール[SMTP、RFC822]| | | (受信機+送付者), | | | MIME| | 文書の配信| GEDIバージョン3.0| +------------------------+-------------------------------+
5.5.4. Stream Delivery Extension Module
5.5.4. ストリーム配送拡大モジュール
This Extension Module is intended to support real-time delivery of multimedia by the GAIA Broker.
このExtension Moduleが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.
- 直接SupplierからCustomerまで、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を通したSupplierからCustomerまでのBrokerはキャッシュアルゴリズムを実装することによって、ストリーム配送過程に価値を高めることができます、ストリーム、数個のCustomersへの分岐1つのストリームなどを混ぜて
- 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.
- BrokerはBrokerからCustomerまで、少量のマルチメディアがそれ自身のデータベースのデータ(例えば、オーディオの例)であることを保って、要求でのCustomerにそれを提供できます。
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.
Stream Delivery Extension Moduleはリアルタイムのマルチメディア配送の最後の2つのシナリオを提供するためにBrokerによって実装されることが勧められます。
The Stream Delivery Extension Module requires the Broker to support the following technologies:
Stream Delivery Extension Moduleは、Brokerが以下の技術をサポートするのを必要とします:
- Compression
MPEG-2 Audio Layer 3, specified in ISO/IEC 13818-3 [11]. Only
support of constrained parameter streams (CSPS) is required.
- ISO/IEC13818-3[11]で指定された圧縮MPEG-2Audio Layer3。 強制的なパラメタストリーム(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.
- データ転送プロトコルRTPはRFC1889[12](クライアントとサーバ一部の両方)で定義されたUDP/IPの上で議定書を作ります。 RTPアプリケーション・サービス実体(「翻訳者」か「ミキサー」)の完全なふるまいがサポートされますが、それは必要でないのが、お勧めです。
Blinov, et al. [Page 22] RFC 2552 GAIA April 1999
Blinov、他 [22ページ]RFC2552GAIA1999年4月
- Mapping
RTP payload format for MPEG Audio (MPA), defined in RFC 2250 [13].
- RFC2250[13]で定義されたMPEG Audio(MPA)のためにRTPペイロード形式を写像します。
- Session control protocol
RTCP, specified in RFC 1889 [12].
- RFC1889[12]で指定されたセッション制御プロトコルRTCP。
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 | +--------------------------+-------------------------+
+----------------------------------------------------+ | ストリーム配送拡大モジュール| +--------------------------+-------------------------+ | 圧縮| MPEG-2オーディオ層3| | データ転送| RTP(クライアント+サーバ)| | マッピング| RFC2250| | セッション制御プロトコル| RTCP| +--------------------------+-------------------------+
5.5.5. Security Extension Module
5.5.5. セキュリティ拡大モジュール
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つの状況に必要です: セッションを始めるときのユーザワークステーションでの認証、地方の環境(クライアント/サーバ証明)とaでグローバルな認証、オープンネットワーク(インターネット)における認証。
- 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.
このモジュールで、Brokerは他の関係者とのコミュニケーションを保証できます。 それはセキュリティ、認証、および証明書交換をチャンネルに供給します。
The Security Extension Module specifies the following protocols and algorithms:
Security Extension Moduleは以下のプロトコルとアルゴリズムを指定します:
- Privacy, integrity, non-repudiation
- プライバシー、保全、非拒否
Blinov, et al. [Page 23] RFC 2552 GAIA April 1999
Blinov、他 [23ページ]RFC2552GAIA1999年4月
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].
- RFC1508[16]で指定されたリモートクライアント/サーバ証明GSS v5。
- 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 | +--------------------------------------+--------------------+
+-----------------------------------------------------------+ | セキュリティ拡大モジュール| +--------------------------------------+--------------------+ | プライバシー、保全、非拒否| 3.0、SSL対PKCS#7| | リモートクライアント/サーバ証明| GSS v5| | 証明サービス| PKIX証明| | | プロトコル| +--------------------------------------+--------------------+
5.5.6. Payment Extension Module
5.5.6. 支払い拡大モジュール
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.
このモジュールで、BrokerはCustomers、Suppliers、および他のBrokersとの電子決済操作を実行できます。 そのような操作は検索、Locate、Order、または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.
Brokerによって使用されるように、GAIA Standardはtariffingか充電モデルを指定しません。 これは国内事情であると考えられます。 しかしながら、請求書が一致していたとき、支払いは安全で互いに許容できる方法で行われなければなりません。 GAIA Standardで指定された支払い手順はSET仕様を利用します。
The Payment Extension Module requires a Broker to support SET v1.0 merchant's server and SET certification protocol, specified in [18].
Payment Extension Moduleは、Brokerが、SET v1.0が[18]で指定された商人のサーバとSET証明プロトコルであるとサポートするのを必要とします。
+----------------------------------------------------+ | Payment Extension Module | +------------------------+---------------------------+ | Payment | SET v 1.0 : | | | 1) CA server for banks | | | 2) Cardholder wallet | | | 3) Merchant Server | | | 4) Payment Gateway server | +------------------------+---------------------------+
+----------------------------------------------------+ | 支払い拡大モジュール| +------------------------+---------------------------+ | 支払い| SET v1.0: | | | 1) 銀行へのカリフォルニアサーバ| | | 2) カード保持者財布| | | 3) 商人サーバ| | | 4) 支払いゲートウェイサーバ| +------------------------+---------------------------+
Blinov, et al. [Page 24] RFC 2552 GAIA April 1999
Blinov、他 [24ページ]RFC2552GAIA1999年4月
5.5.7. Alerting Extension Module
5.5.7. 拡大モジュールを警告します。
The Alerting Extension Module specifies the protocols to notify Customers about changes that can be interesting for them.
Alerting Extension Moduleは、それらによっておもしろい場合がある変化に関してCustomersに通知するためにプロトコルを指定します。
This Extension Module requires the support of the following technologies:
このExtension Moduleは以下の技術のサポートを必要とします:
- 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].
- SMTPプロトコル[8]に基づいたインターネット電子メール、およびRFC822[9]で指定されたメールデータ形式。 Brokerはメールメッセージを生成して、送ることができるはずです。 - [19]で指定されたSMS(短いMessage Service)。
+-----------------------------------------------------+ | Alerting Extension Module | +-----------+-----------------------------------------+ | Alerting | Internet e-mail [SMTP,RFC822] (sender), | | | SMS | +-----------+-----------------------------------------+
+-----------------------------------------------------+ | 拡大モジュールを警告します。| +-----------+-----------------------------------------+ | 警告| インターネット電子メール[SMTP、RFC822](送付者)| | | SMS| +-----------+-----------------------------------------+
5.5.8. Customer Discovery Extension Module
5.5.8. 顧客発見拡大モジュール
The Customer Discovery Extension Module allows Z39.50 clients to use the service of the GAIA Broker.
CustomerディスカバリーExtension ModuleはZ39.50クライアントにGAIA Brokerのサービスを利用させます。
This Extension Module requires the Broker to support the server part of the Z39.50 protocol, as defined in [5]. The following subset of the protocol is required:
このExtension Moduleは、[5]で定義されるようにBrokerが、サーバがZ39.50プロトコルの一部であるとサポートするのを必要とします。 プロトコルの以下の部分集合が必要です:
- Init, Search, and Present services - GRS-1 record syntax
- イニット、検索、およびPresentサービス--GRS-1は構文を記録します。
Z39.50 protocol PDUs should be carried using TCP/IP network protocols.
Z39.50プロトコルPDUsは、TCP/IPネットワーク・プロトコルを使用することで運ばれるべきです。
+----------------------------------------------------+ | Discovery Extension Module | +------------------------+---------------------------+ | Searching, | Z39.50 (server) | | Locating | | +------------------------+---------------------------+
+----------------------------------------------------+ | 発見拡大モジュール| +------------------------+---------------------------+ | 探すこと| Z39.50(サーバ)| | 場所を見つけること| | +------------------------+---------------------------+
5.6. Interface Modules
5.6. インタフェース・モジュール
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
順応の目的のために、GAIA Standardによって指定されたFUMsとFUsとのすべてのインタフェースがGAIA Interface Modulesに分類されます。 これらのモジュールはGAIA Brokerによってサポートされることが勧められますが、それらは義務的ではありません。 Brokerは部分集合を選ぶことができます。
Blinov, et al. [Page 25] RFC 2552 GAIA April 1999
Blinov、他 [25ページ]RFC2552GAIA1999年4月
Interface Modules that are more important in its area of operation, and implement interfaces defined in these modules.
操作の領域では、より重要なModulesを連結してください、そして、これらのモジュールで定義されたインタフェースを実装してください。
A full specification of the Functional Unit interfaces is presented in the GAIA Standard [1].
Functional Unitインタフェースの完全な仕様はGAIA Standard[1]に提示されます。
The following table defines Interface Modules and specifies which interfaces have to be supported in each of them.
以下のテーブルは、Interface Modulesを定義して、どのインタフェースがそれぞれのそれらでサポートされなければならないかを指定します。
+--------------------+------------------------------------+ | 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 | +--------------------+------------------------------------+
+--------------------+------------------------------------+ | インタフェース・モジュール| 必要なインタフェース| | | このモジュールで、サポートされます。| +--------------------+------------------------------------+ | 検索| 検索FUインタフェース| | 場所を見つけます。| FUインタフェースの場所を見つけてください。| | オーダー| オーダーFUインタフェース| | 離散的な配送| 離散的なDelivery FUインタフェース| | ストリーム配送| ストリームDelivery FUインタフェース| | 顧客| 顧客FUインタフェース| | 警告| FUインタフェースを警告します。| | ディレクトリサービス| ディレクトリサービスFUインタフェース| | 認証| 認証FUインタフェース| | 支払い| 支払いFUインタフェース| +--------------------+------------------------------------+
6. Acknowledgement
6. 承認
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 Standardのデザイン過程による非常に活気がある議論と彼らの貴重なダイレクトで間接的な入力のためにGAIA Consortiumのすべてのメンバーに感謝したいと思います。
7. Security Considerations
7. セキュリティ問題
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に電子仲買業と関係がある安全保障問題について議論します。
8. References
8. 参照
[1] GAIA Consortium, Deliverable 0403, "GAIA Standard (Final)",
December 1998, see also <http://www.syspace.co.uk/GAIA/>.
[1] また、GAIA Consortium、Deliverable0403(「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] オブジェクト管理グループ(「CORBA2.0仕様」、1996年7月)は<ftp://ftp.omg.org/パブ/docs/正式な/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.、Gettys、J.、ムガール人、J.、Frystyk、H.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2068、1997年ハイパーテキスト転送プロトコル--1月」。
Blinov, et al. [Page 26] RFC 2552 GAIA April 1999
Blinov、他 [26ページ]RFC2552GAIA1999年4月
[4] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -
2.0", RFC 1866, November 1995.
そして、[4] バーナーズ・リー、T.、D.コノリー、「2インチ、RFC1866、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かISO23950、「情報検索:」 「アプリケーション・サービス定義とプロトコル仕様。」
[6] ISO 10161:1997 "Information and documentation -- Open Systems
Interconnection -- Interlibrary Loan Application Protocol
Specification".
[6]ISO10161: 1997 「情報と文書--オープン・システム・インターコネクション--Interlibrary Loan ApplicationプロトコルSpecification。」
[7] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC
959, October 1985.
[7] ポステルとJ.とJ.レイノルズ、「ファイル転送プロトコル」、STD9、RFC959、1985年10月。
[8] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
August 1982.
[8] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。
[9] Crocker, D., "Standard for the format of ARPA Internet text
messages", STD 11, RFC 822, August 1982.
[9] クロッカー、D.、「ARPAインターネット・テキスト・メッセージの形式の規格」、STD11、RFC822、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)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
Freed, N., and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
N.、およびN.Borenstein、解放されていて、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
November 1996.
ムーア、K.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、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)は4を分けます」。 「登録手順」、RFC2048、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を分けます」。 「順応評価基準と例」、RFC2049、11月1996日
[11] ISO/IEC IS 13818 "Information technology -- Coding of moving
pictures and associated audio information"
[11] ISO/IECが13818である、「情報技術、映画と関連オーディオ情報がコード化される、」
Part 1: Systems
Part 2: Video
Part 3: Audio
Part 4: Conformance testing
Part 5: Software simulation
第1部: システム第2部: ビデオパート3: オーディオパート4: Part5をテストする順応: ソフトウェアシミュレーション
Blinov, et al. [Page 27] RFC 2552 GAIA April 1999
Blinov、他 [27ページ]RFC2552GAIA1999年4月
[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:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、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有効搭載量形式」、RFC2250、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インチ、処理中の作業、トランスポート層セキュリティ作業部会、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: 暗号のメッセージ構文規格。 1993年11月のバージョン1.5。
[16] Linn, J., "Generic Security Service Application Program
Interface", RFC 1508, Geer Zolot Associate, September 1993.
[16] リン、J.、「ジェネリックセキュリティー・サービス適用業務プログラム・インタフェース」、RFC1508、イェール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)(GSM3.40)の技術的な実現。 バージョン5.2.0。 規格が設けるヨーロッパのテレコミュニケーション。 1996年5月。
Blinov, et al. [Page 28] RFC 2552 GAIA April 1999
Blinov、他 [28ページ]RFC2552GAIA1999年4月
9. Authors' Addresses
9. 作者のアドレス
Mikhail Blinov Computer Science Department University College Dublin Belfield, Dublin 4, Ireland
ミハイール・Blinovコンピュータサイエンス部のユニバーシティ・カレッジダブリンBelfield、ダブリン4アイルランド
Phone: +353 1-706-2488 Fax: +353 1-269-7262 EMail: mch@net-cs.ucd.ie
以下に電話をしてください。 +353 1-706-2488Fax: +353 1-269-7262 メールしてください: mch@net-cs.ucd.ie
Mikhail Bessonov Computer Science Department University College Dublin Belfield, Dublin 4, Ireland
ミハイール・Bessonovコンピュータサイエンス部のユニバーシティ・カレッジダブリンBelfield、ダブリン4アイルランド
Phone: +353 1-706-2488 Fax: +353 1-269-7262 EMail: mikeb@net-cs.ucd.ie
以下に電話をしてください。 +353 1-706-2488Fax: +353 1-269-7262 メールしてください: mikeb@net-cs.ucd.ie
Ciaran Clissmann Computer Science Department University College Dublin Belfield, Dublin 4, Ireland
Ciaran Clissmannコンピュータサイエンス部のユニバーシティ・カレッジダブリンBelfield、ダブリン4アイルランド
Phone: +353 1-706-2488 Fax: +353 1-269-7262 EMail: ciaranc@net-cs.ucd.ie
以下に電話をしてください。 +353 1-706-2488Fax: +353 1-269-7262 メールしてください: ciaranc@net-cs.ucd.ie
Blinov, et al. [Page 29] RFC 2552 GAIA April 1999
Blinov、他 [29ページ]RFC2552GAIA1999年4月
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Blinov, et al. [Page 30]
Blinov、他 [30ページ]
一覧
スポンサーリンク
