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)


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.

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
>	
>	
>  
>






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