[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