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)


> You have to mandate that it is understood on receipt, otherwise it's not
> interoperable. In any event, we have to mandate it for *REQ* + CONTEXT, so
this
> bullet must be bitten.

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

> This will inevitably have protocol implications, at the messaging level
(format of
> compound messages, BTP aware endpoints, addressing). The problem cannot be
avoided,
> even if you rest with implicit context propagation. We are sending > 1
message to >
> 1 endpoint, through 1 ostensible endpoint, and the ostensible endpoint
must have
> special intelligence. You can compose a compound message however you like,
but the
> sender/receiver cannot be unaware of its compoundness.

Exactly, and I think I said as much in one of the emails last night.

> This implies that the
> receiving interceptor becomes an actor in our scheme, maybe as simple as a
special
> computable address (any known BTP address with the suffix set to a special
value of
> BOXCAR?), plus an agreement to allow n protocol messages in n headers, or
perhaps
> to introduce some BOXCAR message.

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

Mark.

-----------------------------------------------------------------------
SENDER : Dr. Mark Little, Architect (Transactions), HP Arjuna Labs
PHONE  : +44 191 206 4538, FAX : +44 207 670 1964
EMAIL  : mark@arjuna.com




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


Powered by eList eXpress LLC