[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]