RE: TIP - node rules

[Peter Furniss <[e-mail]>]

Tom,

> > One kind of rule, essential because of the two-pipe mechanism, is 
making
> > sure the top-node (the travel agent in the requirements example) does 
not
> > initiate commitment until all the subordinates have registered.
> > Generalising this precisely may not be that easy. A particular might 
be:
>
>       Doesn't the general rule need to also state that all applications
> messages must have been
> received by a server ... this would be the equivalent of the
> OTS/implicit/checked behavior?

Yes, there has to be a rule corresponding to the one I gave to say "don't 
initiate commitment until all the replies are in, and yes this is the same 
as OTS (or X/Open) checked behaviour. (and the need for it in those shows 
that they are semanticaly two-pipe, by the way)

But the general rule appropriate to the TIP specification (as opposed to 
TIP + P spec) ought to permit cases beyond the request/response paradigm. A 
spec that allowed:  [ P(stuff) means "stuff" is sent as fields of an 
application message ]

A->B:   P(start negotiation, TIP URL (at TM A))
TM B -> TM A: PULL
TM A -> TM B: PULLED
B->A : P (started, price list)
A->B : P( buy N of item X as quoted)
Ap A requests TM to initiate commitment
TM A-> TM B: PREPARE

is safe, because Ap B won't let TM B allow the commitment (and thus send 
PREPARED) until and unless it has purchase secured. There may be another 
application message from B->A, but that could come after the whole 
commitment exchange is over.

I know that is not a client-server example ( Ap B can't be run as simple 
server that exits with ok/not-ok before the commitment starts), but the TIP 
protocol at present would allow it, and I don't think we would want to 
*forbid* it in stating guidance rules for TIP + P specs.  Or would we ?

>      Another case, not specifically on this point but related is
> out-of-sequence messages ... i.e. a failure
> in the server causes the server to restart at some random point in the
> application message flow (btw a
> point which is not covered in the OMG/OTS specification).

(I assume "server" here means the top transactional node, not the leaf 
server)

A server that isn't sure where it is in the transaction surely ought not 
request/allow commitment.

Otherwise, there is a general problem of being sure both sides agree on 
what they are committing to. I think this is probably a TIP + P matter, 
though it links to the security issue (especially the non-repudiation 
needed for e-commerce). A problem I can see is that can be different 
application protocols on the branches (as in the requirements example - the 
airline and hotel booking may use different protocols, or at least 
different URL-in-HTTP specs).  Using the undefined space at the end of TIP 
statement, as Keith suggested, sounds like a good approach.

Peter

Peter Furniss Consultants
58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK
Phone & fax : [phone] (or 0181 460 8553 if busy)
Email           : [e-mail]