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


The BCM TC is already working on this - and have the draft Appendix B 
posted at their team documents site.

There is also a PPT available from http://dfas.info 

under "BCM" / and then "Choice Pt presentation"

that discusses the approach and rationale.

I mentioned this in my liaison report on our last teleconference 

I believe it would make sense to formally liaise with the BCM team
on this and jointly work out technical details on how the technology
pieces can best fit together.

Clearly choice points have many possible applications WRT BPEL,
however - it comes down to a design decision on how much needs
to be bitten off and chewed at this stage of the game - and how much
can be tabled and worked on in parallel in the meantime?

Then a supplemental item is the transaction handling mechanism itself - 
I'd already ntoed elsewhere that should be open - so you can use 
not use XPath and XSLT - but also formal transaction technology like
a CAM processor - or any other external transaction formatting.

Bottom line - what is needed immediately to solve Issues, and what
can we foresee is nice to provide support for coming along in 
subsequent releases?

Thanks, DW
Message text written by Monica Martin

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]