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: [wsbpel] Issue - 53 - Should include Business Transaction Management(BTM) programming constructs compatible with WS-T, BTP and WS-TXM]


David RR Webber - XML ebusiness wrote:

>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.   
>  
>
mm1:  Perhaps we should get back to the original question.  Is context 
important? Yes. What context is important to BPEL?  In the 
specification, we have at least initially: message (security, 
transaction, and middleware), conversation, behavior, to start.  Does 
this restrict context to transactions? No.  Are there some near-term and 
manageable benefits to understanding lightweight options to understand 
context at least as it is identified in the 1.1 (May 2003)? Yes.

Whether or not it is 'BPEL problem', as Peter asks is another question 
(and a topic of discussion for the F2F on whether transaction context is 
explicitly defined, and what a transaction 'is' to BPEL).  My inquiry is 
not for/against the proposal but recognizing that BPEL has several 
contexts already, including 'transaction.'

Thanks.

>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.
><
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
>
>
>  
>




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