[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 99 - Updated proposal for vote
Hello Jim, The problem is, if a abstract definition contains Sequence invoke exit invoke ... Skipping the exit activity for sure will cause a visible mismatch in the message exchange. Of course the process can be re-implemented to match the message exchange, however in that case it is no longer possible to have a "template" style fill in abstract process. Greetings Bernd -----Original Message----- From: Jim Clune [mailto:jim@parasoft.com] Sent: Friday, May 20, 2005 8:22 PM To: ygoland@bea.com; andrew.francis@mail.mcgill.ca Cc: ivana.trickovic@sap.com; dannyv@tibco.com; wsbpel@lists.oasis-open.org Subject: Re: [wsbpel] Issue 99 - Updated proposal for vote I think the externally visible aspect of a message exchange ends (by definition) when messages are no longer being exchanged. The "exit" activity seems to refer to a private aspect of the process's life-cycle, as there does not seem to be a message exchange directly associated with this activity. It seems to me that the rule of thumb should be that any activity that does not directly involve message exchanges should not be considered externally visible. - Jim Clune ----- Original Message ----- From: "Yaron Y. Goland" <ygoland@bea.com> To: <andrew.francis@mail.mcgill.ca> Cc: <ivana.trickovic@sap.com>; <dannyv@tibco.com>; <wsbpel@lists.oasis-open.org> Sent: Friday, May 20, 2005 10:43 AM Subject: Re: [wsbpel] Issue 99 - Updated proposal for vote My understanding of the purpose of the 'external behavior' profile is to describe all actions that a process will undertake that can be viewed externally to the process. The goal being to describe the order in which a process expects to send and receive messages. A key part of describing such a sequence is knowing when the sequence ends. Without the use of the <exit> activity it is significantly more difficult to describe end states, especially ones that represent an exception to the 'expected' execution path. Yaron andrew.francis@mail.mcgill.ca wrote: > Quoting "Yaron Y. Goland" <ygoland@bea.com>: > > > The use of exit in publicly visible behavior is that it is > >an > unambiguous way of saying that no further action in > the> > communication can occur. > > I believe the only BPEL activities that constitute a process's visible > behaviour are invoke, receive, and reply. These activities, or more > specifically, their associated partnerlinks, messages, and operations, > are exposed to an external observer. I believe that all other > activities are internal. > > I believe a step forward would be for the base profile" to state which > activities are "visible" and "internal." > > Cheers, > Andrew > > > > Reaching the end of the process > > has similar semantics but in many cases a 'sudden' end > may be > needed. For example, if my process has a 'kill > yourself' message > on an event handler then the body would > contain an <exit> to > indicate that no further > communications can occur. > > > > > > > > > > Yaron > > > > Trickovic, Ivana wrote: > >> Currently the <exit> activity is only available for >> executable > processes (+ the common base and all future >> profiles, according > to the resolution for issue 82) and >> it is forbidden for "publicly > visible behavior" (called >> AP 1.1). What would be the semantics of > <exit> in a >> description of publicly visible behavior? > >> > >> > >> > >> Regards, > >> > >> > >> > >> Ivana > >> > >> > ------------------------------------------------------------------------ -------->> > *From:* Danny van der Rijn [mailto:dannyv@tibco.com] > > >> *Sent:* Wednesday, May 11, 2005 1:23 PM > >> *To:* wsbpel@lists.oasis-open.org > >> *Subject:* Re: [wsbpel] Issue 99 - Updated proposal > >> for vote > >> > >> Sounds like we need a new issue allowing the > >> appearance of exit (and all other activities) in > >> abstract processes? > >> > >> Trickovic, Ivana wrote: > >> > >>>Indeed, issue 99 is considering only the AP 1.1 profile >>>(the > publicly visible behavior) and does not deal with >>>other profiles, > including process >>>templates. So, statement "... the <exit> > activity is >>>limited to >>>executable >>>processes" is probably > misleading. I would suggest to >>>change it to "...the >>><exit> > activity is forbidden in BPEL abstract processes >>>describing the > publicly visible behavior" > >>> > >>>Regards, > >>> > >>>Ivana > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Furniss, Peter > >>>>[mailto:Peter.Furniss@choreology.com] > >>>>Sent: Tuesday, May 10, 2005 11:11 PM > >>>>To: ygoland@bea.com; Trickovic, Ivana > >>>>Cc: wsbpel@lists.oasis-open.org > >>>>Subject: RE: [wsbpel] Issue 99 - Updated proposal for >>>>vote > >>>> >>>>I agree with Yaron. As I understood the resolution of > >>>>82, ALL >>>>constructs >>>>of >>>>BPEL could appear in abstract > processes. It's only the >>>>profiles that would >>>>apply a > restriction. The profile for !abstract >>>>processes >>>>to define > publically visible behaviour" (which is what >>>>the ap 1.1 profile > >>>>would be, I think) may forbid exit. Profiles for >>>>templates > (whereever they >>>>get published) would likely allow it. > >>>> > >>>>(actually, given the relation of executable:abstract, > >>>>disallowing a construct in a profile is equivalent to > >>>>requiring it to be >>>>opaqued/omitted, if >>>>we move from > exectuable to abstract) >>>> >>>>Peter >>>> >>>> >>>> > >>>>>-----Original Message----- > >>>>>From: Yaron Y. Goland [mailto:ygoland@bea.com] > >>>>>Sent: 10 May 2005 21:09 > >>>>>To: Trickovic, Ivana > >>>>>Cc: wsbpel@lists.oasis-open.org > >>>>>Subject: Re: [wsbpel] Issue 99 - Updated proposal for >>>>>vote > >>>>> >>>>> >>>>>Why do we limit exit to executable processes? When > did >>>>>we >>>>>agree to that? > >>>>>I honestly don't remember. I don't see a good reason >>>>>to > exclude exit from abstract processes since this >>>>>would negate > the ability to use abstract processes as >>>>>templates which was a > required use case in our >>>>>compromise on 82. > >>>>> > >>>>>Otherwise I'm happy with this text. > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Yaron > >>>>> > >>>>>Trickovic, Ivana wrote: > >>>>> > >>>>> > >>>>>>Per our discussion we had last Wednesday, here is an >>>>>> > >>>>> >>>>>updated proposal >>>>> >>>>> >>>>>>for issue 99. There > is a separate issue (issue 82.3) >>>>>>serving as a placeholder for > refactoring the >>>>>>original definition of abstract processes > (AP1.1) >>>>>>and the work required to produce profile >>>>>> >>>>> > >>>>>for AP1.1. > >>>>> > >>>>> > >>>>>>Nevertheless, based on the proposal for issue 82 and >>>>>>the > >>>>>> >>>>> >>>>>current text >>>>> >>>>> >>>>>>of the > specification the following text should be >>>>>>incorporated. > >>>>>> > >>>>>> > >>>>>>11.4 Providing Web Service Operations > >>>>>>------------------------------------- > >>>>>>Reword first two sentences of the second paragraph > >>>>>>to: > >>>>>>In addition, receive activities play a role in the > >>>>>>lifecycle of AN EXECUTABLE process. The only way to > >>>>>>instantiate AN >>>>>> >>>>> >>>>>EXECUTABLE process >>>>> > >>>>> >>>>>>in WS-BPEL is to annotate a receive activity with the > >>>>>> >>>>>> >>>>> >>>>>createInstance >>>>> >>>>> > >>>>>>attribute set to "yes" (see Pick for a variant). > >>>>>> > >>>>>> > >>>>>>Section on AP1.1 (probably section 15.2 according to >>>>>>the > >>>>>> >>>> >>>>resolution >>>> >>>> >>>>>>for issue 82): > >>>>>> > >>>>>> > >>>> > > > >>>>------------------------------------------------------------------ > ---->>>> > >>>> > >>>>>>-- > >>>>>>---------- > >>>>>>Include the following text: > >>>>>> > >>>>>>The receive activity plays a role in the lifecycle of > >>>>>>executable processes. It is required that executable > >>>>>>processes must >>>>>> >>>> >>>>contain at >>>> >>>> > >>>>>>least one receive activity (or pick activity) that > >>>>>>receives >>>>>> >>>>> >>>>>a message >>>>> >>>>> >>>>>>and > is annotated with the createInstance attribute >>>>>>set to "yes" to > indicate that the occurrence of that >>>>>>activity causes a new > >>>>>> >>>>> >>>>>instance of >>>>> >>>>> >>>>>>the process to be > created. This restriction, however, >>>>>>is >>>>>> >>>>> > >>>>>relaxed for >>>>> >>>>> >>>>>>BPEL abstract processes > describing the publicly >>>>>>visible >>>>>> >>>> >>>>behavior of > >>>> >>>> >>>>>>services executable processes implement since they > do >>>>>>not >>>>>> >>>>> >>>>>reveal the >>>>> >>>>> > >>>>>>internal implementation. For example, how the process >>>>>>is > >>>>>> >>>>> >>>>>started could >>>>> >>>>> >>>>>>be an > implementation detail and does not have to be >>>>>> >>>> > >>>>included in the >>>> >>>> >>>>>>description of the publicly > visible behavior. Any >>>>>>basic activity, except activities > <reply> and >>>>>><exit>, may appear at the >>>>>> >>>>> > >>>>>beginning of a >>>>> >>>>> >>>>>>BPEL abstract process. Please > note that the <exit> >>>>>>activity >>>>>> >>>>> >>>>>is limited > >>>>> >>>>> >>>>>>to executable processes, and a <reply> activity > must >>>>>>always be preceded by a <receive> activity. > >>>>>>Therefore these two > >>>>>> > >>>>> > >>>>>activities are > >>>>> > >>>>> > >>>>>>explicitly excluded. > >>>>>> > >>>>>><<end>> > >>>>>> > >>>>>>Regards, > >>>>>> > >>>>>>Ivana > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > > > >>>>>----------------------------------------------------------------- > ---->>>>> > >>>>> > >>>>>>To unsubscribe from this mail list, you must leave >>>>>>the > >>>>>> >>>>> >>>>>OASIS TC that >>>>> >>>>> >>>>>>generates this > mail. You may a link to this group >>>>>>and all >>>>>> >>>>> > >>>>>your TCs in >>>>> >>>>> >>>>>>OASIS > >>>>>>at: > >>>>>> > >>>>>> > >>>>> > >>>>>https://www.oasis-> > >>>>> > >>>> > >>>>open.org/apps/org/workgroup/portal/my_workgroups.php > >>>> > >>>> > > > >>>>>----------------------------------------------------------------- > ---->>>>>To unsubscribe from this mail list, you must leave the > > >>>>>OASIS > >>>>>TC that generates this mail. You may a link to this >>>>>group > >>>>>and all your TCs in OASIS > >>>>>at: > > >>>>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr>>> > >> > >>>> > >>>>oups.php > >>>> > >>>> > >>>> > >>> > >>> > > > >>>------------------------------------------------------------------- > -->>>To unsubscribe from this mail list, you must leave the > > >>>OASIS TC that generates this mail. You may a link to >>>this > group and all your TCs in OASIS at: > > > >>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups. > php>>> > >>> > >>> > >>> > >> > >> > --------------------------------------------------------------------->> > To > unsubscribe from this mail list, you must leave > > >> the OASIS TC that generates this mail. You may a > >> link to this group and all your TCs in OASIS at: > >> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > >> > > > > > > > ---------------------------------------------------------------------> > To > unsubscribe from this mail list, you must leave the > > > OASIS TC that generates this mail. You may a link to > this group > and all your TCs in OASIS at: > > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]