Yaron,
By reading your requirements below, it seems to me that there is another
requirement:
"BPEL4WS MUST add input and output parameters to compensation
handlers".
Yaron Goland wrote:
Here is my view on what the requirements are for
a solution to Issue 2.
Terminology:
Host - This is the process that called the sub-function.
Requirements:
Integration into host fault/compensation model - The sub-function MUST
be
able to throw faults that will propagate to the host. The
host MUST be able
to call compensation handlers defined in the sub-function.
Functional Programming - One of the key concepts of functional programming
is the idea of isolation. Functions in functional
programming systems are
expected to be able to run in their own context and
to only have contact
with the host context through explicit value passing.
The sub-function
solution MUST enable for isolation.
Human Usable - It MUST be reasonably easy for a programmer to read/write
sub-function definitions and calls without requiring the aid of a tool.
By Reference - Messages seem only to get larger with multi-megabyte
XML
messages now commonly seen. Therefore when passing data into a sub-function
it is critical that it be possible to hand over the data by reference
so
that the data does not have to be copied on its way in or out.
Use in Expressions - It MUST be possible to call a sub-function anywhere
one
could call a XPATH or other type of general/query/date expression and
have
the sub-function return the desired value.
Import - A mechanism is needed to allow sub-functions to be defined
in stand
alone files which can then be referenced by multiple BPEL processes.
> -----Original Message-----
> From: Trickovic, Ivana [mailto:]
> Sent: Wednesday, October 29, 2003 5:22 AM
> To: ''
> Cc: ''; ''; Liu, Kevin
> Subject: Re: [wsbpel] Issue - 2- sub functions
>
>
> We should be able to reuse pieces of BPEL code within a
> single process or across multiple processes. The question is
> how these reusable pieces of BPEL code should be modeled and
> integrated in the calling processes.
>
> It seems that one idea would be to model reusable parts of
> BPEL code (sub-processes) as BPEL processes. As Bernd
> suggested some time ago, one way or two-way <bpel:invoke>s
> can be used for asynchronous and synchronous calls,
> respectively, and the specification could also give a
> recommendation how to differentiate between internal and
> external process ports. If we take that approach, we also
> have to review consequences for the control flow, especially
> compensation and error handling. Satish pointed out that the
> BPEL specification includes as its integral part the BA
> protocol defined in the WS-Transaction specification. This
> protocol specifies the parent-child relationship between
> scopes. But, BPEL usage of the BA protocol makes the
> assumption of localized behavior in a single service. If we
> model sub-processes as BPEL processes and use the invoke
> action as mentioned above, we do not have localized behavior
> in a single service anymore. So, what is missing in BPEL is
> the semanti!
> cs!
> for compensation and error handling. It cannot be that for
> the sub-processes protocols such as
> WS-Coordination/WS-Transaction are needed. This semantics
> must be an integral part of the language.
>
> Also, sub-processes will be modeled as partners, which is
> misleading from the modeling point of view and at the end the
> process model will be overloaded with partner link
> definitions (partner links will be used extensively). I
> believe this is also an area where some simplifications
> should be made.
>
> Kind regards,
>
> Ivana
>
> 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.
