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


Actually the flow example is less 'safe' than issue 81 because issue 81 
has an ordering guarantee that the flow example does not. It seems 
ironic that the example we all agree on is the flow example.

As for a compelling use case, we shouldn't ban functionality unless 
there is harm and if there is harm in 81 then there is harm in BPEL 
messaging.

That all having been said, there are some interesting use cases and I 
suspect that by allowing this feature people will come up with many more 
we have never thought of. That's why the general rule of 'don't ban it 
unless it's proven harmful' is a good one to follow.

A general design pattern that will make good use of 81 is any time one 
has actions that need to occur regardless of which start activity begins 
the process.

For example, a truck manufacturing plant which builds made-to-order 
trucks uses a BPEL process to coordinate multiple parts suppliers who 
are delivering different parts needed for a particular truck order. 
Because it's unknown which supplier will contact the plant first and 
because each supplier has its own unique interaction with the plant the 
BPEL process supports N start activities, one for each of the N 
suppliers. Regardless of which supplier kicks off the BPEL process 
instance, the process will immediately want to send a message to the 
plant floor letting them know that at least one of the part deliveries 
for a particular truck is on its way and so the plant floor should start 
to tool up. Using issue 81 the process would be written with a parent 
activity that was a flow with N+1 children. N children will be start 
activities for each of the N part suppliers and the additional activity 
will be an initial activity that sends the notice to the floor.

Without 81 the programmer will have to put in the status update after 
each and every one of the N start activities, that is, they will have to 
repeat the code N times and then use a serializable scope before all N 
copies of the status update code that checks a global variable to see if 
the status update has already been sent.

I believe that issue 81 allows a much simpler and more maintainable 
design that is consistent with current BPEL design.

I hope this letter helps to better explain my interest in this topic,

	Thanks,

		Yaron

Francisco Curbera wrote:
> 
> 
> 
> 
> You are right that looked that way the change is "small". There is a
> significant difference however. Today, I can have concurrent start
> activities and the behavior is essentially what you describe, but the fact
> is that any one of the start activities could potentially be hit first and
> start the process; in that sense the different concurrent executions that
> the process represents are all legal (possible) ones. When non-start
> activities are allowed as initial activities the only legal execution
> sequences are those in which start activities go first. So the process
> definition (as in your flow example) is not a faithful representation of
> the possible execution sequences. I think we agree on this.
> 
> Given that, I think I would need a little more than the benefit of the
> doubt to agree; how about a compelling use case?
> 
> Paco
> 
> 
> 
> 
>                                                                                                                                         
> 
> 
>                       "Yaron Y. 
> Goland"                                                                                                 
> 
> 
>                       <ygoland@bea.com>        To:       Francisco 
> Curbera/Watson/IBM@IBMUS                                            
> 
>                                                cc:       wsbpeltc 
> <wsbpel@lists.oasis-open.org>                                        
> 
>                       09/16/2004 07:02         Subject:  Re: [wsbpel] 
> Issue - 81 - Proposal for Vote                                   
> 
>                       
> PM                                                                                                                
> 
> 
>                       Please respond 
> to                                                                                                 
> 
> 
>                       
> ygoland                                                                                                           
> 
> 
>                                                                                                                                         
> 
> 
> 
> 
> 
> 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]