Reported by: Keith Evans (keith@loc252.tandem.com)
Keith opened the meeting by welcoming everyone and giving a brief overview of the Transaction BOF. The intent of the meeting was to socialize and discuss interest in the Internet-Draft Transaction Internet Protocol (TIP) specification, and ascertain the need for an Internet standard for transactions.
Jim Lyon presented an overview and rationale of the TIP specification
(draft-lyon-itp-nodes.01.txt).
The primary issue that arose was instigated via a letter submitted, signed by individuals from several companies (this letter is attached below). The letter states essentially that any Internet transaction standard should be based upon the CORBA IIOP + OTS protocol, and that a new protocol (e.g., TIP) is not required. Members from two of the signatory companies present at the meeting supported this view. [Note that one of the signatory companies (Digital) also sent a representative to the BOF to support the TIP proposal.]
Arguments were made by several people against this position, which may be summarized as:
· OTS assumes IIOP, and does not support other application communication protocols (e.g., HTTP), whereas TIP supports any application protocol, it therefore offers protocol independence. This is an essential requirement.
· Applications using HTTP are not going to use IIOP.
· TIP is very simple (whereas IIOP/OTS is not), and hence is suitable for many applications where a small footprint is required.
· TIP picks the low-hanging fruit and offers a simple common 2-pc protocol - it does what's needed simply and efficiently. IIOP/OTS is overkill.
· The IETF has a bad track record of standardizing complex protocols such as IIOP/OTS.
· IIOP is not an Internet standard and probably never will be.
A question was asked whether TIP solves problems that OTS does not, and vice-versa? It was answered that TIP is agnostic with respect to application protocols, whereas OTS assumes IIOP.
Another point was made that OSI TP is also not a solution to this problem, since it too is complex, and not widely implemented.
The discussion then centered around whether the IETF should develop a standard transaction protocol at all, regardless of which protocol? The essence of comments here was that there are a number of applications developed by the IETF which need atomic transactions, and a common standard would prevent each application from inventing their own 2-pc protocol. Such a standard would provide an IETF middleware building-block. Hence, a Working Group on the subject should be formed to address transactions, given this synergy with other IETF efforts.
It was also stated that there is a general need for transactions on the internet, and that this problem is not solved today. A counter argument was made that different organizations will not do 2-pc with each other because of trust issues. It was noted that this would not be the case for a large company intranet; nor for cooperating organizations (e.g., between a publisher and a bookstore, or a travel agency and a hotel chain). If this was an issue, then an installation can protect them by employing timeouts to abort transactions that have overstayed their welcome. (This (timeouts) is also the answer to another question that was raised about deadlock detection.)
A show of hands at the end of the meeting yielded only two persons that thought forming a Working Group to address transactions on the Internet is a bad idea. There was also a majority sentiment that TIP is a good starting point for such a group.
Here is the text of the letter submitted at the meeting:
To The Members of the IETF TIP BOF
We believe in the value of open standards for transaction processing. We support collaborative efforts to specify standards, implement standards, and help ensure broad industry adoption of standards.
Fortunately, the open systems community has already collaborated on an Internet-based standard for transaction processing, including a two-phase commitment protocol.
As part of the Object Management Group (OMG), many companies including Bull, IBM, ICL, Iona, Novell (Tuxedo), Tandem, Tivoli, Transarc, and Sun collaborated to define the Object Transaction Service (OTS) which provides two-phase commitment using TCP/IP with the Internet Inter-ORB protocol (IIOP). Additionally OTS has been incorporated by JavaSoft in their JTS.
Standards provide tangible value when products implement them. OTS has not only been specified, but also implemented in products shipping from several companies, and announced by many others.
The Internet community is best served by a single standard for two-phase commitment. The goal of IETF is to establish widely-adopted standards for interoperability. If yet another standard is pushed into the community, vendors will be faced with the burden of supporting two standards, and the user community will be forced to manage systems of limited interoperability or those built on two similar, yet distinct protocols.
We, the undersigned, recommend to the members of the IETF the following:
Those who desire IETF endorsed transaction standards, we recommend working with the OMG on a submission of OTS and IIOP for IETF endorsement.
Those who are dissatisfied with the current OTS or IIOP specifications are invited to participate on the next revisions.
Carlos Borgialli, Digital Equipment Corporation
Mark Carges, BEA Systems, Inc.
Carl Cargill, Netscape Communications Corporation
Graeme Dixon, Transarc Corporation
Jeri Edwards, BEA Systems, Inc.
Larry Jacobs, Oracle Corporation
Jeff Mischkinsky, Visigenic Software, Inc.
Goran Olsson, Oracle Corporation
Annrai O'toole, Iona Technologies
Chris Stone, Object Management Group
Tony Storey, International Business Machines Corporation
1. TIP: Distributed Transactions for Everyone (Agenda)