One protocol, one context ...

[Alastair Green <alastair.green@choreology.com>]

Mark,

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.

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

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.

2) An initiating application (the party) requests operations provided by
application services (the counterparties). Operations are bundled into
atomic groups, which are able to have a bilateral conversation with the
cohesion coordinator, 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).

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

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

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

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 believe the protocol I've sketched above can support any of the use
cases or models cited thus far (including sagas and glued actions), 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).

Yours,

Alastair

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.

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