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:]
>Sent: Tuesday, May 10, 2005 11:11 PM
>To: ; Trickovic, Ivana
>Cc:
>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:]
>> Sent: 10 May 2005 21:09
>> To: Trickovic, Ivana
>> Cc:
>> 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
>
>
