Re: [wsbpel] Issue - 2- requirements for a sub function solution

[Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>]

Harvey,

Harvey Reed wrote:

>Which brings us full circle to a much earlier question:  Can this
>convenience of sub-process be implemented by a tool that has "libraries" to
>choose from? Then its not a question for BPEL.
>
>If we want BPEL to provide something the high level choice is clear:
>
>1. A simple way to do local data processing (no invoking with all that
>implies)
>
>2. A full blown process with compensation/fault handling, etc
>
>
>I don't think there is much in between. 
>
    We may have an issue with concepts/terminology here. We are 
discussing compositional models for processes; sub-processes are a 
traditional, tried-and-true approach. We are also discussing service 
composition, which is a primary characteristic of BPEL. Aren't these 
logically two separate forms of composition? Must be necessarily embrace 
a single mechanism to perform both types of composition?

>If this is right, then we have three
>choices: (a) let a tool do it in libraries; (b) have some local data
>processing subroutine (with some semi-painful parm passing); (c) just make
>another BPEL process if you want to encapsulate something that has invokes.
>
To (c) we should note that painful <assign> activities are needed to 
pack and unpack such requests and responses (I believe Yaron 
characterised them as "gnarly").

As an alternative, I would add Edwin's point that a sophisticated 
deployment/run-time system could recognise sub-process "invokes" and 
avoid the full cost of serializing the logical messages.  This has the 
advantage of not affecting the language (and language doesn't get in the 
way of such innovations).

>
>++harvey
>  
>

Cheers,
-Ron