OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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


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

At a minimum a URI will do, since the context is a correlator id and needs
to be unique. A URI should fit with all of the context schemes being
proposed at the moment too.

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

Agreed.

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

At the BPEL level I would imagine that a handle or reference (or URI) to a
context is all that is required. You don't need to know what's in the
context in order to reason about it. When you come to use it (e.g., register
a participant), the information becomes relevant, but even then it can be
implicitly left up to the user to determine how to get that information (or
even whether or not there is any).

Personally I think that if a context format is required in BPEL then we
should consider it as a context element/entry that can be embedded in some
other structure if necessary (e.g., a WS-C context or a WS-Context context
structure).

Mark.

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