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