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

["Yaron Y. Goland" <ygoland@bea.com>]

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
>