[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 99 - Updated proposal for vote
+1 Yaron Y. Goland wrote: > 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]