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)


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