Re: interposition

[arkin <arkin@intalio.com>]

Mark Little wrote:
> 
> > I believe this should actually happen in reverse order. The
> > sub-coordinator must assume that any of its participants (in local
> > proximity, but likely in a separate server) are susceptible to failure,
> > and as such as them to prepare all work before it performs any
> > preparation on its side, returning a vote to the coordinator.
> 
> Did you miss a message exchange? We went through this on Wednesday/Thursday.

Sorry. I read and responded to the original e-mail, only to get the
reminder of the discussion after synchronizing with the e-mail server.

Having read the rest of the thread, I agree with Alastair's point.


> > Technically speaking, if the sub-coordinator fails, it will not be able
> > to prepare itself or its participants and the transaction will timeuot
> > and rollback by the coordinator. If a participant of the sub-coordinator
> > fails, the sub-coordinator will still attempt to prepare before giving
> > up. Hence, it should ask all its participants to prepare first, and once
> > all votes have been tallied perform work on its side. It must, however,
> > record such a tally in durable storage.
> 
> Agreed, and as was pointed out last week, the email was not meant as an
> implementation document, simply as a statement of the work that must be
> performed.

I agree. Still, it will be valuable if the specification produces, even
in the form of notes, indication of how an implementation should behave.
Alastair's comments phrase it better in the form of an expected behavior
from the interposing participant, giving leverage to multiple
implementations that are consistent with the expected behavior.


> > Again, from the perspective of the user this is transparent. The Web
> > service defines it's expected inputs and outputs, but not how it goes
> > about doing its work. Indeed the initiator may not be aware of all
> > participants indirectly used in the transaction (but will be aware of
> > all participants directly used), and not be able to record them in the
> > audit trail.
> >
> > The audit trail should only reflect the direct participants of the
> > transaction, and will never be able to reflect all indirect
> > participants, specifically where other protocols (or direct API calls)
> > are being used.
> 
> I suspect you have missed a significant portion of this argument, that has
> been going on via email and the teleconferences over the last 2 weeks.

I definitely missed most of it. Is there any strong reason why a Web
service should be prevented from interposing? Does that argument extend
to all participants used by that service, or only to a select portion
(which the coordinator can nodoubtly name)?

arkin

> 
> Mark.
> 
> ----------------------------------------------
> Dr. Mark Little (mark@arjuna.com)
> Transactions Architect, HP Arjuna Labs
> Phone +44 191 2064538
> Fax   +44 191 2064203
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: business-transaction-request@lists.oasis-open.org

-- 
----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
CTO,  Intalio Inc.                                     www.intalio.com
The Business Process Management Company                 (650) 345 2777