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

[Harvey Reed <hreed@sonicsoftware.com>]

Maybe I don't understand this issue at all, please help me out:

1. I think we are talking about sub-processes in the context of reuse, and I
think your email reiterated that.

2. The two obvious choices for reuse are:
(a) inline textual reuse, which some people have suggested tools can help;
(b) another BPEL process

3. Why don't I think there is an in between ground? Because if you want to
do useful work in the sub-process, that implies a coordinated shift of
state, a.k.a. subject to transactional control, which drags in all the
handlers. Then you are just a short hop from a full BPEL process.

Please show me how useful (transactional) work can be done, with
reusability, that isn't one of the above 2 choices.

For me, this issue isn't so much about philosophy of programming languages
(although that is an interesting area, and I was co-author of a programming
language while at Motorola); the issue is instead a practical one of how to
accomplish useful work in a sub-process.

++Harvey



-----Original Message-----
From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM] 
Sent: Friday, November 07, 2003 12:34 PM
To: Harvey Reed
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 2- requirements for a sub function solution

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