RE: Boxcarring and its implications (was Re: Open-top coordinators andprotocol)

[Peter Furniss <peter.furniss@choreology.com>]

I don't believe boxcarring can be regarded as just an optimisation that the
two sides can use if their addresses happen to be the same and the timing
comes out right. That kind of "facultative" [1] box-carring is, as Mark
says, invisible to the principal actors (whichever were involved), and can
be done magically by the carrier implementations (cooperatively)

However, it isn't the case for ENROLL. To summarise the checking
requirements - in order to ensure all parts of the atom are included in the
decision, it is essential that everything is known to be enrolled at the
coordinator at the time it collates the votes. (for normal 2pc mechanisms,
it is usually stated earlier than that, but for our case, it's vote
collection time). With separate message streams, this is ensured by
requiring that ENROLLED has been received back before an "ok" application
response is returned to the initiator - if the ENROLL fails, the application
response must be a fault, and the initiator must cancel the atom rather than
try to prepare and confirm it. Without this constraint it would be possible
for the initiator to request, and the coordinator complete confirmation of
the rest of the atom before this participant was enrolled.

Such an ENROLL cannot be facultatively-boxcarred with the application
response, because the reply (ENROLLED) must come back to the S/P side before
the application response can be sent.

However, if the involved entities *know* that the ENROLL will be
piggy-backed with the application response, there is no need for the double
round trip. If the application response gets lost, the initiator will see a
fault, and will cancel. In this case it is helpful to assume a superior-side
interceptor which pulls of the ENROLL and passes it to the coordinator - and
if that ENROLL invocation fails , the superior interceptor must make sure
the atom will cancel - either directly, or by changing the response seen by
the application to a fault/exception.

This at least changes the behaviour of the element at S/P that issues the
ENROLL, which doesn't receive an ENROLLED response. Possibly it doesn't
change the coordinator, which always replies to a received ENROLL.


The requirement to run both the application and btp messages down a single
pipe (which was expressed by several in the Boston meeting), pretty much
requires boxcarring.  And, per the earlier discussion, one-shot without
boxcarring

Peter


[1] - facultative : used as in biology to mean that something can do this if
conditions are right, but doesn't always. Opposite is "obligate".  Not the
same as optional/mandatory, which refers to what is implemented.


> -----Original Message-----
> From: Mark Little [mailto:mcl@arjuna.com]
> Sent: 30 May 2001 16:44
> To: Alastair Green
> Cc: 'BTP'
> Subject: Re: Boxcarring and its implications (was Re: Open-top
> coordinators and protocol)
>
>
> > > Obviously you have to understand the message if you receive
> it. However,
> > > what I am against is a protocol that only works with piggybacking of
> > > messages. This is an optimisation that may well work in some
> situations
> but
> > > not in others, and as such, if you can't understand the
> compound message
> the
> > > protocol should still work (albeit with more message exchange).
> >
> > Are you saying that implicit context propagation should be optional?
> (Receiver
> > does not have to understand this?)
>
> No, and I certainly didn't mean to give that impression. What I am against
> is a protocol that requires piggybacking of *messages*, not "attributes"
> [not the best word to describe it, but I want something different to
> differentiate what I am about to say]. Implicitly propagating the context
> (which I consider an "attribute") is different IMO from having a single
> message that contains multiple application-level messages intended for the
> same receiver. The first can always be done, whereas the second
> may well be
> down to timing or implementation issues. Both require some kind of
> interception facility. Implicit context propagation is my
> prefered method of
> getting a context from A to B, but I'm not sure we can mandate it
> either: in
> fact at the London face-to-face I remember we discussed this briefly and
> decided to go with explicit propagation, and I haven't seen any discussion
> otherwise since.
>
> Going back to piggybacking messages: for example, let's assume the is a
> CONTEXT object that an outward bound interceptor has access to. When a
> service message (say BOOK_TAXI) goes out from a high-level sender, the
> interceptor can piggyback CONTEXT on the message. A receiving interceptor
> can then strip it off, do something useful with it, and invoke the
> high-level receiver to do the real work. No problem with any of this: the
> roles are well defined - we have a high-level sender, a
> high-level receiver,
> and a couple of interceptors.
>
> Now suppose the high-level receiver creates a separate
> participant that then
> wants to send an ENLIST message. If this ENLIST message goes through the
> receiver's interceptor at the same time the response to BOOK_TAXI
> does *and*
> the destinations are the same, then I've no problem with the interceptor
> using some intelligence to piggyback the two (or even more) messages;
> obviously the receiving interceptor then needs to figure out that
> there are
> multiple messages. If the timing's off then two separate messages
> will flow,
> but sobeit. By default the service doesn't see this piggybacking, and
> doesn't have a hand in it. If you think it is important for messages to be
> piggybacked, then you could certainly put some implementation
> specific hooks
> into your service to ensure that timing issues are never a problem, i.e.,
> ENLIST (and possibly VOTE) do pass through the interceptor at the
> same time
> as the application response. However, this is an implementation specific
> decision that may well only be possible in specific circumstances and for
> specific services.
>
> Interposition is a prime example of where piggybacking of context
> information on return responses may well be useful, and it
> doesn't have any
> timing issues. Just as in the OTS, a participant that wants to do
> interposition could update its local notion of the context saying that it
> wants to be ENLIST-ed, but no explicit ENLIST message flows back. When the
> application response flows, this updated context goes back to the sender,
> whose interceptor needs to examine the updated context and sees the newly
> "ENLIST-ed" participant, and enlists it locally.
>
> > > This would work, as long as that actor is not mandated. There will be
> > > communications protocols/distributed infrastructures that
> simply do not
> let
> > > you do this optimisation, and we should not remove ourselves
> from those
> > > arenas by mandating boxcarring.
> >
> > Don't buy this. If something can receive a message, and the
> receipt can be
> > associated with computation, then boxcars can be unloaded and messages
> > forwarded. The carrier protocol itself may not be capable, that doesn't
> end the
> > matter. Analogy, that I have already raised some weeks ago: if
> a protocol
> > doesn't support headers or contexts, then one can simulate the
> effect by a
> BTP
> > envelope or array structure, which can be carried over any carrier.
>
> See above. We must make the distinction between context propagation and
> message piggybacking. I'm all for the former, but do not believe
> the latter
> should a) be mandatory, b) can work without smudging the
> distinction between
> actors and the message sets they can generate, and c) only workd if the
> timing is right.
>
> >
> > > However, if it's optional, then that's
> > > great. Application-level negotiation can be conducted between
> end-points
> to
> > > figure out whether or not they are going to us boxcarring, and this
> could
> > > occur dynamically with the first message exchange, so no-one sees it
> anyway.
> >
> > I'm not convinced this is the way to go. I would prefer to see
> boxcarring
> as an
> > mandatory interoperable feature.
>
> And I would prefer to see it optional, for all of the arguments above, and
> in previous emails.
>
> Mark.
>
> -----------------------------------------------------------------------
> SENDER : Dr. Mark Little, Architect (Transactions), HP Arjuna Labs
> PHONE  : +44 191 222 8066, FAX : +44 191 222 8232
> EMAIL  : mark@arjuna.com
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to:
> business-transaction-request@lists.oasis-open.org
>