RE: [wsbpel] Issue - 121 - <finally> construct

["Edwin Khodabakchian" <edwink@collaxa.com>]

Hi Bern,

I believe that the scope wrapping feature is not enough because sometimes
the inner scope will complete successfully and sometimes the inner scope
will rethrow the exception which ends up being 2 execution paths from the
perspective of the wrapper scope.

Regarding transactions, here again I am not sure that something like
WS-BusinessActivity or even a context service would address the problem
given that each final call includes application level data.

Best,
Edwin 

-----Original Message-----
From: Eckenfels. Bernd [mailto:B.Eckenfels@seeburger.de] 
Sent: Tuesday, April 27, 2004 10:50 AM
To: wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue - 121 - <finally> construct

Hello Edwin,

you can simulate the finally semantics with a scope inside the scope. You
might need to add a rethrowing catch-all fault handler. Effectively you then
have two places where you have to clean up, but most likely those differ
anyway.

<sequence>
  <invoke name="reserve-ressource">

  <scope name="do something with multiple exits" />

  <invoke name="free-ressource">
</sequence>

Personally I agree, that a finally is nicer. 

However: I am not sure if reserving external ressources is a use case we
should optimize for, since this will get the customer into troubles sooner
or later anyway. Dont ha your busienss transaction support in your engine,
and can use that much more robust for reserving ressources and establishing
and tearing down sessions with them? This would be best solved with business
transactions, anyway.

Mit freundlichen Grüßen
Bernd Eckenfels
Chief Architect
--
SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany
Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256
mailto:b.eckenfels@seeburger.de - http://www.seeburger.de


-----Original Message-----
From: Edwin Khodabakchian [mailto:edwink@collaxa.com]
Sent: Tuesday, April 27, 2004 8:17 PM
To: 'Dieter Koenig1'
Cc: wsbpel@lists.oasis-open.org
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

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.