[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 anupdated proposalfor 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 profilefor AP1.1.Nevertheless, based on the proposal for issue 82 and thecurrent textof 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 ANEXECUTABLE processin WS-BPEL is to annotate a receive activity with thecreateInstanceattribute set to "yes" (see Pick for a variant). Section on AP1.1 (probably section 15.2 according to theresolutionfor issue 82):------------------------------------------------------------------------ ---------- Include the following text: The receive activity plays a role in the lifecycle of executable processes. It is required that executable processes mustcontain atleast one receive activity (or pick activity) that receivesa messageand is annotated with the createInstance attribute set to "yes" to indicate that the occurrence of that activity causes a newinstance ofthe process to be created. This restriction, however, isrelaxed forBPEL abstract processes describing the publicly visiblebehavior ofservices executable processes implement since they do notreveal theinternal implementation. For example, how the process isstarted couldbe an implementation detail and does not have to beincluded in thedescription of the publicly visible behavior. Any basic activity, except activities <reply> and <exit>, may appear at thebeginning of aBPEL abstract process. Please note that the <exit> activityis limitedto executable processes, and a <reply> activity must always be preceded by a <receive> activity. Therefore these twoactivities areexplicitly excluded. <<end>> Regards, Ivana---------------------------------------------------------------------To unsubscribe from this mail list, you must leave theOASIS TC thatgenerates this mail. You may a link to this group and allyour TCs inOASIS 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]