RE: [ws-caf] discussion on approaches for web services/ business transaction

["Newcomer, Eric" <Eric.Newcomer@iona.com>]

Guy,

 

A good part of the first day of the F2F is a presentation of the WS-CAF specs.  I hope everything will be clear from the presentation, but if not there will be an opportunity to ask questions and raise issues during the F2F, including anything from these email trails that anyone wants to bring up.

 

I think what we are trying to say about which discussion belongs where is simply that issues related to BTP should be discussed by the BTP TC, while issues about WS-CAF should be discussed by the WS-CAF TC. 

 

WS-CAF does not define a composite application so strictly.  It defines a composite application as a set of Web services that share a common context.  Optionally, the context can be used to drive one or more recovery scenarios described in WS-TXM or other similar specifications.  WS-CAF separates context management from transaction management so that a global failure scenario is only one of several possible scenarios.

 

Anyway, I hope this will all become clearer during the presentation and discussion this week.

 

Regards,

 

Eric

-----Original Message-----
From: Guy Pardon [mailto:guy@atomikos.com]
Sent: Monday, December 01, 2003 5:25 PM
To: Mark Little
Cc: ws-caf@lists.oasis-open.org
Subject: Re: [ws-caf] discussion on approaches for web services/ business transaction

Hi Mark and Robert and everyone,

Did you mean that we are not going to talk about it in the f2f? I was actually hoping that we _could_ discuss this in the meeting...

I believe that the CAF proposal defines a composite application as one where the unresolved failure of at least one participant task leads to global failure of the whole thing. Under this definition 2PC is certainly sufficient because it guarantees (within limits of course) that the whole composite thing is really canceled everywhere in case of any participant failure.

The question (for me at least) is whether you can do with less (such as 1PC).

Best,

Guy

On maandag, dec 1, 2003, at 11:06 Europe/Brussels, Mark Little wrote:

Robert, I get the distinct feeling we are going round in circles. You have

yet to prove that a single protocol is suffice for all situations. BP

doesn't say that it should be used in all situations and that isn't the case

for WS-TXM.

Sorry for the brief response, but I have to prepare for the WS-CAF

face-to-face and I suspect all of this discussion is out of scope for that

TC.

Mark.

----

Mark Little,

Chief Architect, Transactions,

Arjuna Technologies Ltd.

www.arjuna.com

----- Original Message -----

From: "Haugen Robert" <Robert.Haugen@choreology.com>

To: "Mark Little" <mark.little@arjuna.com>; "Newcomer, Eric"

<Eric.Newcomer@iona.com>; "WS-CAF" <ws-caf@lists.oasis-open.org>

Cc: <business-transaction@lists.oasis-open.org>

Sent: Sunday, November 30, 2003 10:15 PM

Subject: RE: [ws-caf] discussion on approaches for web services/ business

transaction

There are good reasons for having specific protocols and

against generic ones

Sure. Tightly-coupled internal transactions...

Now who's being extreme - this is certainly *a* reason

but is neither necessary nor sufficient.

I'll get a little more extreme below...and even claim that WS-TXM makes

the case for a generic protocol.

and on occassion vice versa.

Loosely-coupled external transactions, especially spanning different

companies.

Same as above.

Consider the case of participants (not coordinators) in loosely-coupled

external transactions.

If I have a generic protocol, I can develop generic participants and

[enrol|enlist|register] them in any business transaction.

In other words, those participants would be freely composable.

If I don't have a generic protocol, then I need either different

participants for each protocol or adapters-with-mappings for each

protocol.

The participants would not be freely composable.

You could propose a protocol to be included in WS-TXM

(even BTP I suppose) that accomplished the things you want to see.

I think even BTP is too complicated for the generic participant. I

don't see any cost-effective justification for a loosely-coupled

participant to care whether the business transaction is atomic, or

cohesive, or whatever. Coordinator, yes; participant, no.

I know the argument about wanting more guarantees about participant

behavior, but if it's externally undetectable behavior (e.g. Isolation),

you can't enforce the guarantees anyway.

** Rash Claim **

Actually, WS-TXM has its own attempt at a generic protocol: BP.

Describing interposition between subdomains, the WS-TXM-BP spec says:

"Each domain is represented by a subordinate coordinator that masks the

internal business process infrastructure from its parent. Not only does

the interposed domain require the use of a different context when

communicating with services within the domain (the coordinator endpoint

is different), but each domain may use different protocols to those

outside of the domain: the subordinate coordinator may then act as a

translator from protocols outside the domain to protocols used within

the domain.

"For example, a domain may be implemented entirely using the OASIS BTP

with the interposed coordinator responsible for mapping BP protocol

messages into BTP's atom or cohesion messages and vice versa. Another

domain (possibly in the same overall business process) may use the OMG's

Object Transaction Service (OTS) and therefore provide an interposed

coordinator to translate between the BP model and the OTS. The important

point is that as far as a parent coordinator in the BP hierarchy is

concerned it interacts with participants and as long as those

participants obey the BP protocol, it cannot determine the

implementation."

In which case, assuming the BP protocol could work as described, then it

is a universal protocol. So either WS-TXM has its own proof of the

feasibility of a universal protocol, or WS-TXM-BP won't work as

advertised.

I think BP is too complicated and contains too many sub-protocols to be

a good candidate for a generic protocol, but that's beyond the arguments

for and against the concept and on to the more-interesting discussion of

what makes a good generic protocol.

Dr. Guy Pardon ( guy@atomikos.com )

Atomikos: Your Partner for Reliable eBusiness Coordination

http://www.atomikos.com/

The information in this email is confidential and only meant for the addressee(s). The content of this email is informal and will not be legally binding for Atomikos.