rfc2372.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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.

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.

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



Evans, et. al.               Informational                      [Page 1]

RFC 2372     TIP Requirements and Supplemental Information     July 1998


1. Introduction

   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.

   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).

   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.

   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



Evans, et. al.               Informational                      [Page 2]

RFC 2372     TIP Requirements and Supplemental Information     July 1998


   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.

   (See [2] for more information re transactions, atomicity, and two-
   phase commit protocols in general.)

2. The Transaction Internet Protocol (TIP)

   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.

   This goal is achieved primarily by satisfying two key requirements:

   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.

   2) Enable the protocol to be used with any applications
      communications protocol (e.g. HTTP). This ensures heterogeneous
      environments can participate in distributed work.

   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).

      +-------------+ 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






Evans, et. al.               Informational                      [Page 3]

RFC 2372     TIP Requirements and Supplemental Information     July 1998


3. Scope

   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 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).

4. Anticipated Usage of TIP

   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.

5. TIP Compliant Systems

   There are two classes of TIP compliant Transaction Manager system:

   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.





Evans, et. al.               Informational                      [Page 4]

RFC 2372     TIP Requirements and Supplemental Information     July 1998


   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.

   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).

6. Relationship to the X/Open DTP Model

   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.

7. Example TIP Usage Scenario

   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.





Evans, et. al.               Informational                      [Page 5]

RFC 2372     TIP Requirements and Supplemental Information     July 1998


   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)):

   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.

   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).

   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:

      a. the local TM creates a local transaction (under which the
         work will be performed),

      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),

      c. a PULL command is sent to the superior 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,

      e. the subordinate TM returns control to the book_flight
         application, which is now executing in the context of the newly
         created local transaction.