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

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

Ugo,

    What we are debating here is a compositional model for processes. I 
don't think it is accurate to characterise this as a solution looking 
for a problem; it is an alternative solution to a problem that BPEL 
solves in an unconventional fashion.

    I say unconventional, since this problem has been addressed in 
countless process languages in the past. The most widely used 
compositional model is sub-processes. Composing processes at a services 
level is unusual, and arguably runs counter to what analysts have come 
to expect. Only a software technologist would find the approach "natural."

    As mentioned elsewhere in this thread, sub-processes can range in 
execution sophistication from a "macro" language to full-blown 
distributed process execution. I believe Yaron was proposing something 
on the more modest end of this spectrum.

    I don't think that the discussion should be centred on proving that 
process composition at the service level is provably "wrong" or "just 
plain broken." The question should be "what is the best compositional 
model we can standardise?" To debate it otherwise is simply trying to 
rig the outcome of the process.

-Ron

Ugo Corda wrote:

>I just reread this message after reading the latest ones on this thread, and it made me wonder whether we have real good reasons for pursuing this sub function/process requirement. In other words, are we working on a solution in search of a problem?
>
>I understand the difference between calling real sub processes vs. calling a separate process offered through a Web service interface. What is not completely clear to me is why we cannot use the latter mechanism in all cases we care about. Edwin's message seems to indicate that users naturally gravitate toward using separate processes even in reuse cases.
>
>It cannot be an issue of communication performance because, as people already mentioned, we could use protocols/transports other than SOAP/HTTP when communicating within the same machine.
>
>I understand the risk of mistaking the external process for a regular partner, but that could be fixed by using some appropriate attribute (or other syntactic mechanism) to distinguish the two.
>
>I guess what I am looking for is some use case that shows how it would really be wrong to use an external process to model the concept of a subprocess, listing all the drawbacks related to that use (or, even better, showing that it is simply impossible to achieve that goal).
>
>Ugo
>  
>