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

[David RR Webber - XML ebusiness <Gnosis_@compuserve.com>]

Peter,

Excellent summary of the points here.   This was exactly what my
reference to the "choice point" technology that BCM is developing
was all about yesterday.   

Basically if you take each of your paragraphs here
and then go read Appendix B of the BCM spec's you get a large
"YES" tick mark against each one!

The BCM folks have started a sub-team on this all - so I believe
that is the right vehicle to build that out into.   As you say - this is
not a BPEL deliverable - but BPEL can easily exploit the 
choice point tools and WSDL to implement the "linking and
switching" that it needs.

I believe we can make this seamless - as BPEL appears to 
have all the right "hooks" already to be able to interface to
a choice point system - all we need to do at this point is
formulize the actual interface and bindings so we have
consistency.

Looking forward to working this more with those interested
in this area.

Thanks, DW
Choice Point team lead, BCM TC.

Message text written by "Furniss, Peter"
>prf:  I believe there might be different questions about context as
manipulated within a BPEL-specified process and how it gets carried
between such (i.e. between web-services). 

A business transaction can be, within a BPEL process, created,
terminated or registered with. It also needs to be propagated outward
and its incoming propagation accepted. From a BPEL perspective, a
business transaction context, as the representation of the business
transaction, is characterised by the ability to do those things to it.
Another kind of context would be handled in a different way, though
perhaps with some overlap on the propagation capabilities. Making the
answer to issue 55 (b t propagation) applicable to other contexts could
be just a matter of minor bpel syntax - perhaps just appropriate naming
of attributes.

How the context gets carried, and how large a range of functionality can
be put in context elements with a common ancestral type is another
question, and one which a particular BPEL script can largely defer the
WSDL. Allowing too wide a range of functionality might end up just
re-inventing the soap:header element - the different functions have to
be distinguished by the uri's, which is how (via namespace uri's)
headers are distinguished, and a general-purpose context just becomes
another bag for labelled mixed tricks.  But I'm not sure this is a bpel
problem.
<