RE: [wsbpel] Issue 53 - Motion for consideration by the TC

["Green, Alastair J." <Alastair.Green@choreology.com>]

I didn't read Bob's comment to suggest substituting BTM for
intra-process compensations. No one has proposed that. 

What does all this "experience versus ignorance" come down to?

The compensation approach implies 

1) an initial action
2) delivery of one signal ("COMPENSATE"), which can be handled. 
3) The context required to forget the ability to compensate is deleted
when a signal to "FORGET" is delivered
4) the completion signal is delivered implicitly by going out of the
outermost scope of the process. 

In BPEL processes these two signals are delivered internally within the
implementation of an execution engine. 

The business transaction management approach implies 

1) an initial action 
2) delivery of two signals: "CONFIRM" and "CANCEL" which can both be
handled by the application
3) procedural or scope-based control of delivery of these two completion
signals (either approach is viable)

As proposed (to avoid re-engineering existing products) these signals
are delivered externally to an instance of an execution engine
(presenting as a web service).

CANCEL can equal COMPENSATE. CONFIRM can equal FORGET. That's my choice
as a user. Or CANCEL can just as well equal "erase the provisional", and
CONFIRM can equal "finalize the provisional". That's also my choice.

To paraphrase Yaron, the industry has decades of experience of this BTM
model in each of its three flavours: 

1) in its tightest form, (where the initial action blocks contenders for
the updated resources) it uses the model of degree-3 consistency
database transactions, messaging and XA transactions. (The only
difference is that cancel and confirm are application-defined, specific,
whereas commit and rollback are resource-defined, general.)

2) in a more relaxed mode, (where initial action follows
contract-defined rules on visibility of partial changes), we see
behaviour analogous to relaxed isolation level databases, or various
very widely-employed techniques for application-level guard locking,
cache refreshing etc.

3) in its most laid-back mode (where the initial action is just "do it",
and don't worry about the side effects), we have the (very much less
widely utilized) compensation model.

All three of these modes can be seen at work in JCA adaptors, by the
way.

It is very difficult to see why the constrained "do-compensate" model
(which makes intermediate work totally visible) is so much better
understood from our collective experiences. (And I would add
parenthetically that most experience of any of this comes, not from Web
Services, but from earlier attempts at service orientation.)

But the nub of the matter is captured by Yaron's absolutely correct
comment on the extreme challenge of doing this type of work by hand. Any
of these three modes of BTM are extremely challenging to program by
hand. Research we are currently conducting on "roll your own with
reliable messaging" versus our Cohesions BTM product indicates that the
productivity gain (measured in lines of effective, comparable code) is
at or above ten-fold. The hand-crafted solutions imply great knowledge
and high awareness of recovery and reliability techniques, which are not
the useful purview of application programmers, let alone business
process designers and modellers.

It isn't good enough to point out that there are intricate circumstances
which will require fine-grained application control over the whole
coordination interaction. No-one is proposing to alter or remove the
fine control. But it is proposed to neuter the facilities of BPEL when
it comes to business transaction processing.

Let's be generous. Eighty per cent of coordinated activities do not
require anything more than what we have proposed. They do not even
require parameterized (app data qualified) CANCEL and CONFIRM messages
-- not that that capability would be hard to accommodate in the
proposal. It is a standing part of our pretty simple product API, for
the rare cases where it may be used.

I believe that Satish's desire to deny the simplifying sophistication of
BTM to business process definers is a) wrong intrinsically, b)
short-sighted in terms of the likely overlap in lifecycle of the BPEL
and BTM standards, and c) utterly mystifying as the stance of a leading
technical representative of a company publicly committed to introducing
Web Service business transactions in both atomic and business activity
styles. 

Are Microsoft, IBM and BEA really telling their customers and the
industry at large: "coordination of application services is so much
easier than coordination of resource managers that we recommend you do
it yourself"? 

Over time I doubt we will see such a stance persisted in. I believe the
committee should not follow this erroneous lead.

Alastair




Alastair J. Green
CTO and Director
Choreology Ltd
68 Lombard Street
London EC3V 9LJ
www.choreology.com
 

-----Original Message-----
From: Yaron Goland [mailto:ygoland@bea.com] 
Sent: 20 January 2004 00:55
To: Haugen Robert; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue 53 - Motion for consideration by the TC

Issues 53-59 only address global scope compensation and only in the case
of an external message sent in the context of a distributed transaction
protocol.

BPEL's compensation handlers are available at all scopes and cover all
types of compensation triggers not just external messages from
distributed transaction protocols.

So clearly Issue 53-59 cannot substitute, as you suggest below, for
BPEL's existing compensation mechanism.

Regarding your question on (b), I can speak for my customers in saying
that cascading compensations happen all the time in their Web Services.
That is, an event triggers compensation inside a Web Service which then
causes a cascading set of compensations to occur in the Web Service.

The problem is that this design pattern has to be implemented by hand,
which is extremely challenging. However, having seen this design pattern
for many years in Web Services we now have sufficient experience to
design an optimization to make matters simpler, this is where the
cascading compensation features in BPEL come from.

For reasons previously stated similar experience is lacking with
distributed transactions which, again, is why the optimizations in
issues 53-59 are premature and hence should not be adopted.

		Yaron


> -----Original Message-----
> From: Haugen Robert [mailto:Robert.Haugen@choreology.com]
> Sent: Tuesday, January 13, 2004 11:41 AM
> To: wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue 53 - Motion for consideration by the TC
> 
> 
> Yaron Goland wrote:
> 
> > The BPEL group has a vast vein of experience to mine 
> > in creating a simplified local compensation framework 
> > as customers have been implementing local compensation 
> > handlers on every Web Service product and platform 
> > since the dawn of web services. 
> 
> Do you mean:
> 
> (a) simple local undos per Web service?
> 
> or
> 
> (b) cascading Compensations with nesting and links as in BPEL?
> 
> I don't think (a) qualifies as experience with (b).
> 
> Moreover, I think local undos can fit into a business transaction
> framework such as we're proposing, as easily (maybe more easily) than
> they fit into the BPEL cascading Compensations.
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> ave_workgroup.php.
> 
>