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] 9/14/2003: Issue 53-59 Feedback on Business Transactions


 
 On initial review, the Business Transaction Management proposal from
 Choreology has sound technical underpinnings.  However, the WS-BPEL
 TC should discuss whether standard language extensions should be defined 
 in BPEL to accomodate externally coordinated completion. If extensions 
 are defined, this could impact BPEL code portability. This may provide 
 an argument to consider defining the transaction context outside of BPEL 
 (possibly as a context type for business transaction).  On this final 
 assumption, minimum pre-requisite is a set of clear 
 definitions/distinctions between business transaction, transaction and 
 relationship to business process.  In addition, should the TC consider 
 whether a WSDL binding for business transactions be defined?
 
 In general, opening up the scope or process for external coordination, 
 would entail more sophisticated machinery and associated state handling 
 beyond the lifetime of a process instance.  The current compensation 
 constructs are not fully specified and do not appear to support this 
 sophistication (as evidenced by the several issues we have logged
 on compensation).
 
 In looking at these two discussion items and the broader behavioral 
 model, business transactions may be more appropriately understood by the 
 global model with a view that is 'available' to the business process 
 orchestration (i.e. BPEL). Whether this becomes a discussion item our 
 liaison with WS-Choreography could be entertained.
 Notwithstanding the comments above, if externally coordinated 
 completions are to be properly supported, two coverage areas (at a 
 minimum) exist:
 
 1. The semantics of 'enableInstanceCompletion' has to be fully 
 specified. Specifically, how to associate a compensation handler for a 
 process instance, that may be invoked only after the process instance 
 goes away. This applies to processing at the participant site in a 
 coordination hierarchy.
 
 2. The BPEL language extensions to support initiating and completing 
 coordinated actions or virtual scopes that span across process 
 instances. This applies to processing at the root site in a coordination 
 hierarchy.
 
 These discussion points span across or touch on several issues 
 including, but not limited to: 3, 5, 6, 10, 20, 21, 25, 27 (if condition 
 allowed), and 30. Likely, we will get ample time to discuss these dependencies,
 opportunities and technical options in the F2F this week.

 Thanks.




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