RFC2372 日本語訳
2372 Transaction Internet Protocol - Requirements and SupplementalInformation. K. Evans, J. Klein, J. Lyon. July 1998. (Format: TXT=53699 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Evans
Request for Comments: 2372 J. Klein
Category: Informational Tandem Computers
J. Lyon
Microsoft
July 1998
コメントを求めるワーキンググループK.エヴァンス要求をネットワークでつないでください: 2372年のJ.クラインカテゴリ: 情報のタンデムコンピューターズJ.リヨンマイクロソフト1998年7月
Transaction Internet Protocol - Requirements and
Supplemental Information
トランザクションインターネットプロトコル--要件と補足的情報
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 (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
This document describes the purpose (usage scenarios), and requirements for the Transaction Internet Protocol [1]. It is intended to help qualify the necessary features and functions of the protocol. It also provides supplemental information to aid understanding and facilitate implementation of the TIP protocol.
このドキュメントはTransactionインターネットプロトコル[1]のために目的(用法シナリオ)、および要件について説明します。 プロトコルの必要な特徴と機能に資格を与えるのを助けるのは意図しています。 また、それは、理解を支援して、TIPプロトコルの実装を容易にするために補足的情報を提供します。
Table of Contents
目次
1. Introduction 2
2. The Transaction Internet Protocol 3
3. Scope 4
4. Anticipated Usage of TIP 4
5. TIP Compliant Systems 4
6. Relationship to the X/Open DTP Model 5
7. Example TIP Usage Scenario 5
8. TIP Transaction Recovery 9
9. TIP Transaction and Application Message Serialisation 10
10. TIP Protocol and Local Actions 10
11. Security Considerations 11
12. TIP Requirements 11
References 14
Authors' Addresses 15
Comments 15
A. An Example TIP Transaction Manager API 16
Full Copyright Statement 24
1. 序論2 2。 トランザクションインターネットプロトコル3 3。 範囲4 4。 チップ4 5の用法を予期しました。 対応するシステム4 6をくつがえしてください。 X/Open DTPモデル5 7との関係。 例のチップ用法シナリオ5 8。 トランザクションリカバリ9 9をくつがえしてください。 トランザクションとアプリケーションメッセージ連載10 10をくつがえしてください。 プロトコルと地方の動き10 11をくつがえしてください。 セキュリティ問題11 12。 チップ要件11参照14作者のものはA. 例のチップトランザクションマネージャAPI16の完全な著作権宣言文24を15のコメント15に扱います。
Evans, et. al. Informational [Page 1] RFC 2372 TIP Requirements and Supplemental Information July 1998
etエヴァンス、アル。 情報[1ページ]のRFC2372チップ要件と補足的情報1998年7月
1. Introduction
1. 序論
Transactions are a very useful programming paradigm, greatly simplifying the writing of distributed applications. When transactions are employed, no matter how many distributed application components participate in a particular unit-of-work, the number of possible outcomes is reduced to only two; that is, either all of the work completed successfully, or none of it did (this characteristic is known as atomicity). Applications programming is therefore much less complex since the programmer does not have to deal with a multitude of possible failure scenarios. Typically, transaction semantics are provided by some underlying system infrastructure (usually in the form of products such as Transaction Processing Monitors, and/or Databases). This infrastructure deals with failures, and performs the necessary recovery actions to guarantee the property of atomicity. The use of transactions enables the development of reliable distributed applications which would otherwise be difficult, if not impossible.
分配されたアプリケーションの書くことを大いに簡素化して、トランザクションは非常に役に立つプログラミングパラダイムです。 いくつの分配されたアプリケーション構成要素が仕事の特定のユニットに参加してもトランザクションが採用しているとき、可能な結果の数は2だけまで減少します。 すなわち、首尾よく終了する仕事のすべてかそれのいずれのどちらかもそうしませんでした(この特性は最小単位として知られています)。 したがって、プログラマが可能な失敗シナリオの多数に対処する必要はないので、アプリケーションソフトのプログラミングはあまりそれほど複雑ではありません。 何らかの基本的なシステムインフラストラクチャ(通常、Transaction Processing Monitors、そして/または、Databasesなどの製品の形の)で通常、トランザクション意味論を提供します。 このインフラストラクチャは、最小単位の特性を保証するために失敗に対処して、必要な回復動作を実行します。 トランザクションの使用はそうでなければ難しいか、または不可能な分配された高信頼のアプリケーションの開発を可能にします。
A key technology required to support distributed transactions is the two-phase commit protocol (2-pc). 2-pc protocols have been used in commercial Transaction Processing (TP) systems for many years, and are well understood (e.g. the LU6.2 2-pc (syncpoint) protocol was first implemented more than 12 years ago). Today a number of different 2-pc protocols are supported by a variety of TP monitor and database products. 2-pc is used between the components participating in a distributed unit-of-work (transaction) to ensure agreement by all parties regarding the outcome of that work (regardless of any failure).
分配されたトランザクションをサポートするのに必要である主要な技術は二相がプロトコル(2-pc)を遂行するということです。 2-pcプロトコルは、何年も商業Transaction Processing(TP)システムで使用されて、よく理解されています(例えばLU6.2 2-pc(syncpoint)プロトコルは12年以上前に最初に、実装されました)。 今日、多くの異なった2-pcプロトコルがさまざまなTPモニターとデータベース製品によってサポートされます。 2-pcは、その仕事(どんな失敗にかかわらず)の結果に関してすべてのパーティーによる同意を確実にするために分配された仕事のユニット(トランザクション)に参加しながら、コンポーネントの間で使用されます。
Today both standard and proprietary 2-pc protocols exist. These protocols typically employ a "one-pipe" model. That is, the transaction and application protocols are tightly-integrated, executing over the same communications channel. An application may use only the particular communications mechanism associated with the transaction protocol. The standard protocols (OSI TP, LU6.2) are complex, with a large footprint and extensive configuration and administration requirements. For these reasons they are not very widely deployed. The net of all this is restricted application flexibility and interoperability if transactions are to be used. Applications may wish to use a number of communications protocols for which there are no transactional variants (e.g. HTTP), and be deployed in very heterogeneous application environments.
今日、標準のものと同様に独占である2-pcプロトコルは存在します。 これらのプロトコルは「1パイプ」のモデルを通常雇います。 同じコミュニケーションチャンネルの上に実行して、すなわち、トランザクションとアプリケーション・プロトコルはしっかり統合しています。 アプリケーションはトランザクションプロトコルに関連している特定のコミュニケーションメカニズムだけを使用するかもしれません。 標準プロトコル(OSI TP、LU6.2)は大きい足跡、大規模な構成、および管理要件で複雑です。 これらの理由で、それらはそれほど広く配布されません。 このすべてのネットは、狭い応用範囲の柔軟性とトランザクションが使用されていることであるなら、相互運用性です。 アプリケーションは、どんな取引の異形(例えば、HTTP)もない多くの通信規約を使用することを願って、非常に異種のアプリケーション環境で配布されるかもしれません。
In summary, transactions greatly simplify the programming of distributed applications, and the 2-pc protocol is a key transactional technology. Current 2-pc protocols only offer transaction semantics to a limited set of applications, operating
概要では、トランザクションは分配されたアプリケーションのプログラミングを大いに簡素化します、そして、2-pcプロトコルは主要な取引の技術です。 現在の2-pcプロトコルはアプリケーション、限られたセットの作動にトランザクション意味論を提供するだけです。
Evans, et. al. Informational [Page 2] RFC 2372 TIP Requirements and Supplemental Information July 1998
etエヴァンス、アル。 情報[2ページ]のRFC2372チップ要件と補足的情報1998年7月
within a special-purpose (complex, homogeneous) infrastructure, using a particular set of intercommunication protocols. The restrictions thus imposed by current 2-pc protocols limits the widespread use of the transaction paradigm, thereby inhibiting the development of new distributed business applications.
特定のセットの相互通信プロトコルを使用する専用(複雑で、均質の)であるインフラストラクチャの中で。 その結果、制限は現在の2-pcプロトコル限界によるトランザクションパラダイムの普及使用を課しました、その結果、新しい分配されたビジネス・アプリケーションの開発を抑制します。
(See [2] for more information re transactions, atomicity, and two- phase commit protocols in general.)
(トランザクションに関して詳しい情報、最小単位、および2フェーズのための[2]が一般に、プロトコルを遂行するのを見てください。)
2. The Transaction Internet Protocol (TIP)
2. トランザクションインターネットプロトコル(チップ)
TIP is a 2-pc protocol which is intended to provide ubiquitous distributed transaction support, in a heterogeneous (networked) environment. TIP removes the restrictions of current 2-pc protocols and enables the development of new distributed business applications.
TIPは異種(ネットワークでつながれる)の環境に遍在している分配されたトランザクションサポートを提供することを意図する2-pcプロトコルです。 TIPは現在の2-pcプロトコルの制限を取り除いて、新しい分配されたビジネス・アプリケーションの開発を可能にします。
This goal is achieved primarily by satisfying two key requirements:
この目標は主として2つの主要な要件を満たすことによって、達成されます:
1) Keep the protocol simple (yet functionally sufficient). If the
protocol is complex it will not be widely deployed or quickly
adopted. Simplicity also means suitability to a wide range of
application environments.
1) 簡単に(まだ機能上十分な)プロトコルを保ってください。 プロトコルが複雑であるなら、それは、広く配布もされませんし、すぐに採用もされないでしょう。 また、簡単さはさまざまなアプリケーション環境への適合を意味します。
2) Enable the protocol to be used with any applications
communications protocol (e.g. HTTP). This ensures heterogeneous
environments can participate in distributed work.
2) プロトコルがどんなアプリケーション通信規約(例えば、HTTP)と共にも使用されるのを可能にしてください。 これは、異機種混在環境が分配された仕事に参加できるのを確実にします。
TIP does not reinvent the 2-pc protocol itself, the well-known presumed-abort 2-pc protocol is used as a basis. Rather the novelty and utility of TIP is in its separation from the application communications protocol (the two-pipe model).
TIPは2-pcプロトコル自体を再発明しないで、よく知られる推定されたアボート2-pcプロトコルは基礎として使用されます。 むしろTIPの目新しさとユーティリティは分離アプリケーション通信規約(2パイプのモデル)からの中です。
+-------------+ Application Communication +-------------+
| Application |---------------------------| Application |
| Program | "Pipe 1" | Program |
+-------------+ +-------------+
| |
| TIP TM API TIP TM API |
| |
+-----------------+ TIP 2-pc Protocol +-----------------+
| TIP Transaction |-----------------------| TIP Transaction |
| Manager | "Pipe 2" | Manager |
+-----------------+ +-----------------+
+-------------+ アプリケーションコミュニケーション+-------------+ | アプリケーション|---------------------------| アプリケーション| | プログラム| 「1インチを運んでください」| プログラム| +-------------+ +-------------+ | | | チップTm APIチップTm API| | | +-----------------+ チップ2-pcプロトコル+-----------------+ | チップトランザクション|-----------------------| チップトランザクション| | マネージャ| 「2インチを運んでください」| マネージャ| +-----------------+ +-----------------+
Fig 1: The two-pipe nature of TIP
図1: TIPの2パイプの自然
Evans, et. al. Informational [Page 3] RFC 2372 TIP Requirements and Supplemental Information July 1998
etエヴァンス、アル。 情報[3ページ]のRFC2372チップ要件と補足的情報1998年7月
3. Scope
3. 範囲
TIP does not describe how business transactions or electronic commerce are to be conducted on the internet, it specifies only the 2-pc transaction protocol (which is an aid in the development of such applications). e.g. TIP does not provide a mechanism for non- repudiation. Such protocols might be a subject for subsequent IETF activity, once the requirements for general electronic commerce are better understood. TIP does not preclude the later definition of these protocols.
TIPはインターネットで行われる企業取引か電子商取引がことである方法を説明しないで、それは2-pcトランザクションプロトコル(そのようなアプリケーションの開発で援助である)だけを指定します。例えば、TIPは非拒否にメカニズムを提供しません。 一般的な電子商取引のための要件がいったん理解されているほうがよいと、そのようなプロトコルはその後のIETF活動のための対象であるかもしれません。 TIPはこれらのプロトコルの後の定義を排除しません。
TIP does not specify Application Programming Interfaces (note that an example TIP TM API is included in this document (Appendix A), as an aid to understanding).
TIPはApplication Programming Interfaces(理解への援助として例のTIP TM APIが本書では(付録A)含まれていることに注意する)を指定しません。
4. Anticipated Usage of TIP
4. チップの予期された用法
As described above, transactions are a very useful tool in simplifying the programming of distributed applications. TIP is therefore targeted at any application that involves distributed work. Such applications may comprise components executing within a single system, across a corporate intranet, across the internet, or any other distributed system configuration. The application may be of "enterprise" class (requiring high-levels of performance and availability), or be less demanding. TIP is intended to be generally applicable, meeting the requirements of any application type which would benefit from the provision of transaction semantics.
上で説明されるように、トランザクションは分配されたアプリケーションのプログラミングを簡素化することにおいて非常に役に立つツールです。 したがって、TIPは分配された仕事にかかわるどんなアプリケーションのときにも狙います。 そのようなアプリケーションは直径のただ一つのシステムの中で企業イントラネットを実行するコンポーネントを包括するかもしれません、インターネット、またはいかなる他の分散システム構成の向こう側にも。 アプリケーションは、「企業」のクラス(高いレベルの性能を必要として、有用性)があるか、またはそれほど過酷でないかもしれません。 一般に、TIPが適切であることを意図します、トランザクション意味論の支給の利益を得るどんなアプリケーションタイプに関する必要条件も満たして。
5. TIP Compliant Systems
5. 対応するシステムをくつがえしてください。
There are two classes of TIP compliant Transaction Manager system:
TIP対応することのTransactionマネージャシステムの2つのクラスがあります:
1) Client-only systems. Those which provide an application
interface to demarcate TIP transactions, but which do not offer
access to local recoverable resources. Such a lightweight
implementation is useful for systems which host client
applications only (e.g. desktop machines). Such client systems may
be unreliable, and are not appropriate as transaction coordinators
(their unavailability might cause resources on other transaction
participant systems to remain locked and unavailable). These so-
called "volatile client" systems therefore delegate the
responsibility to coordinate the transaction (and recover from
failures), to other "full" (server) TIP system implementations.
For these lightweight systems, only the TIP IDENTIFY, BEGIN,
COMMIT, and ABORT commands are needed; no transaction log is
required.
1) クライアントだけシステムTIPトランザクションを画定するためにアプリケーション・インターフェースを提供しますが、ローカルの回復可能なリソースへのアクセスを提供しないもの。 そのような軽量の実装はクライアントアプリケーション(例えば、デスクトップマシン)だけを主催するシステムの役に立ちます。 そのようなクライアントシステムは、頼り無いかもしれなく、トランザクションコーディネータとして適切ではありません(彼らの使用不能で、他のトランザクション関係者システムに関するリソースはロックされていて入手できないままで残るかもしれません)。 したがって、そのように「揮発性のクライアント」システムと呼ばれるこれらはトランザクションを調整する責任を代表として派遣します(障害を修復してください)、他の「完全である」(サーバ)に TIPシステムの実現。 これらの軽量のシステムにおいて、TIP IDENTIFY、BEGIN、COMMIT、およびABORTコマンドだけが必要です。 取引ログは全く必要ではありません。
Evans, et. al. Informational [Page 4] RFC 2372 TIP Requirements and Supplemental Information July 1998
etエヴァンス、アル。 情報[4ページ]のRFC2372チップ要件と補足的情報1998年7月
2) Server systems. Those which offer the above support, plus TIP
transaction coordination and recovery services. These systems may
also provide access to recoverable resources (e.g. relational
databases). Server systems support all TIP commands, and provide a
recoverable transaction log.
2) サーバシステム上のサポート、TIPトランザクションコーディネート、およびリカバリーサービスを提供するもの。 また、これらのシステムは回復可能なリソース(例えば、関係型データベース)へのアクセスを提供するかもしれません。 サーバシステムは、すべてのTIPコマンドをサポートして、回復可能な取引ログを提供します。
A TIP compliant Transaction Manager (TM), will also supply application programming interfaces to demarcate transactions (e.g. the X/Open TX interface [3]), plus commands to generate TIP URLs, to PUSH/PULL TIP transactions, and to set the current TIP transaction context. TIP support can be added to TMs with existing APIs and 2-pc protocols, and transactions may comprise both proprietary and TIP transaction branches (it is assumed existing TM implementations will provide "TIP gateway" facilities which will coordinate between TIP and other transaction protocols).
TIP対応することのTransactionマネージャ(TM)、また、トランザクションを画定するようにインタフェースにプログラムしながら、アプリケーションを供給するでしょう。(例えば、X/Openテキサスのインタフェース[3])、およびPUSH/PULL TIPトランザクションへのURLをTIPに生成して、現在のTIPトランザクション背景を設定するコマンド。 既存のAPIと2-pcプロトコルでTIPサポートをTMsに加えることができます、そして、トランザクションは独占である状態で両方を包括するかもしれません、そして、TIPトランザクションは分岐します(既存のTM実装がTIPと他のトランザクションの間で調整される「TIPゲートウェイ」施設にプロトコルを提供すると思われます)。
6. Relationship to the X/Open DTP Model
6. X/Open DTPモデルとの関係
The X/Open Distributed Transaction Processing (DTP) Model [4] defines four components: 1) Application Program (AP), 2) Transaction Manager (TM), 3) Resource Manager (RM), and 4) Communications Resource Manager (CRM). In this model, TIP defines a TM to TM interoperability protocol, which is independent of application communications (there is no such equivalent protocol specified by X/Open, where all transaction and application communication occurs between CRMs (the one-pipe model)). Programmatic interfaces between the AP and TM/RM are unaffected by, and may be used with TIP. The TM to RM interaction is defined via the X/Open XA interface specification [5]. TIP is compatible with XA, and a TIP transaction may comprise applications accessing multiple RMs where the XA interface is being used to coordinate the RM transaction branches.
X/Open Distributed Transaction Processing(DTP)モデル[4]は4つのコンポーネントを定義します: 1) アプリケーション・プログラム(AP)、2) トランザクションマネージャ(TM)、3) 資源管理プログラム(RM)、および4) コミュニケーション資源管理プログラム(CRM)。 このモデルでは、TIPはTM相互運用性プロトコルへのTMを定義します(すべてのトランザクションとアプリケーションコミュニケーションがCRMs(1パイプのモデル)の間に現れるX/Openによって指定されたそのようなどんな同等なプロトコルもありません)。(TMはアプリケーションコミュニケーションから独立しています)。 APとTM/RMとのプログラムに従ったインタフェースは、影響を受けなく、TIPと共に使用されるかもしれません。 RM相互作用へのTMはX/Open XAインターフェース仕様[5]で定義されます。 TIPはXAと互換性があります、そして、TIPトランザクションはXAインターフェースがRMトランザクションブランチを調整するのに使用されている複数のRMsにアクセスするアプリケーションを包括するかもしれません。
7. Example TIP Usage Scenario
7. 例のチップ用法シナリオ
It is expected that a typical internet usage of TIP will involve applications using the agency model. In this model, the client node itself is not directly involved in the TIP protocol at all, and does not need the services of a local TIP TM. Instead, an agency (server) application handles the dialogue with the client, and is responsible for the coordination of the TIP transaction. The agency works with other service providers to deliver the service to the client. e.g. as a Travel Agency acts as an intermediate between airlines/hotels/etc and the customer. A big benefit of this model is that the agency is trusted by the service providers, and there are fewer such agencies (compared to user clients), so issues of security and performance are reduced.
TIPの典型的なインターネット使用法が政府機関モデルを使用することでアプリケーションを伴うと予想されます。 このモデルでは、クライアントノード自体は、直接全くTIPプロトコルにかかわらないで、また地方のTIP TMのサービスを必要としません。 代わりに、政府機関(サーバ)アプリケーションは、クライアントと共に対話を扱って、TIPトランザクションのコーディネートに原因となります。 政府機関は、クライアントに対するサービスを提供するために他のサービスプロバイダーと共に働いています。例えば、aとして、Travel Agencyは航空会社/ホテル/などと顧客の間の中間介在物として務めます。 このモデルの大きい利益は政府機関がサービスプロバイダーによって信じられて、より少ないそのような政府機関があるので(ユーザクライアントと比べて)セキュリティと性能の問題が減少するということです。
Evans, et. al. Informational [Page 5] RFC 2372 TIP Requirements and Supplemental Information July 1998
etエヴァンス、アル。 情報[5ページ]のRFC2372チップ要件と補足的情報1998年7月
Consider a Travel Agency example. A client running a web browser on a network PC accesses the Travel Agency web page. Via pages served up by the agency (which may in turn be constructed from pages provided by the airline and hotel servers), the client creates an itinerary involving flights and hotel choices. Finally, the client clicks the "make reservation" button. At this point the following sequence of events occurs (user-written application code is invoked by the various web servers, via any of the standard or proprietary techniques available (e.g. CGI)):
Travel Agencyの例を考えてください。 ウェブブラウザをネットワークPCに車で送るクライアントはTravel Agencyウェブページにアクセスします。 政府機関(航空会社によって提供されたページとホテルのサーバから順番に組み立てられるかもしれない)によって供給されたページで、クライアントは飛行とホテルの選択にかかわる旅程を作成します。 最終的に、クライアントは「予約をしてください」というボタンをクリックします。 ここに、イベントの以下の系列は起こります(ユーザによって書かれた応用コードが様々なウェブサーバーによって呼び出されます、利用可能な標準の、または、独占であるテクニック(例えば、CGI)のどれかを通して):
1) The travel agency begins a local transaction, and gets a TIP URL
for this transaction (both of these functions are performed using
the API of the local TM. e.g. "tip_xid_to_url()" would return the
TIP URL for the local transaction). The TIP URL contains the
listening endpoint IP address of the local TM and the transaction
identifier of the local transaction.
1) これらの機能の両方が、地方のTMのAPIを使用することで実行されます。旅行代理店は、地方のトランザクションを始めて、このトランザクションのためにTIP URLを手に入れます(例えば、「_url()へのチップ_xid_」は地方のトランザクションのためにTIP URLを返すでしょう)。 TIP URLは地方のTMの聴取終点IPアドレスと地方のトランザクションに関するトランザクション識別子を含んでいます。
2) The travel agency application sends a request to the airline
server (via some protocol (e.g. HTTP)), requesting the
"book_flight" service, passing the flights selected by the client,
and the TIP URL (obtained in 1. above).
2) 旅行代理店アプリケーションはエアラインサーバ(何らかのプロトコル(例えば、HTTP)を通した)に要求を送ります、「本_飛行」サービスを要求して、クライアント、およびTIP URL(1では、上で得る)によって選択された飛行を通過して。
3) The request is received by the airline server which invokes the
book_flight application. This application retrieves the TIP URL
from the input data, and passes this on a "tip_pull()" API request
to its local TM. The tip_pull() function causes the following to
occur:
3) 本_飛行アプリケーションを呼び出すエアラインサーバは要求を受け取ります。 このアプリケーションは、入力データからTIP URLを検索して、地方のTMへの「チップ_牽引力()」API要求にこれを移ります。 チップ_牽引力の()機能で、以下は起こります:
a. the local TM creates a local transaction (under which the
work will be performed),
a. 地方のTMは地方のトランザクション(仕事がそこで行われる)を作成します。
b. if a TIP connection does not already exist to the superior
(travel agency) TM (as identified via the IP address passed in
the TIP URL), one is created and an IDENTIFY exchange occurs
(if multiplexing is to be used on the connection, this is
followed by a MULTIPLEX exchange),
b. TIP接続が既に優れた(旅行代理店)TMに存在していないなら(TIP URLで通過されたIPアドレスで特定されるように)、1つは作成されて、IDENTIFY交換は起こります(マルチプレクシングが接続のときに使用されることであるなら、MULTIPLEX交換はこれのあとに続いています)。
c. a PULL command is sent to the superior TM,
c. PULLコマンドを優れたTMに送ります。
d. in response to the PULL, the superior TM associates the
subordinate (airline) TM with the transaction (by associating
the connection with the transaction), and sends a PULLED
response to the subordinate TM,
d. PULLに対応して、優れたTMはトランザクション(トランザクションとの関係を関連づけるのによる)に下位(エアライン)のTMを関連づけて、PULLED応答を下位のTMに送ります。
e. the subordinate TM returns control to the book_flight
application, which is now executing in the context of the newly
created local transaction.
e. 下位のTMは本_飛行アプリケーションにコントロールを返します。(現在、それは、新たに作成された地方のトランザクションの文脈で実行です)。
Evans, et. al. Informational [Page 6] RFC 2372 TIP Requirements and Supplemental Information July 1998
etエヴァンス、アル。 情報[6ページ]のRFC2372チップ要件と補足的情報1998年7月
4) The book_flight application does its work (which may involve
access to a recoverable resource manager (e.g. an RDBMS), in which
case the local TM will associate the RM with the local transaction
(via the XA interface or whatever)).
4) 本_飛行アプリケーションは仕事します(地方のTMがそうするどのケースが地方のトランザクションにRMを関連づけるかに(XAインターフェースか何でもを通した)回復可能な資源管理プログラム(例えば、RDBMS)へのアクセスにかかわるかもしれません)。
5) The book_flight application returns to the travel agency
application indicating success.
5) 本_飛行アプリケーションは成功を示す旅行代理店アプリケーションに戻ります。
6) Steps 2-5 are then repeated with the hotel server "book_room"
application. At the conclusion of this, the superior TM has
registered two subordinate TMs as participants in the transaction,
there are TIP connections between the agency TM and the airline
and hotel TMs, and there are inflight transactions at the airline
and hotel servers. [Note that steps 2-5 and 6 could be performed
in parallel.]
6) そして、ステップ2-5はホテルのサーバ「本_余地」アプリケーションで繰り返されます。 この結論のときに、トランザクションの関係者、政府機関TMと、エアラインとホテルのTMsの間には、TIP接続があって、エアラインとホテルのサーバに不飛行トランザクションがあるとき、優れたTMは2下位のTMsを登録しました。 [平行でステップ2-5と6を実行できたことに注意してください。]
7) The travel agency application issues a "commit transaction"
request (using the API of the local TM). The local TM sends a
PREPARE command on the TIP connections to the airline and hotel
TMs (as these are registered as subordinate transaction
participants).
7) 旅行代理店アプリケーションは「トランザクションを遂行してください」という要求を出します(地方のTMのAPIを使用して)。 地方のTMはTIP接続のPREPAREコマンドをエアラインとホテルのTMsに送ります(これらが下位のトランザクション関係者として登録されるとき)。
8) The TMs at the airline and hotel servers perform the
necessary steps to prepare their local recoverable resources (e.g.
by issuing xa_prepare() requests). If successful, the subordinate
TMs change their TIP transaction state to Prepared, and log
recovery information (e.g. local and superior transaction branch
identifiers, and the IP address of the superior TM). The
subordinate TMs then send PREPARED commands to the superior TM.
8) エアラインとホテルのサーバにおけるTMsは、地元の回復可能なリソースを準備するために必要なステップを実行します(例えば、xa_を発行することによって、() 要求を用意してください)。 うまくいくなら、下位のTMsは彼らのTIPトランザクション状態をPrepared、およびログ回復情報(例えば、ローカルの、そして、優れたトランザクションブランチ識別子、および優れたTMのIPアドレス)に変えます。 そして、下位のTMsは優れたTMへのコマンドをPREPAREDに送ります。
9) If both subordinates respond PREPARED, the superior TM logs that
the transaction is Committed, with recovery information (e.g.
local and subordinate transaction identifiers, and subordinate TM
IP addresses). The superior TM then sends COMMIT commands on the
two subordinate TIP connections.
9) 両方の部下であるならPREPAREDを反応させてください、トランザクションは優れたTMログですが。回復情報があるCommitted(例えば、地方の、そして、下位のトランザクション識別子、および下位のTM IPアドレス)。 そして、優れたTMは2つの下位のTIP接続のときにコマンドをCOMMITに送ります。
10) The TMs at the airline and hotel servers perform the
necessary steps to commit their local recoverable resources (e.g.
by issuing xa_commit() requests). The subordinate TMs forget the
transaction. The subordinate TMs then send COMITTED commands to
the superior TM.
10) エアラインとホテルのサーバにおけるTMsは、地元の回復可能なリソースを遂行するために必要なステップを実行します(例えば、xa_を発行することによって、() 要求を遂行してください)。 下位のTMsはトランザクションを忘れます。 そして、下位のTMsは優れたTMへのコマンドをCOMITTEDに送ります。
11) The superior TM forgets the transaction. The TIP connections
between the superior and subordinate TMs return to Idle state
(not associated with any transaction). The superior TM returns
success to the travel agency application "commit transaction"
request.
11) 優れたTMはトランザクションを忘れます。 優れて下位のTMsの間のTIP接続はIdle状態(どんなトランザクションにはも、交際しない)に戻ります。 優れたTMは「トランザクションを遂行してください」が要求する旅行代理店の申込み書に成功を返します。
Evans, et. al. Informational [Page 7] RFC 2372 TIP Requirements and Supplemental Information July 1998
etエヴァンス、アル。 情報[7ページ]のRFC2372チップ要件と補足的情報1998年7月
12) The travel agency application returns "reservation made" to the
client.
12) 旅行代理店アプリケーションは「された予約」をクライアントに返します。
This example illustrates the use of PULL. If PUSH were to be used instead, events 2) and 3) above would change as follows:
この例はPULLの使用を例証します。 PUSHが代わりに使用されることになっているなら、上のイベント2と)3)は以下の通り変化するでしょうに:
2) The travel agency application:
2) 旅行代理店アプリケーション:
a. passes the TIP URL obtained in 1. above, together with the
listening endpoint address of the TM at the airline server, to
its local TM via a "tip_push()" API request. The tip_push()
function causes the following to occur:
a. TIP URLがTMの聴取終点アドレスと共に上でエアラインサーバで地方のTMに「チップ_プッシュ()」API要求で1で入手したパス。 チップ_プッシュ()機能で、以下は起こります:
i. if a TIP connection does not already exist to the
subordinate (airline server) TM (as identified via the IP
address passed on the tip_push), one is created and an
IDENTIFY exchange occurs (if multiplexing is to be used on
the connection, this is followed by a MULTIPLEX exchange),
i. TIP接続が既に下位(エアラインサーバ)のTMに存在していないなら(チップ_プッシュで通過されたIPアドレスで特定されるように)、1つは作成されて、IDENTIFY交換は起こります(マルチプレクシングが接続のときに使用されることであるなら、MULTIPLEX交換はこれのあとに続いています)。
ii. a PUSH command is sent to the subordinate TM,
ii PUSHコマンドを下位のTMに送ります。
iii. in response to the PUSH, the subordinate TM creates a
local transaction, associates this transaction with the
connection, and sends a PUSHED response to the superior
TM,
iii PUSHに対応して、下位のTMは地方のトランザクションを作成して、このトランザクションを接続に関連づけて、PUSHED応答を優れたTMに送ります。
iv. in response to the PUSHED response, the superior TM
associates the subordinate TM with the transaction,
iv PUSHED応答に対応して、優れたTMは下位のTMをトランザクションに関連づけます。
v. the superior TM returns control to the travel agency
application.
v. 優れたTMは旅行代理店アプリケーションにコントロールを返します。
b. the travel agency application sends a request to the airline
server (via some protocol (e.g. HTTP)), requesting the
"book_flight" service, passing the flights selected by the
client, and the TIP URL (obtained in 1 above).
b. 旅行代理店アプリケーションはエアラインサーバ(何らかのプロトコル(例えば、HTTP)を通した)に要求を送ります、「本_飛行」サービスを要求して、クライアント、およびTIP URL(上の1では、得る)によって選択された飛行を通過して。
3) The request is received by the airline server which invokes the
book_flight application. This application retrieves the TIP URL
from the input data, and passes this on a "tip_pull()" API request
to its local TM. Since the local TM has already "seen" this URL
(it was already pushed), it simply returns to the book_flight
application, which is now executing in the context of the
previously created local transaction.
3) 本_飛行アプリケーションを呼び出すエアラインサーバは要求を受け取ります。 このアプリケーションは、入力データからTIP URLを検索して、地方のTMへの「チップ_牽引力()」API要求にこれを移ります。 地方のTMが既にこのURLを「見た」ので(それは既に押されました)、それは単に本_飛行アプリケーションに戻ります。(現在、それは、以前に作成された地方のトランザクションの文脈で実行です)。
Evans, et. al. Informational [Page 8] RFC 2372 TIP Requirements and Supplemental Information July 1998
etエヴァンス、アル。 情報[8ページ]のRFC2372チップ要件と補足的情報1998年7月
[Note that although in this example the transaction coordinator role is performed by a node which is also a participant in the transaction (the Travel Agency), other configurations are possible (e.g. where the transaction coordinator role is performed by a non-participant 3rd-party node).]
[トランザクションコーディネータの役割がこの例でまたトランザクション(Travel Agency)の関係者であるノードによって実行されますが、他の構成が可能であることに(例えば、どこで、トランザクションコーディネータの役割は非関係者3番目のパーティーノードによって実行されますか)注意してください。]
8. TIP Transaction Recovery
8. チップトランザクションリカバリ
Until the transaction reaches the Prepared state, any failure results in the transaction being aborted. If an error occurs once the transaction has reached the Prepared state, then transaction recovery must be performed. Recovery behaviour is different for superior and subordinate; the details depend upon the outcome of the transaction (committed or aborted), and the precise point at which failure occurs.
トランザクションがPrepared状態に達するまで、どんな失敗も中止されるトランザクションをもたらします。 トランザクションがいったんPrepared状態に達すると誤りが発生するなら、トランザクションリカバリを実行しなければなりません。 回復のふるまいは、上司にとって異なって下位です。 詳細はトランザクション(遂行されるか、または中止される)の結果、および失敗が起こる正確なポイントに依存します。
In the travel agency application for example, if the connection to the hotel server fails before the COMMIT command has been received by the hotel TM, then (once the connection is restored):
例えば、旅行代理店アプリケーションでは、ホテルのサーバとの接続が以前失敗するなら、COMMITコマンドはホテルのTMによって受け取られました、そして(接続がいったん復元されると):
1) The superior (travel agency) TM sends a RECONNECT command
(passing the subordinate transaction identifier (recovered from
the transaction log if necessary)).
1) 上司(旅行代理店) TMはRECONNECTコマンド(下位のトランザクション識別子(必要なら、取引ログを取り戻す)を通過する)を送ります。
2) The subordinate (hotel) TM responds RECONNECTED (since it never
received the COMMIT command, and still has the transaction in
Prepared state (if the failure had occurred after the subordinate
had responded COMMITTED, then the subordinate would have forgotten
the transaction, and responded NOTRECONNECTED to the RECONNECT
command)).
2) 部下(ホテル) TMはRECONNECTEDを反応させます(COMMITコマンドを決して受け取らないで、Prepared状態にまだトランザクションを持っているので(部下がCOMMITTEDを反応させた後に失敗が起こったなら、部下は、トランザクションを忘れて、RECONNECTコマンドにNOTRECONNECTEDを反応させたでしょうに))。
3) The superior TM sends a COMMIT command. The subordinate TM
commits the transaction and responds COMMITTED. The transaction is
now resolved.
3) 優れたTMはCOMMITコマンドを送ります。 下位のTMはトランザクションを遂行して、COMMITTEDを反応させます。 トランザクションは現在、決議されています。
4) If the subordinate TM restores the connection to the superior TM
before receiving a RECONNECT command, then it may send a QUERY
command. In this case, the superior TM will respond QUERIEDEXISTS,
and the subordinate TM should wait for the superior to send a
RECONNECT command. If the transaction had been aborted, then the
superior may respond QUERIEDNOTFOUND, in which case the
subordinate should abort the transaction (note that the superior
is not obliged to send a RECONNECT command for an aborted
transaction (i.e. it could just forget the transaction after
sending ABORT and before receiving an ABORTED response)).
4) RECONNECTコマンドを受け取る前に下位のTMが優れたTMに接続を復元するなら、それはQUERYコマンドを送るかもしれません。 この場合、優れたTMはQUERIEDEXISTSについて応答するでしょう、そして、下位のTMは上司がRECONNECTコマンドを送るのを待つはずです。 トランザクションが中止されたなら、上司はQUERIEDNOTFOUNDを反応させるかもしれません、その場合、部下がトランザクションを中止するべきです(上司が中止になっているトランザクションのためのRECONNECTコマンドを送るのが強いられないことに注意してください(ABORTを送った後とABORTED応答を受ける前に、すなわち、それはただトランザクションを忘れるかもしれません))。
Evans, et. al. Informational [Page 9] RFC 2372 TIP Requirements and Supplemental Information July 1998
etエヴァンス、アル。 情報[9ページ]のRFC2372チップ要件と補足的情報1998年7月
There are failure circumstances in which the client application (the one calling "commit") may not receive a response indicating the final outcome of the transaction (even though the transaction itself is successfully completed). This is a common problem, and one not unique to TIP. In such circumstances, it is up to the application to ascertain the final outcome of the transaction (a TIP TM may facilitate this by providing some implementation specific mechanism. e.g. writing the outcome to a user-log).
クライアントアプリケーション(「公約してください」と呼ぶもの)がトランザクションの最終的な結果を示す応答を受けないかもしれない失敗事情があります(取引自体は首尾よく完了されますが)。 これは、共有する問題と、TIPにユニークでない1つです。 そのような事情では、トランザクションの最終的な結果を確かめるのはアプリケーションまで達しています(TIP TMは. 例えば、aに結果を書くとユーザと同じくらい登録される何らかの実装の特定のメカニズムを提供することによって、これを容易にするかもしれません)。
9. TIP Transaction and Application Message Serialisation
9. チップトランザクションとアプリケーションメッセージ連載
A relationship exists between TIP commands and application messages: a TIP transaction must not be committed until it is certain that all participants have properly registered, and have finished work on the transaction. Because of the two-pipe nature of TIP, this behaviour cannot necessarily be enforced by the TIP system itself (although it may be possible in some implementations). It is therefore incumbent upon the application to behave properly. Generally, an application must not:
関係はTIPコマンドとアプリケーションメッセージの間に存在しています: すべての関係者が適切に登録して、トランザクションに対する仕事を終えたのが、確かになるまで、TIPトランザクションを遂行してはいけません。 TIPの2パイプの自然のために、必ずTIPシステム自体でこのふるまいを励行されることができるというわけではありません(それはいくつかの実装で可能であるかもしれませんが)。 したがって、アプリケーションのときに、礼儀正しく振る舞うのは現職です。 一般に、アプリケーションはそうしてはいけません:
1) call it's local TMs "commit" function when it has any requests
associated with the transaction still outstanding.
1) トランザクションがまだ傑出していた状態で、どんな要求もあるとき、それが地方のTMsが「公約する」という機能であるという要求は交際しました。
2) positively respond to a transactional request from a partner
application prior to having registered it's local TM with the
transaction.
2) トランザクションで明確に登録する前のパートナーアプリケーションからのそれが地方のTMであるという取引の要求に応じてください。
10. TIP Protocol and Local Actions
10. チッププロトコルと地方の動き
In order to ensure that transaction atomicity is properly guaranteed, a system implementing TIP must perform other local actions at certain points in the protocol exchange. These actions pertain to the creation and deletion of transaction "log-records" (the necessary information which survives failures and ensures that transaction recovery is correctly executed). The following information regarding the relationship between the TIP protocol and logging events is advisory, and is not intended to be definitive (see [2] for more discussion on this subject):
トランザクション最小単位が適切に保証されるのを確実にするために、TIPを実装するシステムはある一定のポイントでプロトコル交換で他の地方の動きを実行しなければなりません。 これらの動作はトランザクション「ログ記録」の作成と削除に関係します(失敗を乗り切っていて、そのトランザクションリカバリを確実にする必要事項は正しく実行されます)。 TIPプロトコルと伐採イベントとの関係の以下の情報は、顧問であり、決定的であることを意図しません(この問題についての、より多くの議論のための[2]を見ます):
1) before sending a PREPARED response, the system should create
a prepared-recovery-record for the transaction.
1) PREPARED応答を送る前に、システムはトランザクションのための準備された回復記録を作成するはずです。
2) having created a prepared-recovery-record, this record should not
be deleted until after:
a. an ABORT message is received; or
b. a COMMIT message is received; or
c. a QUERIEDNOTFOUND response is received.
2) 準備された回復記録を作成したので、以下の後までこの記録を削除するべきではありません。 a. ABORTメッセージは受信されています。 または、b. COMMITメッセージは受信されています。 または、c. QUERIEDNOTFOUND応答は受け取られています。
Evans, et. al. Informational [Page 10] RFC 2372 TIP Requirements and Supplemental Information July 1998
etエヴァンス、アル。 情報[10ページ]のRFC2372チップ要件と補足的情報1998年7月
3) the system should not send a COMMITTED or NOTRECONNECTED message
if a prepared-recovery-record exists.
3) 準備された回復記録が存在しているなら、システムはCOMMITTEDかNOTRECONNECTEDメッセージを送るはずがありません。
4) before creating a commit-recovery-record for the transaction, the
system should have received a PREPARED response.
4) トランザクションのために回復記録を遂行している作成aの前に、システムはPREPARED応答を受けるはずでした。
5) before sending a COMMIT message in Prepared state, the system
should have created a commit-recovery-record for the transaction.
5) Prepared状態でCOMMITメッセージを送る前に、システムはトランザクションのために回復記録を遂行していた状態でaを作成するはずでした。
6) having created a commit-recovery-record, this record should not be
deleted until after:
a. a COMMITTED message is received; or
b. a NOTRECONNECTED message is received.
6) aを作成したので、回復記録を遂行してください、そして、以下の後までこの記録を削除するべきではありません。 a. COMMITTEDメッセージは受信されています。 または、b. NOTRECONNECTEDメッセージは受信されています。
11. Security Considerations
11. セキュリティ問題
The means by which applications communicate and perform distributed work are outside the scope of the TIP protocol. The mechanisms used for authentication and authorisation of clients to access programs and information on a particular system are part of the application communications protocol and the application execution infrastructure. Use of the TIP protocol does not affect these considerations.
TIPプロトコルの範囲の外にアプリケーションが分配された仕事を伝えて、する手段があります。 クライアントの認証と認可が特定のシステムのプログラムと情報にアクセスするのに使用されるメカニズムはアプリケーション通信規約とアプリケーション実行インフラストラクチャの一部です。 TIPプロトコルの使用はこれらの問題に影響しません。
Security relates to the TIP protocol itself inasmuch that systems require to protect themselves from the receipt of unauthorised TIP commands, or the impersonation of a trusted partner TIP TM. Probably the worst consequence of this is the possibility of undetected data inconsistency resulting from violations of the TIP commitment protocol (e.g. a COMMIT command is injected on a TIP connection in place of an ABORT command). TIP uses the Transport Layer Security protocol [6] to restrict access to only trusted partners (i.e. to control from which remote endpoints TIP transactions will be accepted, and to verify that an end-point is genuine), and to encrypt TIP commands. Usage of TLS (or not) is negotiated between partner TIP TMs. See [1] for details of how TLS is used with TIP.
セキュリティはシステムが権限のないTIPコマンドの領収書、または信頼されている相手TIP TMのものまねから我が身をかばうのを必要とするinasmuchをTIPプロトコル自体に関係づけます。 たぶんこの最も悪い結果はTIP委任プロトコルの違反から生じる非検出されたデータ矛盾の可能性(例えばCOMMITコマンドはTIP接続のときにABORTコマンドに代わって注入される)です。 TIPは、アクセスを信頼されている相手だけ(すなわち、TIPトランザクションがどの遠く離れた終点から受け入れられるかを制御して、それについて確かめるために、エンドポイントは本物です)に制限して、TIPコマンドを暗号化するのにTransport Layer Securityプロトコル[6]を使用します。 TLS (or not)の使用法はパートナーTIP TMsの間で交渉されます。TLSがTIPと共にどう使用されるかに関する詳細のための[1]を見てください。
TIP TM implementations will also likely provide local means to time- out and abort transactions which have not completed within some time period (thereby preventing unavailability of resources due to malicious intent). Transaction time-out also serves as a means of deadlock resolution.
TIP TM実装は、また、時間までおそらくローカルの手段を外に提供して、いつか中で期間を完成していないトランザクションを中止するでしょう(その結果、悪意がある意図のためリソースの使用不能を防ぎます)。 また、トランザクションタイムアウトはデッドロック解決の手段として機能します。
12. TIP Requirements
12. チップ要件
Most of these requirements stem from the primary objective of making transactions a ubiquitous system service, available to all application classes (much as TCP may be assumed to be available everywhere). In general this requires imposing as few restrictions
これらの要件の大部分はトランザクションを遍在しているシステムサービスにする主目的によります、すべてのアプリケーションのクラスに、利用可能です(いたる所でTCPが利用可能であると思われるかもしれないように)。 一般に、これは、同じくらいわずかな制限しか課すのを必要としません。
Evans, et. al. Informational [Page 11] RFC 2372 TIP Requirements and Supplemental Information July 1998
etエヴァンス、アル。 情報[11ページ]のRFC2372チップ要件と補足的情報1998年7月
regarding the use of TIP as possible (applications should not be required to execute in some "special" environment in order to use transactions), and keeping the protocol simple and efficient. This enables the widespread implementation of TIP (it's cheap to do), on a wide range of systems (it's cheap to run).
TIPの使用が可能であると(トランザクションを使用するためにいくつかの「特別番組」で環境を実行するためにアプリケーションを必要とするべきではありません)みなして、簡単で効率的にプロトコルを保ちます。 これはTIPの広範囲の実装を可能にします(するのは安いです)、さまざまなシステムの上で(稼働するのは安いです)。
1) Application Communications Protocol Independence
1) アプリケーション通信規約独立
The TIP protocol must be defined independently of the
communications protocol used for transferring application data, to
allow TIP usage in conjunction with any application protocol. It
must be possible for applications using arbitrary communications
protocols to begin, end, and propagate TIP transactions.
どんなアプリケーション・プロトコルに関連してTIPに用法を許容するためにアプリケーションデータを移すのに使用される通信規約の如何にかかわらずTIPプロトコルを定義しなければなりません。 任意の通信規約を使用するアプリケーションに、TIPトランザクションを始めて、終わって、伝播するのは可能であるに違いありません。
This implies that the TIP protocol employ a 2-pipe model of
operation. This model requires the separation of application
communications and transaction coordination, into two discrete
communication channels (pipes). This separation enables the use of
the transaction coordination protocol (TIP), with any application
communications protocol (e.g. HTTP, ODBC, plain TCP/UDP, etc).
これは、TIPプロトコルが操作の2パイプのモデルを雇うのを含意します。 このモデルは2つの離散的な通信チャネル(パイプ)にアプリケーションコミュニケーションとトランザクションコーディネートの分離を必要とします。 この分離はトランザクションコーディネートプロトコル(TIP)の使用を可能にします、どんなアプリケーション通信規約(例えば、HTTP、ODBC、明瞭なTCP/UDPなど)でも。
2) Support for Transaction Semantics
2) トランザクション意味論のサポート
The TIP protocol must provide the functionality of the de-facto
standard presumed-abort 2-pc protocol, to guarantee transactional
atomicity even in the event of failure. It should provide a means
to construct the transaction tree, as well as provide commitment
and recovery functions.
TIPプロトコルは、失敗の場合さえ、取引の最小単位を保証するためにデファクトの標準の推定されたアボート2-pcプロトコルの機能性を提供しなければなりません。 それは、トランザクション木を組み立てる手段を提供して、委任と回復機能を提供するべきです。
3) Application Transaction Propagation and Interoperability
3) アプリケーショントランザクション伝播と相互運用性
In order to facilitate protocol independence, application
interoperability, and provide a means for TIP transaction context
propagation, a standard representation of the TIP transaction
context information is required (in the form of a URL). This
information must include the listening endpoint address of the
partner TIP TM, and transaction identifier information.
プロトコル独立、アプリケーション相互運用性を容易にして、TIPトランザクション文脈伝播のための手段を提供するために、TIPトランザクション文脈情報の標準の表現が必要です(1つのURLの形で)。 この情報はパートナーTIP TM、およびトランザクション識別子情報の聴取終点アドレスを含まなければなりません。
4) Ease of Implementation
4) 実装の容易さ
The TIP protocol must be simple to implement. It should support
only those features necessary to provide a useful, performant 2-pc
protocol service. The protocol should not add complexity in the
form of extraneous optimisations.
TIPプロトコルは実装するのが簡単であるに違いありません。 それは役に立つperformant 2-pcプロトコルサービスを提供するのに必要なそれらの特徴だけをサポートするべきです。 プロトコルは異質な最適化の形で複雑さを加えるべきではありません。
Evans, et. al. Informational [Page 12] RFC 2372 TIP Requirements and Supplemental Information July 1998
etエヴァンス、アル。 情報[12ページ]のRFC2372チップ要件と補足的情報1998年7月
5) Suitability for All Application Classes
5) すべてのアプリケーションのクラスへの適合
The TIP protocol should be complete and robust enough not only for
electronic commerce on the web, but also for intranet applications
and for traditional TP applications spanning heterogenous
transaction manager environments. The protocol should be
performant and scaleable enough to meet the needs of low to very
high throughput applications.
TIPプロトコルは、完全であって、イントラネットアプリケーションとheterogenousトランザクションマネージャ環境にかかる伝統的なTPアプリケーションにも、ウェブにおける電子商取引だけに強健であるのではなく、十分強健であるべきです。 プロトコルは、非常に高いスループットアプリケーションを安値の需要を満たすほどperformantであってスケーラブルであるべきです。
a. the TIP protocol should support the concept of client-only
transaction participants (useful for ultra-lightweight
implementations on low-end platforms).
a. TIPプロトコルはクライアントだけトランザクション関係者(超-ライト級実装のローエンドプラットホームで役に立つ)の概念をサポートするべきです。
b. since some clients may be unreliable, TIP must provide support
for delegation of transaction coordination (to a more reliable
(trusted) node).
b. 何人かのクライアントが頼り無いかもしれないので、TIPはトランザクションコーディネート(より信頼できる(信じられる)ノードへの)の委譲のサポートを提供しなければなりません。
c. the TIP protocol must scale between 1 and n (> 1) concurrent
transactions per TCP connection.
c. TIPプロトコルはTCP接続あたり1とn(>1)同時発生のトランザクションの間で比例しなければなりません。
d. TIP commands should be able to be concatenated (pipelined).
d。 TIPコマンドは連結できるべきです(pipelinedしました)。
e. TIP should be compatible with the X/Open XA interface.
e。 TIPはX/Open XAインターフェースと互換性があるべきです。
6) Security
6) セキュリティ
The TIP protocol must be compatible with existing security
mechanisms, potentially including encryption, firewalls, and
authorization mechanisms (e.g. TLS may be used to authenticate the
sender of a TIP command, and for encryption of TIP commands).
Nothing in the protocol definition should prevent TIP working
within any security environment.
TIPプロトコルは既存のセキュリティー対策と互換性があるに違いありません、潜在的に暗号化、ファイアウォール、および承認メカニズムを含んでいて(例えば、TLSはTIPコマンドの送付者を認証するのに使用される、およびTIPコマンドの暗号化のためのものであるかもしれません)。 プロトコル定義における何も、TIPがどんな治安環境の中でも働いているのを防ぐべきではありません。
7) TIP Protocol Transport Independence
7) チッププロトコル輸送独立
It would be beneficial to some applications to allow the TIP
protocol to flow over different transport protocols. The benefit
is when using different transport protocols for the application
data, the same transport can be used for the TIP 2PC protocol. TIP
must therefore not preclude use with other transport protocols.
いくつかのアプリケーションに、TIPプロトコルが異なったトランスポート・プロトコルの上を流れるのを許容するのは有益でしょう。 利益はアプリケーションデータに異なったトランスポート・プロトコルを使用して、TIP 2PCプロトコルに同じ輸送を使用できる時です。 したがって、TIPは他のトランスポート・プロトコルによる使用を排除してはいけません。
8) Recovery
8) 回復
Recovery semantics need to be defined sufficiently to avoid
ambiguous results in the event of any type of communications
transport failure.
どんなタイプに関するコミュニケーションの場合も、あいまいな結果を避けることができるくらい定義されるべき回復意味論の必要性は失敗を輸送します。
Evans, et. al. Informational [Page 13] RFC 2372 TIP Requirements and Supplemental Information July 1998
etエヴァンス、アル。 情報[13ページ]のRFC2372チップ要件と補足的情報1998年7月
9) Extensibility
9) 伸展性
The TIP protocol should be able to be extended, whilst maintaining
compatibility with previous versions.
TIPプロトコルは旧バージョンとの互換性を維持している間、広げることができるべきです。
References
参照
[1] Lyon, J., Evans, K., and J. Klein, "The Transaction Internet
Protocol Version 3.0", RFC 2371, July 1998.
[1] リヨン、J.、エヴァンス、K.、およびJ.クライン、「トランザクションインターネットプロトコルバージョン3インチ、RFC2371、1998年7月。」
[2] Transaction Processing: Concepts and Techniques. Morgan
Kaufmann Publishers. (ISBN 1-55860-190-2). J. Gray, A. Reuter.
[2]トランザクション処理: 概念とテクニック。 モーガンコフマン出版社。 (ISBN1-55860-190-2。) J。 グレー、A.ロイター通信。
[3] X/Open CAE Specification, April 1995, Distributed Transaction
Processing: The TX Specification. (ISBN 1-85912-094-6).
[3] X/Open CAE仕様(1995年4月)はトランザクション処理を広げました: テキサス仕様。 (ISBN1-85912-094-6。)
[4] X/Open Guide, November 1993, Distributed Transaction Processing:
Reference Model Version 2. (ISBN 1-85912-019-9).
[4] X/Openのガイド(1993年11月)はトランザクション処理を広げました: 規範モデルバージョン2。 (ISBN1-85912-019-9。)
[5] X/Open CAE Specification, December 1991, Distributed Transaction
Processing: The XA Specification. (ISBN 1-872630-24-3).
[5] X/Open CAE仕様(1991年12月)はトランザクション処理を広げました: XA仕様。 (ISBN1-872630-24-3。)
[6] Dierks, T., et. al., "The TLS Protocol Version 1.0", Work in
Progress.
et[6]Dierks、T.、アル、「TLSはバージョン1インチ、処理中の作業について議定書の中で述べます」。
Evans, et. al. Informational [Page 14] RFC 2372 TIP Requirements and Supplemental Information July 1998
etエヴァンス、アル。 情報[14ページ]のRFC2372チップ要件と補足的情報1998年7月
Authors' Addresses
作者のアドレス
Keith Evans Tandem Computers Inc, LOC 252-30 5425 Stevens Creek Blvd Santa Clara, CA 95051-7200, USA
キースエヴァンスタンデムコンピューターズInc、LOC252-30 5425スティーブンス・クリークBlvdサンタクララ、カリフォルニア95051-7200(米国)
Phone: +1 (408) 285 5314 Fax: +1 (408) 285 5245 EMail: Keith.Evans@Tandem.Com
以下に電話をしてください。 +1 (408)285 5314Fax: +1(408) 285 5245はメールされます: Keith.Evans@Tandem.Com
Johannes Klein Tandem Computers Inc. 10555 Ridgeview Court Cupertino, CA 95014-0789, USA
Ridgeview法廷カルパチーノ、ジョハネス・クラインタンデム・コンピューターズ10555カリフォルニア95014-0789(米国)
Phone: +1 (408) 285 0453 Fax: +1 (408) 285 9818 EMail: Johannes.Klein@Tandem.Com
以下に電話をしてください。 +1 (408)285 0453Fax: +1(408) 285 9818はメールされます: Johannes.Klein@Tandem.Com
Jim Lyon Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399, USA
ジムリヨンマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052-6399、米国
Phone: +1 (206) 936 0867 Fax: +1 (206) 936 7329 EMail: JimLyon@Microsoft.Com
以下に電話をしてください。 +1 (206)936 0867Fax: +1(206) 936 7329はメールされます: JimLyon@Microsoft.Com
Comments
コメント
Please send comments on this document to the authors at <JimLyon@Microsoft.Com>, <Keith.Evans@Tandem.Com>, <Johannes.Klein@Tandem.Com>, or to the TIP mailing list at <Tip@Tandem.Com>. You can subscribe to the TIP mailing list by sending mail to <Listserv@Lists.Tandem.Com> with the line "subscribe tip <full name>" somewhere in the body of the message.
Please send comments on this document to the authors at <JimLyon@Microsoft.Com>, <Keith.Evans@Tandem.Com>, <Johannes.Klein@Tandem.Com>, or to the TIP mailing list at <Tip@Tandem.Com>. あなたがメール to <Listserv@Lists.Tandem.Com を送ることによってTIPメーリングリストに加入できる、gt;、メッセージ欄のどこかの系列による、「チップ<フルネームの>を申し込んでください。」
Evans, et. al. Informational [Page 15] RFC 2372 TIP Requirements and Supplemental Information July 1998
etエヴァンス、アル。 情報[15ページ]のRFC2372チップ要件と補足的情報1998年7月
Appendix A. An Example TIP Transaction Manager Application Programming
Interface.
例のチップトランザクションマネージャアプリケーションプログラミングが連結する付録A.。
Note that this API is included solely for informational purposes, and is not part of the formal TIP specification (TIP conformant implementations are free to define alternative APIs).
このAPIが唯一情報の目的のために含まれていて、正式なTIP仕様(TIP conformant実装は自由に代替のAPIを定義できる)の一部でないことに注意してください。
1) tip_open() - establish a connection to a TIP TM.
Synopsis
int tip_open ([out] tip_handle_t *ptiptm)
Parameters
ptiptm [out]
Pointer to the TIP TM handle.
Description
tip_open() establishes a connection to a TIP TM. The call
returns a handle which identifies the TIP TM. This function
must be called before any work can be performed on a TIP
transaction.
1) チップ_戸外() - TIP TMに取引関係を築いてください。 構文intチップ_戸外([out]チップ_ハンドル_t*ptiptm) TIP TMハンドルへのパラメタptiptm [out]指針。 記述チップ_戸外()はTIP TMに取引関係を築きます。 呼び出しはTIP TMを特定するハンドルを返します。 どんな仕事もTIPトランザクションにできる前にこの機能を呼ばなければなりません。
Return Values
[TIPOK]
Connection has been successfully established.
[TIPNOTCONNECTED]
User has been disconnected from the TIP TM.
[TIPNOTCONFIGURED]
TIP TM has not been configured.
[TIPTRANSIENT]
Too many openers; re-try the open.
[TIPERROR]
An unexpected error occurred.
リターンValues[TIPOK]接続は首尾よく確立されました。 [TIPNOTCONNECTED]ユーザTIP TMから切断されました。 [TIPNOTCONFIGURED]TIP TMは構成されていません。 [TIPTRANSIENT] あまりに多くのオープナー。 戸外を再試行してください。 [TIPERROR] 予期せぬエラーは起こりました。
2) tip_close() - close a connection to a TIP TM.
Synopsis
int tip_close([in] tip_handle_t handle)
Parameters
handle [in]
The TIP TM handle.
Description
tip_close() closes a connection to a TIP TM. All outstanding
requests associated with that connection will be cancelled.
Return Values
[TIPOK]
Connection has been successfully closed.
[TIPINVALIDPARM]
Invalid connection handle specified.
[TIPERROR]
An unexpected error occurred.
2) チップ_閉鎖() - 接続をTIP TMに終えてください。 構文intチップ_閉鎖([in]チップ_ハンドル_tハンドル) パラメタはTIP TMが扱う[in]を扱います。 記述チップ_閉鎖()は接続をTIP TMに終えます。 その接続に関連しているすべての傑出している要求が中止されるでしょう。 リターンValues[TIPOK]接続は首尾よく閉店しました。 [TIPINVALIDPARM]無効の接続ハンドルは指定しました。 [TIPERROR] 予期せぬエラーは起こりました。
Evans, et. al. Informational [Page 16] RFC 2372 TIP Requirements and Supplemental Information July 1998
etエヴァンス、アル。 情報[16ページ]のRFC2372チップ要件と補足的情報1998年7月
3) tip_push() - export a local transaction to a remote node and
return a TIP transaction identifier for the
associated remote transaction.
Synopsis
int tip_push ([in] tip_handle_t TM,
[in] char *tm_url,
[in] void *plocal_xid,
[out] char *pxid_url,
[in] unsigned int url_length)
Parameters
TM [in]
The TIP TM handle.
tm_url [in]
Pointer to the TIP URL of the remote transaction manager.
A TIP URL for a transaction manager takes the form:
TIP://<host>[:<port>]
plocal_xid [in]
Pointer to the local transaction identifier. The
structure of the transaction identifier is defined by the
local transaction manager.
pxid_url [out]
Pointer to the TIP URL of the associated remote
transaction. A TIP URL for a transaction takes the form:
TIP://<host>[:<port>]/<transaction identifier>
url_length [in]
The size in bytes of the buffer for the remote
transaction URL.
Description
tip_push() exports (pushes) a local transaction to a remote
node. If a local transaction identifier is not supplied, the
caller's current transaction context is used. The call returns
a TIP URL for the associated remote transaction. The TIP
transaction identifier may be passed on application requests to
the remote node (as part of a TIP URL). The receiving process
uses this information in order to do work on behalf of the
transaction.
Return Values
[TIPOK]
Transaction has been successfully pushed to the remote
node.
[TIPINVALIDXID]
An invalid transaction identifier has been provided.
[TIPNOCURRENTTX]
Process is currently not associated with a transaction
(and none was supplied).
[TIPINVALIDHANDLE]
Invalid connection handle specified.
[TIPNOTPUSHED]
3) チップ_プッシュ() - 遠隔ノードとリターンへの地方のトランザクションが関連リモートトランザクションのためのTIPトランザクション識別子であるとエクスポートしてください。 TM、[in]炭*のtm_url、[in]空間*plocal_xid、[out]が*pxid_urlを炭にするという構文intチップ_プッシュ([in]チップ_ハンドル_t、[in]の未署名のint url_の長さ) パラメタTM [in]TIP TMは. tm_url [in]指針をリモートトランザクションマネージャのTIP URLに扱います。 トランザクションマネージャのためのTIP URLは形を取ります: ローカルのトランザクション識別子へのTIP://<ホスト>[: <ポート>]plocal_xid [in]指針。 トランザクション識別子の構造は地元のトランザクションマネージャによって定義されます。. 関連リモートトランザクションのTIP URLへのpxid_url [out]指針。 トランザクションのためのTIP URLは形を取ります: TIP://<は>[: <ポート>]/<トランザクション識別子>url_長さの[in]を接待します。リモートトランザクションURLのためのバイトに関するバッファのサイズ。 記述チップ_プッシュ()は地方のトランザクションを遠隔ノードにエクスポートします(押します)。 ローカルのトランザクション識別子が提供されないなら、訪問者の経常取引背景は使用されています。 呼び出しは関連リモートトランザクションのためにTIP URLを返します。 TIPトランザクション識別子はアプリケーション要求のときに遠隔ノードに通過されるかもしれません(TIP URLの一部として)。 受信プロセスは、トランザクションを代表して働くのにこの情報を使用します。 首尾よくリターンValues[TIPOK]トランザクションを遠隔ノードに押してあります。 [TIPINVALIDXID] 無効のトランザクション識別子を提供しました。 [TIPNOCURRENTTX]プロセスは現在、トランザクションに関連づけられません(なにも供給されませんでした)。 [TIPINVALIDHANDLE]無効の接続ハンドルは指定しました。 [TIPNOTPUSHED]
Evans, et. al. Informational [Page 17] RFC 2372 TIP Requirements and Supplemental Information July 1998
etエヴァンス、アル。 情報[17ページ]のRFC2372チップ要件と補足的情報1998年7月
Transaction could not be pushed to the remote node.
[TIPNOTCONNECTED]
Caller has been disconnected from the TIP TM.
[TIPINVALIDURL]
Invalid endpoint URL is provided.
[TIPTRANSIENT]
Transient error occurred; re-try the operation.
[TIPTRUNCATED]
Insufficient buffer size is specified for the TIP
transaction identifier.
[TIPERROR]
An unexpected error occurred.
遠隔ノードにトランザクションを押すことができませんでした。 [TIPNOTCONNECTED]訪問者TIP TMから切断されました。 [TIPINVALIDURL]無効の終点URLを提供します。 [TIPTRANSIENT]一時的エラーは起こりました。 操作を再試行してください。 [TIPTRUNCATED]不十分なバッファサイズはTIPトランザクション識別子に指定されます。 [TIPERROR] 予期せぬエラーは起こりました。
4) tip_pull() - create a local transaction and join it with the TIP
transaction.
Synopsis
int tip_pull([in] tip_handle_t TM,
[in] char *pxid_url,
[out] void *plocal_xid,
[in] unsigned int xid_length)
Parameters
TM [in]
The TIP TM handle.
pxid_url [in]
Pointer to the TIP URL of the associated remote
transaction. A TIP URL for a transaction takes the form:
TIP://<host>[:<port>]/<transaction identifier>
plocal_xid [out]
Pointer to the local transaction identifier. The
structure of the transaction identifier is defined by the
local transaction manager.
xid_length [in]
The size in bytes of the buffer for the local transaction
identifier.
Description
tip_pull() creates a local transaction and joins the local
transaction with the TIP transaction (the caller becomes a
subordinate participant in the TIP transaction). The remote TIP
TM is identified via the URL (*pxid_url). The local transaction
identifier is returned. If a local transaction has already been
created for the TIP transaction identifier supplied, then
[TIPOK] is returned (with the local transaction identifier),
and no other action is taken.
Return Values
[TIPOK]
The local transaction has been successfully created
and joined with the TIP transaction.
[TIPINVALIDHANDLE]
4) チップ_牽引力() - 地方のトランザクションを作成してください、そして、TIPトランザクションにそれを接合してください。 構文intチップ_牽引力の([in]チップ_ハンドル_t TM、[in]炭*pxid_url、[out]空間*plocal_xid、[in]の未署名のint xid_長さ) パラメタTM [in]TIP TMは. pxid_url [in]指針を関連リモートトランザクションのTIP URLに扱います。 トランザクションのためのTIP URLは形を取ります: ローカルのトランザクション識別子へのTIP://<ホスト>[: <ポート>]/<トランザクション識別子>plocal_xid [out]指針。 トランザクション識別子の構造は地元のトランザクションマネージャ. xid_長さの[in]によって定義されます。ローカルのトランザクション識別子のためのバイトに関するバッファのサイズ。 記述チップ_牽引力()は、地方のトランザクションを作成して、地方のトランザクションをTIPトランザクションに接合します(訪問者はTIPトランザクションの下位の関係者になります)。 URL(*pxid_url)でリモートTIP TMは特定されます。 ローカルのトランザクション識別子を返します。 提供されたTIPトランザクション識別子のために既に地方のトランザクションを作成したなら、[TIPOK]を返します、そして、(ローカルのトランザクション識別子で)他の行動を全く取りません。 地方のリターンValues[TIPOK]トランザクションを、TIPトランザクションに首尾よく作成されて、接合してあります。 [TIPINVALIDHANDLE]
Evans, et. al. Informational [Page 18] RFC 2372 TIP Requirements and Supplemental Information July 1998
etエヴァンス、アル。 情報[18ページ]のRFC2372チップ要件と補足的情報1998年7月
Invalid connection handle specified.
[TIPTRUNCATED]
Insufficient buffer size is specified for the local
transaction identifier.
[TIPNOTPULLED]
Joining of the local transaction with the TIP
transaction has failed.
[TIPNOTCONNECTED]
Caller has been disconnected from the TIP TM.
[TIPINVALIDURL]
Invalid URL has been supplied.
[TIPTRANSIENT]
Transient error occurred; retry the operation.
[TIPERROR]
An unexpected error occurred.
無効の接続ハンドルは指定しました。 [TIPTRUNCATED]不十分なバッファサイズはローカルのトランザクション識別子に指定されます。 TIPトランザクションとの地方のトランザクションの[TIPNOTPULLED]接合は失敗しました。 [TIPNOTCONNECTED]訪問者TIP TMから切断されました。 [TIPINVALIDURL]無効のURLを供給しました。 [TIPTRANSIENT]一時的エラーは起こりました。 操作を再試行してください。 [TIPERROR] 予期せぬエラーは起こりました。
5) tip_pull_async() - create a local transaction and join it with the
TIP transaction. Control is returned to the
caller as soon as a local transaction is
created.
Synopsis
int tip_pull_async ([in] tip_handle_t TM
[in] char *pxid_url,
[out] void *plocal_xid,
[in] unsigned int xid_length)
Parameters
TM [in]
The TIP gateway handle.
pxid_url [in]
Pointer to the TIP URL of the associated remote
transaction. A TIP URL for a transaction takes the form:
TIP://<host>[:<port>]/<transaction identifier>
plocal_xid [out]
Pointer to the local transaction identifier. The
structure of the transaction identifier is defined by the
local transaction manager.
xid_length [in]
The size in bytes of the buffer for the local transaction
identifier.
Description
tip_pull_async() creates a local transaction and joins the
local transaction with the TIP transaction (the caller
becomes a subordinate participant in the TIP transaction). The
remote TIP TM is identified via the URL (*pxid_url). The local
transaction identifier is returned. A call to tip_pull_async()
returns immediately after the local transaction has been
created (before the TIP PULL protocol command is sent). A
subsequent call to tip_pull_complete() must be issued to check
5) _牽引力_async()をくつがえしてください。 - 地方のトランザクションを作成してください、そして、TIPトランザクションにそれを接合してください。 地方のトランザクションが作成されるとすぐに、コントロールを訪問者に返します。 構文intチップ_牽引力の_async ([in]チップ_ハンドル_t TM [in]炭*のpxid_url、[out]空間*plocal_xid、[in]の未署名のint xid_長さ) パラメタTM [in]、TIPゲートウェイは. pxid_url [in]指針を関連リモートトランザクションのTIP URLに扱います。 トランザクションのためのTIP URLは形を取ります: ローカルのトランザクション識別子へのTIP://<ホスト>[: <ポート>]/<トランザクション識別子>plocal_xid [out]指針。 トランザクション識別子の構造は地元のトランザクションマネージャ. xid_長さの[in]によって定義されます。ローカルのトランザクション識別子のためのバイトに関するバッファのサイズ。 記述チップ_牽引力の_async()は地方のトランザクションを作成して、地方のトランザクションをTIPトランザクションに接合します(訪問者はTIPトランザクションの下位の関係者になります)。 URL(*pxid_url)でリモートTIP TMは特定されます。 ローカルのトランザクション識別子を返します。 _async()が地方のトランザクション直後返す牽引力の_をくつがえすという要求を作成してあります(TIP PULLプロトコルコマンドを送る前に)。 _チェックするために完全な()を発行しなければならない牽引力の_をくつがえすというその後の要求
Evans, et. al. Informational [Page 19] RFC 2372 TIP Requirements and Supplemental Information July 1998
etエヴァンス、アル。 情報[19ページ]のRFC2372チップ要件と補足的情報1998年7月
for successful completion of the pull request.
Return Values
[TIPOK]
The local transaction has been successfully created.
[TIPINVALIDHANDLE]
Invalid connection handle specified.
[TIPNOTCONNECTED]
User has been disconnected from the TIP TM.
[TIPINVALIDURL]
Invalid URL has been supplied.
[TIPTRANSIENT]
Transient error has occurred; retry the operation.
[TIPTRUNCATED]
Insufficient buffer size is specified for the local
transaction identifier.
[TIPERROR]
An unexpected error occurred.
牽引力の要求の無事終了のために。 首尾よく地方のリターンValues[TIPOK]トランザクションを作成してあります。 [TIPINVALIDHANDLE]無効の接続ハンドルは指定しました。 [TIPNOTCONNECTED]ユーザTIP TMから切断されました。 [TIPINVALIDURL]無効のURLを供給しました。 [TIPTRANSIENT]一時的エラーは起こりました。 操作を再試行してください。 [TIPTRUNCATED]不十分なバッファサイズはローカルのトランザクション識別子に指定されます。 [TIPERROR] 予期せぬエラーは起こりました。
6) tip_pull_complete() - check whether a previous tip_pull_async()
request has been successfully completed.
Synopsis
int tip_pull_complete ([in] tip_handle_t TM,
[in] void *plocal_xid)
Parameters
TM [in]
The TIP TM handle.
plocal_xid [in]
Pointer to the local transaction identifier. The
structure of the transaction identifier is defined by the
local transaction manager.
Description
tip_pull_complete() checks whether a previous call to
tip_pull_async() has been successfully completed. i.e. whether
the local transaction has been successfully joined with the TIP
transaction. The caller supplies the local transaction
identifier returned by the previous call to tip_pull_async().
Repeated calls to tip_pull_complete() for the same local
transaction identifier are idempotent.
Return Values
[TIPOK]
The local transaction has been successfully joined with
the TIP transaction.
[TIPINVALIDHANDLE]
Invalid connection handle specified.
[TIPINVALIDXID]
An invalid transaction identifier has been provided.
[TIPNOTPULLED]
Joining of the local transaction with the TIP transaction
6) チップ_牽引力の_完全な() - 前のチップ_牽引力の_async()要求が首尾よく終了したかどうかチェックしてください。 _構文intチップ_牽引力の完全な([in]_tチップ_ハンドルTM、[in]空間*plocal_xid) パラメタTM [in]TIP TMは. plocal_xid [in]指針をローカルのトランザクション識別子に扱います。 トランザクション識別子の構造は地元のトランザクションマネージャによって定義されます。 _牽引力_async()をくつがえすという前の要求が首尾よく終了したか否かに関係なく、記述チップ_は_完全な()チェックを引きます。すなわち、地方のトランザクションが首尾よくそうかどうかがTIPトランザクションと一緒になりました。 _をくつがえすという前の要求でローカルのトランザクション識別子が返した訪問者供給は_async()を引きます。 _同じローカルのトランザクション識別子のための牽引力の_完全な()をくつがえすという繰り返された要求はベキ等元です。 首尾よく地方のリターンValues[TIPOK]トランザクションをTIPトランザクションに接合してあります。 [TIPINVALIDHANDLE]無効の接続ハンドルは指定しました。 [TIPINVALIDXID] 無効のトランザクション識別子を提供しました。 TIPトランザクションとの地方のトランザクションの[TIPNOTPULLED]接合
Evans, et. al. Informational [Page 20] RFC 2372 TIP Requirements and Supplemental Information July 1998
etエヴァンス、アル。 情報[20ページ]のRFC2372チップ要件と補足的情報1998年7月
has failed. The local transaction has been aborted.
[TIPNOTCONNECTED]
Caller has been disconnected from the TIP TM.
[TIPERROR]
An unexpected error occurred.
失敗しました。 地方のトランザクションは中止されました。 [TIPNOTCONNECTED]訪問者TIP TMから切断されました。 [TIPERROR] 予期せぬエラーは起こりました。
7) tip_xid_to_url() - return a TIP transaction identifier for a local
transaction identifier.
Synopsis
int tip_xid_to_url ([in] tip_handle_t TM,
[in] void *plocal_xid,
[out] char *pxid_url,
[in] unsigned int url_length)
Parameters
TM [in]
The TIP TM handle.
plocal_xid [in]
Pointer to the local transaction identifier. The
structure of the transaction identifier is defined by the
local transaction manager.
pxid_url [out]
Pointer to the TIP URL of the local transaction.
A TIP URL for a transaction takes the form:
TIP://<host>[:<port>]/<transaction identifier>
url_length [in]
The size in bytes of the buffer for the TIP URL.
Description
tip_xid_to_url() returns a TIP transaction identifier for a
local transaction identifier. The TIP transaction identifier
can be passed to remote applications to enable them to do work
on the transaction. e.g. to pull the local transaction to the
remote node. If a local transaction identifier is not supplied,
the caller's current transaction context is used. The constant
TIPURLSIZE defines the size of a TIP transaction identifier in
bytes. This value is implementation specific.
Return Values
[TIPOK]
TIP transaction identifier has been returned.
[TIPNOTCONNECTED]
Caller has been disconnected from the TIP TM.
[TIPNOCURRENTTX]
Process is currently not associated with a transaction
(and none was supplied).
[TIPINVALIDXID]
An invalid local transaction identifier has been
supplied.
[TIPTRUNCATED]
Insufficient buffer size is specified for the TIP
7) _url()へのチップ_xid_ - ローカルのトランザクション識別子のためのTIPトランザクション識別子を返してください。 _url ([in]チップ_ハンドル_t TMへの構文intチップ_xid_、[in]空間*plocal_xid、[out]炭*のpxid_url、[in]の未署名のint url_長さ) パラメタTM [in]TIP TMは. plocal_xid [in]指針をローカルのトランザクション識別子に扱います。 トランザクション識別子の構造は地元のトランザクションマネージャによって定義されます。. 地方のトランザクションのTIP URLへのpxid_url [out]指針。 トランザクションのためのTIP URLは形を取ります: TIP://<は>[: <ポート>]/<トランザクション識別子>url_長さの[in]を接待します。TIP URLのためのバイトに関するバッファのサイズ。 _url()への記述チップ_xid_はローカルのトランザクション識別子のためのTIPトランザクション識別子を返します。 トランザクションに取り組むのを可能にするリモートアプリケーションにTIPトランザクション識別子を通過できます。. 例えば地方のトランザクションを遠隔ノードに引くために。 ローカルのトランザクション識別子が提供されないなら、訪問者の経常取引背景は使用されています。 一定のTIPURLSIZEはバイトで表現されるTIPトランザクション識別子のサイズを定義します。 この値は実装特有です。 リターンValues[TIPOK]TIPトランザクション識別子を返しました。 [TIPNOTCONNECTED]訪問者TIP TMから切断されました。 [TIPNOCURRENTTX]プロセスは現在、トランザクションに関連づけられません(なにも供給されませんでした)。 [TIPINVALIDXID] 無効のローカルのトランザクション識別子を提供しました。 [TIPTRUNCATED]不十分なバッファサイズはTIPに指定されます。
Evans, et. al. Informational [Page 21] RFC 2372 TIP Requirements and Supplemental Information July 1998
etエヴァンス、アル。 情報[21ページ]のRFC2372チップ要件と補足的情報1998年7月
transaction identifier.
[TIPERROR]
An unexpected error occurred.
トランザクション識別子。 [TIPERROR] 予期せぬエラーは起こりました。
8) tip_url_to_xid() - return a local transaction identifier for a TIP
transaction identifier.
Synopsis
int tip_url_to_xid ([in] tip_handle_t TM,
[in] char *pxid_url,
[out] void *plocal_xid,
[in] unsigned int xid_length)
Parameters
TM [in]
The TIP TM handle.
pxid_url [in]
Pointer to the TIP URL of the local transaction. A TIP
URL for a transaction takes the form:
TIP://<host>[:<port>]/<transaction identifier>
plocal_xid [out]
Pointer to the local transaction identifier. The
structure of the transaction identifier is defined by the
local transaction manager.
xid_length [in]
The size in bytes of the buffer for the local transaction
identifier.
Description
tip_url_to_xid() returns a local transaction identifier for a
TIP transaction identifier (note that the local transaction
must have previously been created via a tip_push(), or tip_pull
(or tip_pull_async()). The constant TIPXIDSIZE defines the size
of a local transaction identifier in bytes. This value is
implementation specific.
Return Values
[TIPOK]
Local transaction identifier is returned.
[TIPINVALIDURL]
An invalid TIP transaction identifier has been provided.
[TIPTRUNCATED]
Insufficient buffer size is specified for the local
transaction identifier.
[TIPERROR]
An unexpected error occurred.
8) _xid()へのチップ_url_ - TIP取引識別子のためのローカルの取引識別子を返してください。 _xid ([in]チップ_ハンドル_t TMへの構文intチップ_url_、[in]炭*のpxid_url、[out]空間*plocal_xid、[in]の無記名のint xid_長さ) パラメタTM [in]TIP TMは. pxid_url [in]ポインタを地方の取引のTIP URLに扱います。 取引のためのTIP URLは形を取ります: ローカルの取引識別子へのTIP://<ホスト>[: <ポート>]/<取引識別子>plocal_xid [out]ポインタ。 取引識別子の構造は地元の取引マネージャ. xid_長さの[in]によって定義されます。ローカルの取引識別子のためのバイトに関するバッファのサイズ。 地方の取引が以前に、チップ_プッシュ()で作成されたに違いないか、またはチップ_が引かれることに注意してください。_xid()への記述チップ_url_がTIP取引識別子のためのローカルの取引識別子を返す、((または、_が_async())を引くという秘訣。 一定のTIPXIDSIZEはバイトで表現されるローカルの取引識別子のサイズを定義します。 この値は実現特有です。 リターンValues[TIPOK]のローカルの取引識別子を返します。 [TIPINVALIDURL] 無効のTIP取引識別子を提供しました。 [TIPTRUNCATED]不十分なバッファサイズはローカルの取引識別子に指定されます。 [TIPERROR] 予期せぬエラーは起こりました。
Evans, et. al. Informational [Page 22] RFC 2372 TIP Requirements and Supplemental Information July 1998
etエヴァンス、アル。 情報[22ページ]のRFC2372チップ要件と補足的情報1998年7月
9) tip_get_tm_url() - get the name of the local TIP transaction
manager in TIP URL form.
Synopsis
int tip_get_tm_url ([in] tip_handle_t TM,
[out] char *tm_url,
[in] int tm_len);
Parameters
TM[in]
The TIP TM handle.
tm_url [in]
Pointer to the TIP URL of the local transaction manager. A
TIP URL for a transaction manager takes the form:
TIP://<host>[:<port>]
tm_len [out]
The size in bytes of the buffer for the TIP URL of the local
transaction manager.
Description
tip_get_tm_url() gets the name of the local transaction
manager in TIP URL form (i.e. TIP://<host>[:<port>])
Return Values
[TIPOK]
The name of the local transaction manager has been
successfully returned.
[TIPTRUNCATED]
The name of the local transaction manager has been
truncated due to insufficient buffer size. Retry the
operation with larger buffer size.
9) チップ_は_tm_url()を手に入れます。 - TIP URLフォームで地元のTIP取引マネージャの名前を得てください。 _が__ハンドル_t TM、[out]炭の*が_url、[in] int tm_lenをtmするというtm_url ([in]の秘訣を得る構文intチップ)、。 パラメタTM[in]TIP TMは. tm_url [in]ポインタを地元の取引マネージャのTIP URLに扱います。 取引マネージャのためのTIP URLは形を取ります: TIP://<は>[: <ポート>]tm_len [out]を接待します。地元の取引マネージャのTIP URLのためのバイトに関するバッファのサイズ。 記述チップ_はtm_url()がTIP URLフォーム(すなわち、TIP://<ホスト>[: <ポート>])で地元の取引マネージャの名前を得る_を手に入れます。 地元の取引マネージャの名前が首尾よく返されたValues[TIPOK]を返してください。 [TIPTRUNCATED] 不十分なバッファサイズのため地元の取引マネージャの名前の先端を切ってあります。 大きめのバッファサイズで操作を再試行してください。
Evans, et. al. Informational [Page 23] RFC 2372 TIP Requirements and Supplemental Information July 1998
etエヴァンス、アル。 情報[23ページ]のRFC2372チップ要件と補足的情報1998年7月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Evans, et. al. Informational [Page 24]
etエヴァンス、アル。 情報[24ページ]
一覧
スポンサーリンク
