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

["Furniss, Peter" <Peter.Furniss@choreology.com>]

Monica Martin sent:

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

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.

Peter

------------------------------------------
Peter Furniss
Chief Scientist, Choreology Ltd

   Cohesions 1.0 (TM)
   Business transaction management software for application coordination

web: http://www.choreology.com
email:  peter.furniss@choreology.com
phone:  +44 870 739 0066  <-- new, from 4 August 2003
mobile: +44 7951 536168