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] implicite links of the runtime engine (was: Implicit <sequence> macro)


I believe a <sequence> activity can be replaced with a <flow
suppressJoinFailure="false"> activity with a few more caveats, to
produce equivalent control sequencing behavior.  Why do you ask?

Satish

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com] 
Sent: Monday, June 16, 2003 1:48 PM
To: Satish Thatte
Cc: Eckenfels. Bernd; wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] implicite links of the runtime engine (was:
Implicit <sequence> macro)

Satish Thatte wrote:

>Assaf,
>
>Not sure what you are unclear on.  As the comments before the flow
>version of the sequence say: "Finally, assume that the preceding flow
is
>slightly rewritten by linking A, B, and C through links (with
transition
>conditions with constant truth-value of "true") instead of putting them
>into a sequence".  If you look at the second version, those links are
>indeed added.
>
Key word, actually two of them, being "slightly rewritten".

What if a <sequence> was properly rewritten as a <flow>? My question 
again, is there a proper way to rewrite a sequence as a flow so you 
preserve the semantics of the execution but only use the flow activity? 
If so, what are the pros/cons of doing that?

arkin

>
>Let me know if I missed your point.
>
>Satish
>
> 
>
>-----Original Message-----
>From: Assaf Arkin [mailto:arkin@intalio.com] 
>Sent: Friday, June 13, 2003 10:08 AM
>To: Satish Thatte
>Cc: Eckenfels. Bernd; wsbpel@lists.oasis-open.org
>Subject: Re: [wsbpel] implicite links of the runtime engine (was:
>Implicit <sequence> macro)
>
>Satish Thatte wrote:
>
>  
>
>>Sequences and sequentially linked activities in a flow are not
>>    
>>
>identical.  Please look at 12.5.4 for an example.
>  
>
>> 
>>
>>    
>>
>I'm going to need a bit more explanation.
>
>The first example uses a <sequence> and the second one replaces that 
>with a <flow>. In doing so it changes the behavior of the process. I 
>understood that it does so intentionally to explain the usage of
<flow>.
>
>Suppose that it intended to preserve the semantics, and so included a 
>join condition for activity B of the form ''getLinkStatus('X') or 
>getLinkStatus('Y')'. In that case, how would the behavior differ
between
>
>the sequence and the flow?
>
>arkin
>
>  
>
>>	-----Original Message----- 
>>	From: Assaf Arkin [mailto:arkin@intalio.com] 
>>	Sent: Thu 6/12/2003 1:43 PM 
>>	To: Eckenfels. Bernd 
>>	Cc: wsbpel@lists.oasis-open.org 
>>	Subject: Re: [wsbpel] implicite links of the runtime engine
>>    
>>
>(was: Implicit <sequence> macro)
>  
>
>>	
>>	
>>
>>	Eckenfels. Bernd wrote:
>>	
>>	>Hello,
>>	>
>>	>while implementing the BPEL4WS specification, I noted a few
>>    
>>
>simplifications, which can be added to the runtime mode:
>  
>
>>	>
>>	>- implicite flow-start links
>>	>  If the BPEL4WS parser adds links from a flow parent, to all
>>    
>>
>the unlinked activities within, then the process engine does  not have
>to search all activateable activities, but can just follow the links
>  
>
>>	> 
>>	>
>>	I don't see why this would be a simplification. You would have
>>    
>>
>to
>  
>
>>	determine all the unlinked activities and add an XML element to
>>    
>>
>link
>  
>
>>	them to the flow, so essentially you're adding redundant
>>    
>>
>information. If
>  
>
>>	we added that stuff my issue would then be "it's redundant
>>    
>>
>information,
>  
>
>>	can't we just take it away?"
>>	
>>	>- implicite sequence links
>>	>  Instead of a sequence, the engine can simply use a flow,
>>    
>>
>where all sequenced activities are linked together, that way the engine
>has not to implement two different scope styles
>  
>
>>	> 
>>	>
>>	Here I would agree. If the semantics are identical then sequence
>>    
>>
>becomes
>  
>
>>	a shortcut for a flow.
>>	
>>	arkin
>>	
>>	>I notice, that this is not so important for the spec, but
>>    
>>
>especially the second case shows, that there is no need for the
sequence
>activity from a control flow point of few. I guess it would be good to
>add some comments on this in the spec. Or do i have missed a sematical
>difference between a sequence and a flow with linked activities?
>  
>
>>	>
>>	>Greetings
>>	>Bernd
>>	>
>>
>>---------------------------------------------------------------------
>>	>To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>>	>For additional commands, e-mail:
>>    
>>
>wsbpel-help@lists.oasis-open.org
>  
>
>>	> 
>>	>
>>	
>>	
>>	
>>
>>    
>>
>---------------------------------------------------------------------
>  
>
>>	To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>>	For additional commands, e-mail:
>>    
>>
>wsbpel-help@lists.oasis-open.org
>  
>
>>	
>>	
>> 
>>
>>    
>>
>
>
>
>  
>


-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700


This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.





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