[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 53 - Should include Business Transaction Management(BTM) programming constructs compatible with WS-T, BTP and WS-TXM
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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]