[要約] 要約：RFC 2372は、トランザクションインターネットプロトコル（TIP）の要件と補足情報を提供しています。 目的：TIPの実装と展開に関するガイドラインを提供し、信頼性と効率性の向上を促進します。
Network Working Group K. Evans
Request for Comments: 2372 J. Klein
Category: Informational Tandem Computers
J. Lyon
Microsoft
July 1998
Transaction Internet Protocol - Requirements and Supplemental Information
トランザクションインターネットプロトコル-要件と補足情報
Status of this Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントでは、トランザクションインターネットプロトコルの目的（使用シナリオ）と要件について説明します[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. TIPの予想される使用4 5. TIP準拠システム4 6. X / Open DTPモデルとの関係5 7. TIP使用シナリオの例5 8. TIPトランザクションの回復9 9. TIPトランザクションとアプリケーションメッセージのシリアル化10 10. TIPプロトコルとローカルアクション10 11.セキュリティに関する考慮事項11 12. TIP要件11参照14作成者のアドレス15コメント15 A. TIPトランザクションマネージャーAPIの例16完全な著作権ステートメント24
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つだけに減ります。つまり、すべての作業が正常に完了したか、どれも完了しなかった（この特性は原子性と呼ばれます）。したがって、プログラマーは多数の考えられる障害シナリオに対処する必要がないため、アプリケーションのプログラミングはそれほど複雑ではありません。通常、トランザクションのセマンティクスは、基盤となるシステムインフラストラクチャによって提供されます（通常、トランザクション処理モニターやデータベースなどの製品の形で）。このインフラストラクチャは障害に対処し、原子性の特性を保証するために必要な回復アクションを実行します。トランザクションを使用すると、不可能ではないにしても困難である、信頼性の高い分散アプリケーションの開発が可能になります。
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フェーズコミットプロトコル（2個）です。 2-pcプロトコルは商用トランザクション処理（TP）システムで長年使用されており、十分に理解されています（たとえば、LU6.2 2-pc（同期点）プロトコルは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プロトコルの両方が存在します。これらのプロトコルは通常、「ワンパイプ」モデルを採用しています。つまり、トランザクションプロトコルとアプリケーションプロトコルは緊密に統合され、同じ通信チャネル上で実行されます。アプリケーションは、トランザクションプロトコルに関連付けられた特定の通信メカニズムのみを使用できます。標準プロトコル（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 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プロトコルは主要なトランザクション技術です。現在の2 PCプロトコルは、特定の相互通信プロトコルセットを使用して、特殊な目的の（複雑で均一な）インフラストラクチャ内で動作する限られたアプリケーションセットにのみトランザクションセマンティクスを提供します。このように現在の2 PCプロトコルによって課されている制限は、トランザクションパラダイムの広範な使用を制限し、それによって新しい分散型ビジネスアプリケーションの開発を妨げています。
(See [2] for more information re transactions, atomicity, and two-phase commit protocols in general.)
（一般に、トランザクション、アトミック性、および2フェーズコミットプロトコルの詳細については、[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 |
+-----------------+ +-----------------+
Fig 1: The two-pipe nature of TIP
図1：TIPの2パイプの性質
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は、ビジネストランザクションまたは電子商取引がインターネット上でどのように行われるかについては説明していません。2PCトランザクションプロトコルのみを指定しています（これは、このようなアプリケーションの開発に役立ちます）。例えば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は、アプリケーションプログラミングインターフェイスを指定していません（TIP TM APIの例がこのドキュメント（付録A）に含まれていることに注意してください）。
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は一般的に適用可能であり、トランザクションセマンティクスの提供から利益を得るあらゆるアプリケーションタイプの要件を満たします。
There are two classes of TIP compliant Transaction Manager system:
TIP準拠のトランザクションマネージャーシステムには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コマンドのみが必要です。トランザクションログは必要ありません。
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準拠のトランザクションマネージャー（TM）は、トランザクションを区別するためのアプリケーションプログラミングインターフェイス（X / Open TXインターフェイス[3]など）に加えて、TIP URLを生成し、PUSH / PULL TIPトランザクションを実行し、現在のTIPトランザクションコンテキスト。 TIPサポートは、既存のAPIと2個のプロトコルを備えたTMに追加できます。トランザクションには、独自のトランザクションブランチとTIPトランザクションブランチの両方が含まれます（既存のTM実装は、TIPと他のトランザクションプロトコル間で調整する「TIPゲートウェイ」機能を提供すると想定されています）。 。
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分散トランザクション処理（DTP）モデル[4]は、4つのコンポーネントを定義します。1）アプリケーションプログラム（AP）、2）トランザクションマネージャー（TM）、3）リソースマネージャー（RM）、4）通信リソースマネージャー（CRM） ）。このモデルでは、TIPはTMからTMへの相互運用プロトコルを定義します。これは、アプリケーション通信とは無関係です（X / Openで指定された同等のプロトコルはなく、すべてのトランザクションとアプリケーション通信はCRM間で発生します（ワンパイプモデル））。 APとTM / RM間のプログラムインターフェイスは影響を受けず、TIPで使用できます。 TMとRMの相互作用は、X / Open XAインターフェース仕様[5]を介して定義されます。 TIPはXAと互換性があり、TIPトランザクションは、RMトランザクションブランチを調整するためにXAインターフェイスが使用されている複数のRMにアクセスするアプリケーションで構成される場合があります。
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トランザクションの調整を担当します。代理店は他のサービスプロバイダーと協力して、クライアントにサービスを提供します。例えば旅行代理店として、航空会社/ホテル/その他と顧客の間の仲介者として機能します。このモデルの大きな利点は、エージェンシーがサービスプロバイダーから信頼され、そのようなエージェンシーが（ユーザークライアントと比較して）少ないため、セキュリティとパフォーマンスの問題が軽減されることです。
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)):
旅行代理店の例を考えてみましょう。ネットワークPCでWebブラウザーを実行しているクライアントが、旅行代理店のWebページにアクセスします。代理店が提供するページ（航空会社とホテルのサーバーが提供するページから作成される場合があります）を介して、クライアントはフライトとホテルの選択を含む旅程を作成します。最後に、クライアントは「予約する」ボタンをクリックします。この時点で、次の一連のイベントが発生します（ユーザー作成のアプリケーションコードは、利用可能な標準または独自の手法（CGIなど）を介して、さまざまなWebサーバーによって呼び出されます）。
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）旅行代理店がローカルトランザクションを開始し、このトランザクションのTIP URLを取得します（これらの機能は両方ともローカルTMのAPIを使用して実行されます。たとえば、「tip_xid_to_url()」はローカルトランザクションの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）旅行代理店アプリケーションは、「book_flight」サービスをリクエストし、クライアントによって選択されたフライトとTIP URL（上記1.で取得）を渡して、リクエストを航空会社サーバーに送信します（プロトコル（HTTPなど）を介して）。
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）リクエストは、book_flightアプリケーションを呼び出す航空会社サーバーによって受信されます。このアプリケーションは、入力データからTIP URLを取得し、これを「tip_pull()」APIリクエストでローカルTMに渡します。 tip_pull()関数により、次のことが発生します。
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 URLで渡されたIPアドレスで識別される）上位（旅行代理店）TMへのTIP接続がまだ存在しない場合は、TIP接続が作成され、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は、新しく作成されたローカルトランザクションのコンテキストで実行されているbook_flightアプリケーションに制御を返します。
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）book_flightアプリケーションがその作業を実行します（これには、リカバリー可能なリソースマネージャー（RDBMSなど）へのアクセスが含まれる場合があります）。この場合、ローカルTMはRMをローカルトランザクションに関連付けます（XAインターフェースなど）。
5) The book_flight application returns to the travel agency application indicating success.
5）book_flightアプリケーションが旅行代理店アプリケーションに戻り、成功を示します。
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）次に、ホテルサーバーの「book_room」アプリケーションを使用して、手順2〜5を繰り返します。この結果、上位のTMは2つの下位のTMをトランザクションの参加者として登録し、代理店のTMと航空会社およびホテルのTMの間にはTIP接続があり、航空会社およびホテルのサーバーでは機内トランザクションがあります。 [ステップ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コマンドを航空会社およびホテルTMに送信します（これらは従属トランザクション参加者として登録されているため）。
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）航空会社およびホテルのサーバーのTMは、ローカルの回復可能なリソースを準備するために必要な手順を実行します（xa_prepare()要求を発行するなど）。成功した場合、下位のTMはTIPトランザクションの状態を準備済みに変更し、回復情報（ローカルと上位のトランザクションブランチ識別子、上位のTMのIPアドレスなど）をログに記録します。次に、下位のTMはPREPAREDコマンドを上位のTMに送信します。
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はトランザクションがコミットされたことをログに記録し、リカバリ情報（ローカルおよび下位のトランザクション識別子、および下位の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）航空会社とホテルのサーバーのTMは、ローカルの回復可能なリソースをコミットするために必要な手順を実行します（たとえば、xa_commit()要求を発行することによって）。下位のTMはトランザクションを忘れます。次に、下位のTMはCOMITTEDコマンドを上位のTMに送信します。
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はトランザクションを忘れます。上位TMと下位TM間のTIP接続は、アイドル状態に戻ります（トランザクションに関連付けられていません）。上位のTMは、旅行代理店アプリケーションの「トランザクションのコミット」リクエストに成功を返します。
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. 上記の1.で取得したTIP URLを、航空会社サーバーでのTMのリスニングエンドポイントアドレスとともに、「tip_push()」APIリクエストを介してローカルTMに渡します。 tip_push()関数により、以下が発生します。
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. 下位（航空会社サーバー）TMへのTIP接続がまだ存在しない場合（tip_pushで渡されるIPアドレスによって識別される）、TIP接続が作成され、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. 旅行代理店アプリケーションは、「book_flight」サービスを要求し、クライアントによって選択されたフライトとTIP URL（上記1で取得）を渡して、リクエストを航空会社サーバーに送信します（プロトコル（HTTPなど）を介して）。
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）リクエストは、book_flightアプリケーションを呼び出す航空会社サーバーによって受信されます。このアプリケーションは、入力データからTIP URLを取得し、これを「tip_pull()」APIリクエストでローカルTMに渡します。ローカルTMはすでにこのURLを「見た」（すでにプッシュされている）ため、以前に作成されたローカルトランザクションのコンテキストで実行されているbook_flightアプリケーションに戻るだけです。
[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).]
[この例では、トランザクションコーディネーターの役割はトランザクションの参加者でもあるノード（旅行代理店）によって実行されますが、他の構成も可能です（たとえば、トランザクションコーディネーターの役割が非参加者によって実行される場合）パーティノード）]
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状態になるまで、障害が発生するとトランザクションは中止されます。トランザクションが準備済み状態に達した後でエラーが発生した場合は、トランザクションのリカバリを実行する必要があります。回復動作は、上位と下位で異なります。詳細は、トランザクションの結果（コミットまたは中止）、および障害が発生する正確なポイントによって異なります。
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):
たとえば旅行代理店アプリケーションでは、ホテルのTMがCOMMITコマンドを受信する前にホテルのサーバーへの接続が失敗した場合（接続が復元されたら）、
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コマンドを送信します（下位トランザクションIDを渡します（必要に応じてトランザクションログから回復されます））。
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コマンドを受信したことがなく、トランザクションが準備済み状態であるため（部下が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）下位のTMがRECONNECTコマンドを受信する前に上位のTMへの接続を復元すると、QUERYコマンドが送信される場合があります。この場合、上位TMはQUERIEDEXISTSに応答し、下位TMは上位TMがRECONNECTコマンドを送信するのを待つ必要があります。トランザクションが中止された場合、上司はQUERIEDNOTFOUNDを応答することがあります。その場合、部下はトランザクションを中止する必要があります（上司は中止されたトランザクションに対してRECONNECTコマンドを送信する必要がないことに注意してください（つまり、送信後にトランザクションを忘れる可能性があります） ABORTおよびABORTED応答を受信する前））。
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).
クライアントアプリケーション（ "commit"を呼び出すアプリケーション）が、トランザクションの最終結果を示す応答を受信できない場合があります（トランザクション自体は正常に完了した場合でも）。これは一般的な問題であり、TIPに固有の問題ではありません。そのような状況では、トランザクションの最終結果を確認するのはアプリケーション次第です（TIP TMは、実装固有のメカニズムを提供することでこれを容易にします。たとえば、ユーザーログに結果を書き込みます）。
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）未処理のトランザクションに関連付けられた要求がある場合は、ローカルのTMの「コミット」関数を呼び出します。
2) positively respond to a transactional request from a partner application prior to having registered it's local TM with the transaction.
2）ローカルTMをトランザクションに登録する前に、パートナーアプリケーションからのトランザクション要求に積極的に応答します。
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）準備された回復レコードを作成した後、このレコードは次の場合まで削除しないでください。 ABORTメッセージが受信された。またはb。 COMMITメッセージが受信された。またはc。 QUERIEDNOTFOUND応答が受信されました。
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）トランザクションのcommit-recovery-recordを作成する前に、システムはPREPARED応答を受信している必要があります。
5) before sending a COMMIT message in Prepared state, the system should have created a commit-recovery-record for the transaction.
5）準備済み状態でCOMMITメッセージを送信する前に、システムはトランザクションのcommit-recovery-recordを作成しておく必要があります。
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）commit-recovery-recordを作成した後、このレコードは次の場合まで削除しないでください。 COMMITTEDメッセージが受信された。またはb。 NOTRECONNECTEDメッセージが受信されます。
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の偽装からシステムを保護する必要があるため、セキュリティはTIPプロトコル自体に関連しています。おそらくこれの最悪の結果は、TIPコミットメントプロトコルの違反が原因で検出されないデータの不整合が発生する可能性があることです（たとえば、ABORTコマンドの代わりにCOMMITコマンドがTIP接続に挿入されます）。 TIPはトランスポート層セキュリティプロトコル[6]を使用して、信頼できるパートナーのみにアクセスを制限し（つまり、どのリモートエンドポイントからTIPトランザクションを受け入れるかを制御し、エンドポイントが本物であることを確認し）、TIPコマンドを暗号化します。 TLSの使用（または使用しない）は、パートナーTIP TM間でネゴシエートされます。 TIPでTLSを使用する方法の詳細については、[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の実装は、一定の時間内に完了しなかったトランザクションをタイムアウトおよび中止するローカルの手段も提供する可能性があります（これにより、悪意のある意図によるリソースの利用不可を防止します）。トランザクションのタイムアウトは、デッドロックを解決する手段としても機能します。
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 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).
これらの要件のほとんどは、トランザクションをユビキタスシステムサービスにして、すべてのアプリケーションクラスで利用できるようにすることを主な目的としています（TCPはどこでも利用できると想定されているため）。一般に、これには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つの個別の通信チャネル（パイプ）に分離する必要があります。この分離により、任意のアプリケーション通信プロトコル（HTTP、ODBC、プレーンTCP / UDPなど）でトランザクション調整プロトコル（TIP）を使用できるようになります。
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トランザクションコンテキスト情報の標準的な表現が（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プロトコルは実装が簡単でなければなりません。便利で高性能な2 PCプロトコルサービスを提供するために必要な機能のみをサポートする必要があります。プロトコルは、無関係な最適化という形で複雑さを追加してはなりません。
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プロトコルは、Web上の電子商取引だけでなく、イントラネットアプリケーションや、異種トランザクションマネージャー環境にまたがる従来のTPアプリケーションに対しても、完全かつ十分に堅牢でなければなりません。プロトコルは、低スループットから非常に高スループットのアプリケーションのニーズを満たすのに十分なパフォーマンスと拡張性を備えている必要があります。
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コマンドは連結（パイプライン）できる必要があります。
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）TIPプロトコル転送の独立性
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.
何らかのタイプの通信トランスポート障害が発生した場合のあいまいな結果を回避するために、回復セマンティクスを十分に定義する必要があります。
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] Lyon、J.、Evans、K。、およびJ. Klein、「The Transaction Internet Protocol Version 3.0」、RFC 2371、1998年7月。
[2] Transaction Processing: Concepts and Techniques. Morgan Kaufmann Publishers. (ISBN 1-55860-190-2). J. Gray, A. Reuter.
[2] トランザクション処理：概念と手法。モーガンカウフマン出版社。 （ISBN 1-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月、分散トランザクション処理：TX仕様。 （ISBN 1-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（ISBN 1-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仕様。 （ISBN 1-872630-24-3）。
[6] Dierks, T., et. al., "The TLS Protocol Version 1.0", Work in Progress.
[6] Dierks、T.、et。その他、「TLSプロトコルバージョン1.0」、作業中。
Authors' Addresses
著者のアドレス
Keith Evans Tandem Computers Inc, LOC 252-30 5425 Stevens Creek Blvd Santa Clara, CA 95051-7200, USA
Keith Evans Tandem Computers Inc、LOC 252-30 5425 Stevens Creek Blvd Santa Clara、CA 95051-7200、USA
Phone: +1 (408) 285 5314
Fax: +1 (408) 285 5245
EMail: Keith.Evans@Tandem.Com
Johannes Klein Tandem Computers Inc. 10555 Ridgeview Court Cupertino, CA 95014-0789, USA
Johannes Klein Tandem Computers Inc. 10555 Ridgeview Court Cupertino、CA 95014-0789、USA
Phone: +1 (408) 285 0453
Fax: +1 (408) 285 9818
EMail: Johannes.Klein@Tandem.Com
Jim Lyon Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399, USA
じｍ ょん みｃろそｆｔ こｒぽらちおん おね みｃろそｆｔ わｙ れｄもんｄ、 わ ９８０５２ー６３９９、 うさ
Phone: +1 (206) 936 0867
Fax: +1 (206) 936 7329
EMail: 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.
このドキュメントに関するコメントは、<JimLyon@Microsoft.Com>、<Keith.Evans@Tandem.Com>、<Johannes.Klein@Tandem.Com>の作成者、または<Tip @ TandemのTIPメーリングリストに送信してください。コム>。メッセージ本文のどこかに「subscribe tip <full name>」という行を入れて<Listserv@Lists.Tandem.Com>にメールを送信することにより、TIPメーリングリストを購読できます。
Appendix A. An Example TIP Transaction Manager Application Programming Interface.
付録A. TIP Transaction Managerアプリケーションプログラミングインターフェイスの例。
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準拠の実装は代替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_open()-TIP TMへの接続を確立します。概要int tip_open（[out] tip_handle_t * ptiptm）パラメータptiptm [out] TIP TMハンドルへのポインタ。説明tip_open()は、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.
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.
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]
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.
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]
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.
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
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.
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
has failed. The local transaction has been aborted.
[TIPNOTCONNECTED]
Caller has been disconnected from the TIP TM.
[TIPERROR]
An unexpected error occurred.
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
transaction identifier.
[TIPERROR]
An unexpected error occurred.
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.
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.
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。