1. Today’s Standard Transaction Protocols Limit Business Opportunities on the Internet

There are de-facto and de-jure standards for heterogeneous transaction propagation and coordination (SNA LU6.2 Synclevel 2, OSI TP, CORBA OTS). All of these standards employ a tightly-coupled transaction protocol and application communications mechanism. i.e. they use a one-pipe model. The primary characteristic of this model is that the transaction protocol flows over the same conduit (pipe) as the application to application communications. The transaction tree is built implicitly as an application component communicates with another application component. This is achieved by the provision of a transaction protocol embedded within the communications services provided to the application (usually by a TP monitor).[1]

The use of a one-pipe model has the following consequences:

a) If an application wishes to compose distributed work within the context of a single transaction, it may use only the communications services supported with the transaction protocol. Work is required to invent a transaction protocol for each new communications protocol which comes along. This limits the possible distributed communications mechanisms which may be used by an application.

b) To support the transaction protocol, a product must also implement the communications protocol. This significantly increases the complexity, which inhibits implementation. Hence, none of the standards is widely-deployed. Instead, numerous proprietary transaction protocols have been invented, which only work between themselves. This restricts interoperability.

The effect of all this is that transactions may realistically only be used where each component of a distributed application is running under the same TP monitor software, using only the communications services supported by that TP monitor, with a proprietary transaction protocol. This implies it must always be known in advance which application components are to be involved in a transaction, such that the user can arrange things to ensure all applications are written to use the same TP monitor software.[2]

To limit the availability of the transaction paradigm in this way is undesirable since transactions greatly simplify distributed applications programming. When transactions are not used, a distributed application must be explicitly programmed to recover from any number of communications related errors, which may result in work being partially completed, or not performed at all at some sites, but fully completed at others. Such recovery programming is very complex and error-prone. With transactions, the number of possible outcomes is reduced to two - either all of the work is completed everywhere, or none of the work is completed anywhere. Recovery in the event of failure is taken care of by the transaction service, and the distributed system is always left in one of these two consistent states.

As things currently stand then, development of new business applications is throttled by: a) the restrictions imposed if transactions are to be used, and, b) the complexity of writing distributed applications without them.

This is especially true in the case of Internet transactions. There is no standard “transactional HTTP” protocol. And it is contradictory to the flexibility of the internet that it be known in advance which components will be involved in a distributed transaction, and hence to arrange it such that all components use the same transactional communications mechanism.

In summary, today’s standard transaction protocols have failed to become ubiquitous and consequently are of little practical use, and proprietary solutions are too restrictive to encourage use of the internet for distributed transaction processing. This limits exploitation of the inherent benefits of the internet for new business applications (with the concomitant reduction in potential business opportunity and growth).

What is required is not a transactional version of HTTP, but a simple standard transaction propagation and coordination protocol which is independent of the application to application communications mechanism, and which may be employed with any such mechanism (present or future), including HTTP. This model of separation of transaction control and application communications is known as a two-pipe model. Leveraging this experience to specify a standard two-pipe transaction protocol is appropriate (and overdue).

2. TIP – Heterogeneous Transactions for the Internet

The Transaction Internet Protocol (TIP), is a very simple two-phase commit protocol employing the two-pipe model, which operates over TCP/IP connections.[3] It achieves its simplicity by specifying only how different sites agree on the outcome of a transaction; it requires that applications communicate via other protocols. While this transaction protocol may not replace existing ones, it is expected to be relatively easy for many existing transaction managers to implement, thereby enabling interoperability in a heterogeneous environment. TIP has been published by the IETF as a Proposed Internet Standard RFC [2, 3].

TIP offers two innovations compared to the current standard protocols which are particularly relevant to internet applications:

a) The pull method of transaction propagation: where a new participant requests an existing participant to add it to the transaction (the existing participant becomes the superior of the new participant). Among other things, this method allows a client to access an arbitrary set of servers and include them within the same transaction (this is a typical web usage model).

b) A method whereby transaction demarcation is controlled by the client application, but the client node does not participate in transaction commitment and recovery. This is known as delegated commit: commit coordination is delegated to another participant. This mechanism obviates the need for a full transaction manager implementation on the client system (i.e. with a transaction log etc). This is most appropriate for internet applications where the client is typically running on a desktop machine using a web browser, with no local recoverable resources. It would be disastrous for server system resources to be made unavailable because of the failure of such a client.

2.1 TIP URL and APIs

