RE: [wsbpel] Issue 99 - Updated proposal for vote

["Trickovic, Ivana" <ivana.trickovic@sap.com>]

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 
>
>