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: [business-transaction] HPs position on BEAs proposal andtheChoreology response


Also from the southern hemisphere (though having now read most of the later
messages, I'm not sure it's more
than a rephrasing of Alastair's)

Cohesions v Atoms is a much smaller deal than may appear.

If looked at from the concern of an interoperable protocol between a
client+its BTP support to a service+its BTP support, then the difference
between Cohesion and Atom is very small and effectively zero implementation
effort. In fact, it is *atoms* that require more effort (in the service
side).

Looked at concerning the client to btp-support relationship, then cohesions
are more complicated - the client has to have some way of choosing among the
candidates etc, hence the vectored requests and responses.

The conformance profile idea allows an implementation to support the first
of those paragraphs (the superior:inferior relationship) with the
interoperable protocol, but do its own proprietary thing with the second. Or
support both (I can't seen the second alone being rational).


To expand on the first:  all that the service+participant needs to know is
whether, if it sees the same context on two different (application)
invocations, it can trust the decider (superior) to make the same decision.
If it can so trust, and finds it convenient, it can merge the operations
into one reversible group. If it cannot so trust, or doesn't find it
convenient even if it could trust, then each operation is its own group (and
requires a separate registtration).

But, the decider better be telling the truth, and the service should respect
that if a context is declared atomic, then no part of the work associated
with it can be cancelled or reversed unless (within the service) all of it
is. If some branches are to be allowed to drop out or be evicted, then they
better have been cohesive branches, not atomic ones. (which, BTW, is why the
old BEA approach seems to me to be using Cohesions, not Atoms)

I don't see Cohesions as layered on Atoms in protocol (they are to some
extent in concept of course). The top of the (eventual) decision tree
behaves the same way (logs all confirming inferiors before sending confirm
to them), and it is driven (requested, not strictly instructed) by something
with a volatile relationship to it. It's cohesion/atom difference is whether
there were other inferiors that didn't get included in the log. The
inferiors of a cohesion may be atom coordinators, but the cohesion can't
tell, because it's relationship to them is just a simple case of
Superior:Inferior - inferior votes, superior tells it the decision (as
applicable to it). But the inferior could just as well be a
resource-controlling participant - a superior never knows what the inferior
is doing, whether it has inferiors of its own or what. (In some of our
earlier discussions and thinking this wasn't so clear, but the "opacity" of
the interoperable protocol is fundamental to BTP's target of
inter-organisational "appropriate" transactionality).


Peter

> -----Original Message-----
> From: Pal Takacsi-Nagy [mailto:pal.takacsi@bea.com]
> Sent: 24 October 2001 23:50
> To: Cho, Pyounguk; 'Alastair Green'; Mark Little
> Cc: btp
> Subject: RE: [business-transaction] HPs position on BEAs proposal and
> theChoreology response
>
>
> Hi all,
>
> just to clarify one thing. Our proposal was not against the
> Cohesion concept
> per se, but it was against coupling Cohesions with Atoms in the same
> specification and forcing concepts on people, like Superior/Inferior, who
> otherwise would just be interested in Atoms. That's why I don't agree with
> the compliance profile approach, since it does not eliminate the coupling.
> One compromise can be to produce 2 specifications: BTP - Atoms and BTP -
> Cohesions. And no coupling between the two. This approach is in line with
> the layered protocols design principle. HTTP does not have any special
> coupling with SOAP and vica versa. And that's why we all like and
> use them.
>
> Pal

{rest snipped, because I don't want to send it all back)



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


Powered by eList eXpress LLC