[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 121 - <finally> construct
Dieter, Here are the 2 use cases that we have seen that are driving this request for enhancement. Use case 1: releasing resources. Scope Invoke to establish for secured session (token) other interactions based on the session catch (1...N) error management rethrow finally Invoke to close secured session Use case 2: shared space Scope Invoke to create shared space Other activities catch(1...N) error management rethrow finally Invoke to release resources associated with shared space The problem is that without a finally construct, the logic embedded in the finally needs to be replicated in every catch and at the end of the scope. We are happy to try to put you in contact with the specific customers who submitted those enhancements if you have additional questions or require additional details. Best, Edwin -----Original Message----- From: Dieter Koenig1 [mailto:dieterkoenig@de.ibm.com] Sent: Monday, April 26, 2004 10:44 PM To: gmi@collaxa.com Cc: wsbpel@lists.oasis-open.org Subject: Re: [wsbpel] Issue - 121 - <finally> construct Glenn, do you have a concrete business process scenario for the finally construct (which is broken without it)? Thanks in advance! Kind Regards DK ws-bpel issues list editor <peter.furniss@ch To oreology.com> wsbpel@lists.oasis-open.org cc 20.04.2004 11:13 Subject [wsbpel] Issue - 121 - <finally> Please respond to construct wsbpel This issue has been added to the wsbpel issue list. The issues list is posted as a Technical Committee document to the OASIS WSBPEL TC pages on a regular basis. The current edition, as a TC document, is the most recent document with the title in the "Issues" folder of the WSBPEL TC document list - the next posting will include this issue. The list editor's working copy, which will normally include an issue when it is announced, is available at this constant URL. Issue - 121 - <finally> construct Status: open Categories: Scopes, Fault handling Date added: 20 Apr 2004 Submitter: Glenn Mi Date submitted: 20 April 2004 Description: Currently there is not a construct allowing developers to define a fragment of BPEL code that needs be executed any time a scope is exited (whether it be a normal exit or due to a fault). Submitter's proposal: Add a finally construct to the <scope> activity. Credit: the issue and resolution was suggested by Jerry Thomas (CenterStone Software) Changes: 20 Apr 2004 - new issue To comment on this issue, please follow-up to this announcement on the wsbpel@lists.oasis-open.org list (replying to this message should automatically send your message to that list), or ensure the subject line as you send it starts "Issue - 121 - [anything]" or is a reply to such a message. To add a new issue, see the issues procedures document (but the address for new issue submission is the sender of this announcement). 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 . 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]