OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Bernd,

I am not sure I fully understand your point, but just in case you are equating the WS approach with inline macro generation, I would like to point out that the two have no relation. (Sorry if I just misunderstood your point - I guess what confuses me is your statement below: "This alone can be an argument pro-subfunctions").

Ugo

> -----Original Message-----
> From: Eckenfels. Bernd [mailto:B.Eckenfels@seeburger.de]
> Sent: Wednesday, November 12, 2003 10:21 AM
> To: wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue - 2- requirements for a sub function
> solution
> 
> 
> Ivana, this is a good point, reading it the second time I 
> understand your issue:
> 
> - even when the design tool will allow macros for reuse (i.e. 
> "send mail to admin on compensation flow") it is currently 
> forced to inline all the activities multiple times in the 
> resulting process definition. It could use xml entities, but 
> it does not change the fact that the infoset is much bigger. 
> this could effect engines ability to "compress" the process 
> templates. This alone can be an argument pro-subfunctions.
> 
> One option  would be to use id/href type of inclusion. This 
> solves the inline problem, but not the "sharing of fragments" 
> nor the "describe intend of modeller" problems.
> 
> Mit freundlichen Grüßen
> Bernd Eckenfels
> Chief Architect
> --
> SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany
> Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256
> mailto:b.eckenfels@seeburger.de - http://www.seeburger.de
> 
> 
> -----Original Message-----
> From: Trickovic, Ivana [mailto:ivana.trickovic@sap.com]
> Sent: Monday, November 10, 2003 4:52 PM
> To: 'satisht@microsoft.com'; 'UCorda@SeeBeyond.com';
> 'edwink@collaxa.com'; 'ygoland@bea.com'; 'wsbpel@lists.oasis-open.org'
> Subject: RE: [wsbpel] Issue - 2- requirements for a sub function
> solution
> 
> 
> 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.
> > 
> 
> 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/leave_workgroup.php.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]