OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]