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

["Trickovic, Ivana" <ivana.trickovic@sap.com>]

I do not believe we are "working on a solution in search of a problem". I may agree that specifying subprocesses as BPEL processes and calling them as (Web) services is (more) elegant solution but the BPEL specification must be improved in those parts addressing error handling and compensation handling (and partner link types - but this is a minor issue). I do not believe that any part should be (in case of subprocesses) simply delegated to WS-T. I would like to keep BPEL independent of the WS-T specification. 

Regards,

Ivana 

> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: Donnerstag, 6. November 2003 07:17
> To: Ugo Corda; wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue - 2- requirements for a sub function
> solution
> 
> 
> Thanks for pointing out Edwin's earlier mail Ugo.  I seem to 
> have missed it.  I am in complete agreement with Edwin and 
> (apparently) with you on this.
> 
> ________________________________
> 
> From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> Sent: Wed 11/5/2003 4:01 PM
> To: wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue - 2- requirements for a sub 
> function solution
> 
> 
> 
> 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
> >
> >
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> ave_workgroup.php.
> 
> 
> 
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> ave_workgroup.php.
>