[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 99 - Updated proposal for vote
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]