Re: [wsbpel] RE: correlation misconstruction

[Alex Yiu <alex.yiu@oracle.com>]

Hi Bernd and others,

Just to remind people that: a bunch of "undefined" place holder will be 
filled in by the description of a standard fault, after our 3 part spec 
structure is merged into 2 part structure.

See:
http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue158

Regards,
Alex Yiu

Eckenfels. Bernd wrote:

>Hello Genadi,
>
>In BPEL 2.0 it is stated that:
>
>
>10.2. Defining and Using Correlation Sets
>...
>When the initiate attribute is set to "yes", the related activity MUST
>attempt to initiate 
>the correlation set. 
>O If the correlation set is already initiated and the initiate attribute
>is set to "yes", the semantics is undefined. 
>
>
>
>So the spec states clearly, that it is undefined. However one can argue,
>that a System fault would be better here. I dont rember a discussion o
>nwhy we explicitely talk about undefined behaviour. Looks a bit strange
>to me especially since we introduced correlation verification for
>existing (init=no) correlatiob sets.
>
>Gruss
>Bernd
>
>-----Original Message-----
>From: Genadi Genov [mailto:g.genov@bg.seeburger.com] 
>Sent: Thursday, December 01, 2005 6:19 PM
>To: wsbpel@lists.oasis-open.org
>Cc: Eckenfels. Bernd
>Subject: correlation misconstruction
>
>Hi,
>  I seem to have a slight misunderstanding concerning correlation
>initialization and its explanation according to the current BPEL
>specification. To the best of my knowledge every process defined
>correlation is initiated only once during the lifetime of the process
>execution. The same rule applies for correlations that aren't nested in
>a loop. My doubt is whether there is any well defined process behaviour
>when trying to initiate a given correlation set more than once. Consider
>the following code
>fragment:
>
>-----------------------------
><while condition=someCondition>
>	<invoke
>		partnerLink="mappingLink"
>		portType="corr:servicePortType"
>		operation="serviceOperation"
>		inputVariable="vrInitMessage"
>		outputVariable="vrResponseMessage">
>		<correlations>
>			<correlation set="invokeCorrelation"
>pattern="in" initiate="yes"/>
>		</correlations>
>	</invoke>
></while>
>-----------------------------
>
>Assuming the fact the invoke activity is executed more than once what is
>supposed to happen during the second cycle of the loop
>(invokeCorrelation is already initiated but its 'initiate' attribute is
>set to 'yes')? Here is another example:
>
>-----------------------------
><sequence>
>			<receive
>					partnerLink="queue"
>					portType="see:InitPortType"
>					operation="initCorrelation"
>					variable="vrInitMessage"
>					createInstance="yes">
>					<correlations>
>--->initiate it  				<correlation
>set="receiveCorrelation" initiate="yes"/>
>					</correlations>
>			</receive>
>
>			<invoke partnerLink="mappingLink"
>					portType="corr:servicePortType"
>					operation="serviceOperation"
>					inputVariable="vrInitMessage"
>	
>outputVariable="vrResponseMessage">
>					<correlations>
>--->initiate it again			<correlation
>set="receiveCorrelation" pattern="out"
>initiate="yes"/>
>					</correlations>
>			</invoke>
></sequence>
>-----------------------------
>
>Scenario 1. 'initiate' attribute is not taken into account this time
>having in mind our correlation set is already initialized.
>Scenario 2. We are trying to initiate an already initiated correlation
>so some standard fault is being thrown ('bpws:correlationViolation' for
>example).
>
>Maybe I happen to oversee something obvious written in the specification
>even after a thorough search. Any help would be appreciated :)
>
>Best regards,
>Genadi Genov
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>  
>