In order to facilitate the application use of TIP, a TIP URL is specified which defines the information necessary to propagate TIP transactions. This URL is passed between cooperating applications as the transaction context. The URL specifies the listening endpoint of the superior transaction manager, and a transaction identifier by which the superior knows the transaction.[4] This is all a subordinate application needs to supply in order for a local transaction manager to either pull a TIP transaction, or to put the application into the context of a previously pushed TIP transaction. Being architected, the TIP URL is also something an arbitrary application may look for in order to determine whether it should join a TIP transaction or not.[5]

So that applications may utilise TIP, a TIP-compliant transaction manager provides a set of application programming interfaces (APIs), which may be used by applications to perform TIP operations (e.g. to join a TIP transaction, to create a TIP URL, etc).

The TIP protocol itself has characteristics that support high-performance. e.g. multiple TIP transactions may be multiplexed over a single TCP connection; multiple TIP commands may also be pipelined together to reduce network latency and resource consumption.

3. Web-usage Model

TIP enables the development of web agency type applications, which act as brokers for the services of other providers. This is an excellent model for web-based transactional applications, where the agency acts as the transaction coordinator. The agency provides screens to web browser clients, enabling them to open and close an electronic shopping basket, and in between to fill the basket with items selected from the various services offered. e.g. a travel agency which enables a client to select the components of a travel itinerary from services offered by airline and hotel servers, and then execute (confirm) that itinerary as a transactional unit. On confirm, the agency application starts a TIP transaction, works with the airline and hotel servers to update their database records (within the context of the TIP transaction), and if ok (there are flights/rooms available etc), commit the transaction.

Providers to the agency simply need to write their service applications to recognise a TIP URL (present in an HTTP data-stream), and employ APIs provided by the local TIP-compliant transaction manager to join the transaction. The various distributed transaction managers then take care of transaction completion, and either the whole travel itinerary is confirmed, or none of it is (and all the changes associated with it are backed-out). Should a failure occur, the TIP recovery protocol is run between the agency and the provider servers (since the client is not a recoverable participant, and does not participate in the two-phase commit process, it is not involved).

Note that communication between the TIP transaction managers takes place via means totally independent from communication between the application components (which in this example is HTTP between the web browser and agency server, and between the agency and the airline/hotel servers).

4. Summary

The use of TIP confers the following benefits over current standard and proprietary transaction protocols:

a) An application may choose whatever protocol mechanism is most appropriate to communicate with a partner.

b) There is no predetermination regarding which application components are to participate in a transaction. The only requirements are that:

· each distributed system supports a TIP compliant transaction manager, which manages the coordination of local resource managers with remote TIP transaction managers (the transaction managers on each system do not have to be the same).

· co-operating applications agree about their communications data formats and protocol (part of which includes propagation of the TIP URL). TIP transaction trees can therefore be built-up involving many arbitrary “TIP URL aware” applications, using many different communications mechanisms, and many different transaction managers.

c) As new communications protocols are developed, these can be used together with TIP to provide transactional versions of such protocols. The need for development and implementation of a new transaction protocol for every new communications scheme is obviated. An application can avail itself of a new communications paradigm immediately (and obtain transactional semantics).

d) Because of its simplicity and utility, it is expected that TIP will be widely implemented. TIP therefore offers a practical solution for very heterogeneous transactional interoperability.

5. References

[1] X/Open Guide. 1993. “Distributed Transaction Processing: Reference Model Version 2”. X/Open Company Ltd., U.K.

[2] Evans, K., J. Klein, and J. Lyon. 1998. “Transaction Internet Protocol – Requirements and Supplemental Information”.

IETF RFC 2372.

http://www.ietf.org/rfc/rfc2372.txt

[3] Evans, K., J. Klein, and J. Lyon. 1998. “Transaction Internet Protocol Version 3.0”. IETF RFC 2371. http://www.ietf.org/rfc/rfc2371.txt

[4] Gray, J. N., and A. Reuter. 1992. Transaction Processing: Concepts and Techniques. San Francisco: Morgan Kaufmann.

[1] In X/Open TP model terms, a Communications Resource Manager (CRM) cooperates with a local Transaction Manager to implicitly propagate transactions, the application uses the API of the CRM to communicate with other applications [1].

[2] Or at least to use the same communications protocol when employing a standard transaction protocol (e.g. CORBA IIOP with OTS).

[3] The two-phase commit protocol is a proven distributed transaction paradigm, whereby changes to resources are first prepared, then committed (written). This two-stage process minimizes the failure opportunity such that resources could be left in an inconsistent state.

See [4] for more details.

[4] Whether a flat or hierarchical transaction tree is built depends upon which superior transaction manager listening end-point is passed via the TIP URL. i.e. it could be my own, or my superior’s, end-point.

[5] See [3] for details of the TIP protocol and URL.