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:]
> Sent: Wednesday, November 12, 2003 10:21 AM
> To:
> 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: - http://www.seeburger.de
>
>
> -----Original Message-----
> From: Trickovic, Ivana [mailto:]
> Sent: Monday, November 10, 2003 4:52 PM
> To: ''; '';
> ''; ''; ''
> 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:]
> > Sent: Donnerstag, 6. November 2003 07:17
> > To: Ugo Corda;
> > 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:]
> > Sent: Wed 11/5/2003 4:01 PM
> > To:
> > 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:]
> > > Sent: Wednesday, October 29, 2003 3:51 PM
> > > To: ; 'Trickovic, Ivana';
>
> > > Cc: ; ; '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.
