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: Re: [wsbpel] Issue - 81 - Proposal for Vote


Here is my high level understanding of BPEL as it exists today. Please 
note that this is a conceptual model and is not intended to direct 
actual implementation.

Step 1 - A new BPEL process is deployed to (what I call) the BPEL 
dispatcher.

Step 2 - The BPEL dispatcher receives a message and determines that the 
message matches a start activity.

Step 3 - The BPEL dispatcher starts a new instance of the process and 
passes that instance the message.

Step 4 - The new process instance begins execution by:
	Step 4a - Executing any intervening scope, flow or sequence activities 
in order to reach the start activity that matched the incoming message 
and having that start activity receive the message.
	Step 4b - Once the start activity has received the message (and thus 
initialized its correlation sets if any) then any other start activities 
are immediately executed with the correlation sets turned into 
initialize="no".

At this point we now have a fully initialized and running process instance.

The proposed language for issue 81 makes exactly one change to the 
previous. Specifically issue 81 would add one sentence to the end of 
step 4b - "In addition any initial activities that are not start 
activities would also begin execution."

I therefore see the change proposed in 81 as both minor and consistent 
with the functionality in BPEL. I believe that we should give the 
benefit of the doubt to flexibility and so support this change.

	Thanks,

			Yaron



Francisco Curbera wrote:
> 
> 
> 
> 
> The proposed text in section 11.4 contains this sentence:
> 
> If an initial activity is not a start activity then the initial activity
> will only become active when it is inside of a process instance.
> 
> This goes back to the exchange I had with Ugo. The sentence is stating
> implicit control dependencies between initial activities that are non start
> activities and start activities. Which effectively means that don't change
> (at execution time) from what we have now, but we allow people to encode a
> "make believe" process in which things seem to happen one way but actually
> don't. I don't see what we gain with this but maybe someone can explain.
> 
> Paco
> 
> 
> 
>                                                                                                                                         
> 
> 
>                       "Yaron Y. 
> Goland"                                                                                                 
> 
> 
>                       <ygoland@bea.com>        To:       wsbpeltc 
> <wsbpel@lists.oasis-open.org>                                        
> 
>                                                
> cc:                                                                                      
> 
> 
>                       09/15/2004 09:01         Subject:  [wsbpel] Issue 
> - 81 - Proposal for Vote                                       
> 
>                       
> PM                                                                                                                
> 
> 
>                       Please respond 
> to                                                                                                 
> 
> 
>                       
> ygoland                                                                                                           
> 
> 
>                                                                                                                                         
> 
> 
> 
> 
> 
> Section 6.4
> 
> Change: To be instantiated, each business process must contain at least
> one such "start activity." This must be an initial activity in the sense
> that there is no basic activity that logically precedes it in the
> behavior of the process.
> 
> To: To be instantiated, each business process must contain at least one
> such "start activity." That is, a receive/pick activity annotated with a
> createInstance="yes" attribute. See section 11.4 for more details on
> start activities.
> 
> Section 11.4
> 
> Change: A receive activity annotated in this way MUST be an initial
> activity in the process, that is, the only other basic activities may
> potentially be performed prior to or simultaneously with such a receive
> activity MUST be similarly annotated receive activities.
> 
> To: A receive/pick activity annotated in this way MUST be a "start
> activity". A "start activity" is an initial activity that has a
> createInstance="yes" attribute defined on it. An initial activity is a
> receive/pick activity where no other activities but scope, flow,
> sequence and empty activities occur before it in the process's execution
> path. While all start activities must be initial activities not all
> initial activities are required to be start activities. If an initial
> activity is not a start activity then the initial activity will only
> become active when it is inside of a process instance.
> 
> Change: It is permissible to have the createInstance attribute set
> to"yes" for a set of concurrent initial activities.
> 
> To: It is permissible to have multiple start activities.
> 
> Change: All such receive activities MUST use the same correlation sets
> (see Correlation).
> 
> To: If a process has multiple start activities then all the start
> activities MUST use the same correlation sets (see Correlation).
> 
> To unsubscribe from this mailing list (and be removed from the roster of
> the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php 
> 
> .
> 
> 
> 


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