OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

bt-models message

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

Subject: Re: One protocol, one context ...

> As I expressed in tonight's phone call meeting of the models
> sub-committee, I think that we should be careful not to load up this
> standard.

I agree that a simple model is a key part of the take-up.

> It seems like 99 per cent of use cases, requirements etc can be handled
> with a pretty simple approach. (Not *very* simple, or we lose any
> benefit from the protocol).

That remains to be seen since we have had no use cases submitted by anyone

> 1) Services that want to take part in "business transactions" offer some
> group of operations (maybe only one), and a reversal operation (cancel).
> They also offer a confirm, and a prepare. That's all it takes to write a
> new cohesion-capable service, or to wrap a legacy app. Cancel/confirm
> contents are up to the service writer.

What happens if cancel fails? I've asked this question several times (and
it's in our submission too), but haven't had a pragmatic answer yet.

> 2) An initiating application (the party) requests operations provided by
> application services (the counterparties). Operations are bundled into
> atomic groups,

I'd prefer "atomic units", since "group" is already overloaded in the
distributed object/service arena.

> which are able to have a bilateral conversation with the
> cohesion coordinator,

or "conductor"

> to establish whether each group is good to go
> (forward or back). The initiating party decides which groups it wants in
> or out (or it delegates that decision to some trusted agent). The groups
> left in at the end are the outcome of the cohesion.


> 3) We use the well-known 2PC exchanges to coordinate the atomic groups
> (get their vote). Single phase services can come first or last to obtain
> relatively safe integration. The application business process decides
> the final outcome of the overall cohesion (no standard protocol
> involved, part of the collaboration layer).

2PC is fine for many applications, and can probably be used to implement 95%
of our use cases (when we finally see them :-) !) Whether it's the most
efficient for a given situation/application is a different matter. However,
to have something to implement against is probably more important at this
stage, so I agree that keeping it simple (with some flexibility in, say, the
context) is the way to go.

> 4) We have enlistment and delistment, from above, and from below; we
> deal with the time-in and time-out cases, from above, and from below.
> (Nobody can be compelled to stay in a cohesion if they don't want to).

Agreed, and a cohesion (or whatever we call it) can be formed as late as the
end of the first phase.

> 5) We have one context type, containing cohesion and atomic ids,
> implementation data for the added-value, time qualifications (as in your
> example). We define how this gets piggybacked by app messages (and say
> nothing more about how app messages get delivered, despatched etc).

If the context type can later be used for extensions (e.g., 3 phase) then

> 6) We allow boxcarring (do/prepare, enlist/vote) through multi-headers,
> to minimize net traffic. The minimum case one-shot service then looks
> just like the BEA submission (no loss of concision).


> And that's it. Hopefully these are low requirements on the application
> builder, and relatively low requirements on the implementor.
> I believe that ease of use and understanding are critical, as is speed
> to "market". Therefore we should not introduce provision for protocols
> (3PC etc) that have had no commercial take-up thus far, and which are
> very ill-suited to a loosely coupled environment. If the need is
> established in the future for an additional protocol it would be easy to
> retrofit it. (We could even leave a protocol field in the context, value
> 0, to allow for future upgrades.) 2PC is well understood, and
> well-documented. This will aid developer understanding.


> On the other side of the argument I think you must have a two-phase
> approach or you deny the application vital information that it needs to
> decide whether to retain or discard participants (including information
> about participant quitting). If we lose multi-phase exchange (voting) we
> will simply end up with workflow (which is good and useful but not a
> BTP).

I think that whatever we come up with 2PC has to be one of the
defacto-standard protocols.

> So, on pragmatic grounds (desire to see this standard get done, and get
> traction) I think we should not try to incorporate the Activity Service
> approach into this standard (your CL/CD model). Use of the AS may be a
> good implementation choice, and it can aid thinking about the problem,
> but I don't believe it should obtrude into the fundamental design.

I agree that the configurability aspects of coordination/control I mentioned
in an earlier email (and illustrated in the HP submission) may well clutter
the landscape a bit. The activity service framework was never designed to be
used raw (and was presented simply as an example of how extended
transactions could be implemented). It may also be more general than is
required for BTP. However, one of the advantages that such a CL/CD
separation gives is the ability to coordinate at points other than the
termination of the BT, which is useful for a different classification of
transaction models (e.g., recovery-block transactions,
split/join-transactions). If during the execution of an activity it is
desired to run coordination between the participants which will not
necessarily cause the termination of that activity (e.g., simply voting to
allow another participant in and to replace an existing participant), then
this flexibility is useful. In the BT world, however, it's an unknown

> I believe the protocol I've sketched above can support any of the use
> cases or models cited thus far (including sagas and glued actions),

I'm still unsure about the efficiency/implementation impact on glued
actions, but sagas definitely.

> can
> handle single-shot (stateless) web services and stateful,
> multi-operation services (e.g. order plus shipping), and can (if
> required) be extended easily to incorporate nesting.
> My personal view is that we should exclude all capability discovery and
> contract negotiation from this standard effort, on grounds of time, with
> the sole exception of a MUST UNDERSTAND-style attribute in the context
> header, so that cohesion-incapable recipients get a chance to bow out (a
> la Keith's point at the last sub-committee call).

Agreed. This is a whole other standardisation effort!

> PS I have taken the liberty of cc'ing this to the main list, as it
> concerns the overall scope and direction of the TC.

No problem.

> PPS I will write up notes on the terminology discussion on Wednesday,
> and deliver you the real-time trade execution scenario that day also.
> Apologies for the delay.

That's fine. I'll email to the models subcommittee what we discussed about
terminology tomorrow.

All the best,


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