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

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

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

> -----Original Message-----
> From: Edwin Khodabakchian [mailto:edwink@collaxa.com]
> Sent: Wednesday, October 29, 2003 3:51 PM
> To: ygoland@bea.com; 'Trickovic, Ivana'; wsbpel@lists.oasis-open.org
> Cc: B.Eckenfels@seeburger.de; arkin@intalio.com; 'Liu, Kevin'
> Subject: RE: [wsbpel] Issue - 2- requirements for a sub function
> solution
> 
> 
> Yaron,
> 
> We have gone back and forth on this requirement: 
> 
> Our first implementation of BPEL had an extension for allowing the
> definition and execution of sub functions. We found out that 
> people were
> confused on where to use a scope, a separate process and a 
> sub-function.
> What we are seeing it that people end up using scope for grouping and
> separate processes for isolation and reuse (specially given that most
> engines will have internal optimization for inter-process 
> communication
> within the same engine). 
> 
> We find that people do not really care about having to 
> redefine/partition
> the declaration of port types and variables across process definitions
> because this is important for increasing the level of 
> isolation and level of
> decoupling.
> 
> The part that is important and let to interpretation of 
> implementators is
> how WS-T can be used to propagate cancellation across 
> instances and how to
> align the state of the instances during a compensation/cancellation.
> 
> Anyway, this is just food for thoughts...
> 
> Edwin
> 
>