[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)
Mark, Peter: Isn't it true that the "single wire" approach *requires* standardized interception, in the sense that messages for A must pass through X? (Doesn't require boxcarring, I agree). Isn't it also true that the network optimization described as one-shot *requires* boxcarring, otherwise you do end up with 6 instead of 2? (Or a worse ratio if number of participants > 1)? And lastly, isn't it true that implicit propagation *requires* some kind of bundling of messages (qualification is one view)? If you combine these requirements (and this is first and foremost a requirements discussion, not a "how do we do this in the protocol" discussion) then I think you end up with one approach, that I favour (mandatory interoperable boxcarring and message forwarding). If you chip away at these requirements you may end up with something much more minimal. The most general view that spans all three is that the BTP protocol should permit the creation of compound messages, directed to A(X) -- address of X -- where each element is a message (let us say, {1, 2, 3}) with an address, e.g. A(1). In this case an app request + CONTEXT going to A would be, using a convention that {1,2,3 ...n} = compound message, and -- = "destined for address": {*REQ* -- A, CONTEXT -- A}-- A A forwarded message (for one-wire) would look like: {ENROLL -- A} -- X A boxcarred message (for optimization) might look like: {ENROLL(Pa) -- A, VOTE(Pa) -- A, ENROLL(Pb) -- A, VOTE (Pb) -- A) -- A and a natural optimization in the first and last cases might be to allow the internal addresses to be omitted if they were the same as the first receiver, e.g. {ENROLL(Pa), VOTE(Pa), ENROLL(Pb), VOTE (Pb)) -- A {*REQ*, CONTEXT}-- A This last example is probably what one would reduce to if you thought only implicit context propagation was a requirement. If you thought none of the three requirements was important then you would chuck out the whole notion of "compoundness", make checking an application requirement, and one message would travel to one endpoint, and there would be no implicit or explicit need for interception. Just trying to sift out what we're debating here. Alastair PS There was a bit of a clash over "in scope, out of scope" on the one-wire example, which flows (in part) from internet security impositions (how many holes do you tolerate in the firewall? all traffic over one authenticated pipe). We have decided to take security into account to the extent that we seek to avoid roadblocks to an upward compatible secure V1.0+. I think this should colour our thinking on one-wire topologies. I also happen to believe that inter-org BTP will very often be infeasible without the one-wire approach. PPS There is no assumption of collocation in the sense of the same address space. The receiver must be capable of forwarding, by any (unspecified means) to the ultimate address. There are some subtleties around this, but I believe the combination of a two-part address and distinct IDs for atoms and participants actually makes this quite reasonable. A BTP-aware proxy is one way of looking at this. Mark Little wrote: > [stuff deleted - similar to what I said earlier on how the OTS can behave > w.r.t. interposition] > > > 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. > > I disagree. It does not *require* boxcarring, it only makes it possible. As > I have said in numerous emails, we are not against it, only against it being > required (and I believe Sazi/BEA have expressed a similar view). As soon as > you do not have S/P co-located (you now seem to be implicitly arguing for > co-location, which was HPs position in the first place at Boston, but > apparently not the majority's) then this single-pipe doesn't work. There are > then two services S and P residing in different address spaces and they talk > to their interested parties (I and C respectively) down different pipes. > > Are you now saying that S and P must reside in the same address space? If > the answer is yes then: > > (i) I agree that boxcarring of *certain* messages is possible (see previous > emails). > > (ii) I'm not convinced we want to impose that co-location requirement. > > > And, per the earlier discussion, one-shot without > > boxcarring > > Agreed. > > Mark. > > ---------------------------------------------- > Dr. Mark Little (mark@arjuna.com) > Transactions Architect, HP Arjuna Labs > Phone +44 191 2064538 > Fax +44 191 2064203
begin:vcard n:Green;Alastair tel;cell:+44 795 841 2107 tel;fax:+44 207 670 1785 tel;work:+44 207 670 1780 x-mozilla-html:FALSE url:www.choreology.com org:Choreology Ltd version:2.1 email;internet:alastair.green@choreology.com title:Managing Director adr;quoted-printable:;;13 Austin Friars=0D=0A;London;;EC2N 2JX; fn:Alastair Green end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC