Re: TIP - BEGIN message - is it useful ?

Tom Freund <tjfreund@uk.ibm.com> Fri, 08 August 1997 10:15 UTC

Received: from cnri by ietf.org id aa03844; 8 Aug 97 6:15 EDT
Received: from suntan.tandem.com (suntan.tandem.com [192.216.221.8]) by cnri.reston.va.us (8.8.5/8.7.3) with SMTPid GAA21233 for <ietf-archive@cnri.reston.va.us>; Fri, 8 Aug 1997 06:13:30 -0400 (EDT)
Received: by suntan.tandem.com (8.6.12/suntan5.970212) for tip-relay id CAA15903; Fri, 8 Aug 1997 02:45:06 -0700
Received: from d06lmsgate.uk.ibm.com by suntan.tandem.com (8.6.12/suntan5.970212) for <tip@tandem.com> id CAA15897; Fri, 8 Aug 1997 02:45:02 -0700
Received: from d06lms01.emea.ibm.com by d06lmsgate.uk.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA20968; Fri, 8 Aug 1997 10:41:38 +0100
Received: by UK.IBM.COM (Soft-Switch LMS 2.0) with snapi via D06AU009 id 5060100004787241; Fri, 8 Aug 1997 09:45:35 +0000
From: Tom Freund <tjfreund@uk.ibm.com>
To: p.furniss@ulcc.ac.uk
MMDF-Warning: Parse error in original version of preceding line at ietf.org
Cc: tip@tandem.com
MMDF-Warning: Parse error in original version of preceding line at ietf.org
Subject: Re: TIP - BEGIN message - is it useful ?
Message-Id: <5060100004787241000002L012*@MHS>
Date: Fri, 8 Aug 1997 09:45:35 +0000
Mime-Version: 1.0
Content-Type: text/plain

Keith,

     Peter's attached justification for a client BEGIN is a very interesting
scenario. I'd be very
interested in understanding the details and how the different servers register
with the
initial 'server' TM using TIP. This seems to illustate what has been referred
to in some
products as coordinator migration (and also the equivalent of what an OTS
explicit factory
begin provides) in terms of capabilities ... i.e. allowing the client to
demarcate the work unit
but locate the coordinator responsibility external to the client.

Tom

> There needs to be more justification for the presence in TIP of the BEGIN
> message.


> The possible use of BEGIN/BEGUN is where the client is going to use the TIP
> URL to identify its application messages as being part of the transaction,
> send several such messages (possibly to different servers, hoping the
> others correctly use PULL to register with the initial server's TM), and
> then tell the initial server it is ok to try to commit. (This has a
> one-to-one correspondence with the semantics of OTS interactions, I
> believe)