[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, Yes, macros cannot solve the problem and you nicely explained the reason. Issue #2 is about design but has an impact on execution as well (e.g. propagation of faults, cancellation, compensation handling). Kind regards, Ivana > -----Original Message----- > From: Eckenfels. Bernd [mailto:B.Eckenfels@seeburger.de] > Sent: Mittwoch, 12. November 2003 19:21 > 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/le > ave_workgroup.php. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]