Re: [wsbpel] Issue - 53 - Should include Business Transaction Management(BTM) programming constructs compatible with WS-T, BTP and WS-TXM

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

Hi Monica,

I am finally getting to my vacation now that these issues and our 
submission are finalized, so you very likely this is my last message to 
WS-BPEL till after Labor Day :-) .

The question of a super-context is a complicated one. It could be a 
generic way of representing context information (a railway carriage with 
multiple occupants), or it could have a higher meaning, that the 
included contexts are related (i.e. that there is some domain common to 
the utilization of e.g. transactions and security).

Our view is that we should stick with a simple, minimal approach to 
dealing with BTM in BPEL. Until the actual requirements of other 
context-reliant services are clearly stated, there is a strong danger of 
having a debate on super-context which is a) abstract, and b) probably 
competitive with other initiatives. I believe that WS-C's multi-protocol 
capable context fits the bill and is straightforward, but any agreed, 
suitable context holder would do the trick..

There is a lurking background issue, obviously, of how the WS-C, WS-T, 
BTP and WS-CAF initiatives all come to some table to do with 
standardizing BTM for web services -- myself, I would like to see OASIS 
create a "WS-BT" technical committee and get on with it. I know that the 
end-users we work with have a very low appetite for standards 
smorgasbord in this area.

Our proposed approach and related submission document are deliberately 
designed to fit a "universal" API on top of a fluid standardization 
picture -- feasible because there is so much common functional ground 
between the business transaction protocol specs already out there, which 
explicitly or implicitly share a participant-promise/coordinator-decide 
two-phase model. I think that this type of approach will allow at least 
the 80 or 90 per cent case to be readily addressed, which is a good 
starting point.

BTM is an important addition to the BPM picture, and I think we need to 
start simple and straightforward and avoid unwonted multiplicity.

Ever a one to avoid controversy, off to my holidays ...

Alastair

Monica Martin wrote:

> Alistar,
>
>>    1. Business transaction creation, manifested by the creation of a
>>       business transaction context variable.
>>
>>    2. Business transaction context reception and transmission
>>       (propagation) via invoke/receive/reply, allowing sub-transaction
>>       or pass-through behaviour.
>>
>>    3. Process involvement in business transactions as participants,
>>       which can handle positive and negative transaction finalization
>>       messages (by means of confirm and cancel handlers).
>>
> mm1: Context may not only apply to business transactions. Therefore, 
> we may need to consider it separate from business transactions.  For 
> example, would it not be prudent to consider a simple context 
> mechanism that has other utility? Thanks.
>
>
> To unsubscribe from this list, go to 
> http://www.oasis-open.org/apps/org/workgroup/wsbpel. 
> Note:unsubscribing will result in your withdrawal from this OASIS 
> Technical Committee.
>