RE: Proposal: WebDAV and transactions

Hello,

Yesterday I was made aware of the TIP protocol
(http://www.ietf.org/rfc/rfc2371.txt). It defines a 2PC TA protocol between
TMs (transaction managers) and requires the application to pass the TID
token to the resource manager (in our scenario the WebDAV server). [The
communication between the application and the resource manager (RM) is not
covered in the standard, except for the fact, that the TID token is passed).

I can see now 3 scenarios:

a) auto commit
The application is not TA aware and sends the WebDAV commands without any TA
commands or TA token. In this case the WebDAV server acts as today (every
request is executed in a single atomic TA). 
b) global TA
In this case multiple resource managers (e.g. multiple webdav server and/or
multiple other datasources) are involved on a single node or on multiple
nodes (with a single or multiple TM). In this case the application sends the
TA_BEGIN to the local TIP aware TM, receives a TID token, which is passed to
all participating RM at every request call. In case of WebDAV the place
could be a header (in case of e.g. PUT, the body is already reserved for
content). The WebDAV server (if the implementation is TIP aware) would
recognize the TID token and enlist at the local/global TM via the TIP
protocol. At the end of the TA the application would send the TA_Commit TIP
command to the local TM and the TM would initiate the 2PC execution to all
participating TM via the TIP protocol. 
c) local TA
In this scenario the application will talk to exactly one RM (the webdav
server) and possibly a full blown TM is not available. If the server would
implement both WebDAV and (at least the 1PC part of) the TIP protocol, the
TA_BEGIN could be send to the same server as all following WebDAV commands
followed by a TA_END command.

I can see following advantages going the TIP path:

The TIP protocol is already standardized, no need for WebDAV to introduced
something new (especially new methods). If WebDAV is used outside the TIP
protocol, performance and scalability stay identical to today's situation.
The decision if a WebDAV server is TIP aware will be driven by the specific
implementation. If a server supports scenario "c" only, would be
server-implementor defined too.
If we could agree on a specific header name to carry the TID token, all TIP
enabled WebDAV servers would be interoperable and could participate in a 2PC
environment. This header agreement would be the only WebDAV/HTTP extension
necessary.

The same would apply for http too. I agree with Roy, this feature is valid
in an http context too and specific to WebDAV. Would there be interest to
agree at this header for HTTP protocol?

Does this make sense?

Best regards,

Juergen



 -----Original Message-----
From: 	Roy T. Fielding [mailto:fielding@apache.org] 
Sent:	Wednesday, September 11, 2002 18.22 PM
To:	B. Shadgar
Cc:	w3c-dist-auth@w3.org
Subject:	Re: Proposal: WebDAV and transactions


I'll try to explain.  It is fundamental to HTTP that intermediaries
are able to inspect the method of an HTTP request in order to determine
the semantics of a request, and thereby its associated access control
and/or authentication requirements.  What you are suggesting is that
we bypass that feature in HTTP via a new syntax that tunnels arbitrary
methods within XML via HTTP, effectively bypassing all of the benefits
of using HTTP in the first place.

Sound familiar? It should, since this is the same objection that I have
frequently given to the use of SOAP for tunneling arbitrary semantics
though an HTTP POST method.

Transactions can be accomplished by using a request to ask the server
for a transaction context, possibly multi-level, and then sending
the sequence of requests with a calculated transaction-request-id
in the header fields, to each the server responds with 202 Accepted
or an error, and finalized with a commit or abort method, to which
the server responds with the appropriate message for the entire
commit.  Such a transaction mechanism accomplishes the same thing
without violating the requirements of HTTP.

In any case, this is OUT OF SCOPE for WebDAV.  It is an HTTP issue
that is not specific to authoring and will not be solved by an
authoring-specific solution.

....Roy

Received on Thursday, 12 September 2002 05:19:48 UTC