OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


> > 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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC