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

["Ugo Corda" <UCorda@SeeBeyond.com>]

Ron, you say:

> 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."

Edwin's original message seems to indicate otherwise. Also, let's not forget our assumption that most likely business analysts will not get their hands dirty with the actual code, but rather use visual tools that will automatically generate the actual BPEL code.

Ugo

> -----Original Message-----
> From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
> Sent: Thursday, November 06, 2003 11:23 AM
> To: Ugo Corda
> Cc: wsbpel@lists.oasis-open.org
> Subject: Re: [wsbpel] Issue - 2- requirements for a sub function
> solution
> 
> 
> 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
> >  
> >
> 
>