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 - 66 - Zero or multiple matches of correlation set


If I interprete the spec correctly, WITHIN ONE PROCESS INSTANCE, there can be only ONE outstanding <receive> from the same (PortType/Operation/CorrelationSet).  I don't see the spec say anything about what happens if DIFFERENT PROCESS INSTANCES are making <receive> from the same (PortType/Operation/CorrelationSet).

ProcessA and ProcessB and ProcessC are three DIFFERENT process instances of three DIFFERENT BPEL process definitions.

ProcessC has a different initial receive activity, lets say <receive portType="PT2" operation="oper2" createInstance="yes"/> and then it execute the <receive portType="PT1" operation="oper" createInstance="no"/>  You can also put in a correlationSet as well.

Point #2 is trying to ask two things ....
2a)  Can a <receive> happen after the <invoke> ?  This is more interesting when the <invoke> is "one-way" where the sender doesn't care about any response.
2b)  RM-Semantics ... Is the message considered "delivered successfully" if the BPEL engine gets it and find no matching instances ?

Best regards,
Ricky

At 10:26 AM 9/23/2003 -0700, Yaron Goland wrote:
I'm having trouble understanding point #1.
 
How can processA and processB be 'executing' a createInstance='Yes" receive? If createInstance="Yes" then the receive must be an initial activity and initial activities can only occur at the beginning of a process. Doesn't this mean then, more or less by definition, that no process can be waiting on an initial activity since it is initial activities that create process instances?
 
Isn't processC explicitly banned by BPEL? processC (since it is the same type as A and B) must contain the initial activity on PT1/oper. Therefore if processC ever waits for PT1/oper (without an instantiated correlation set) then it is waiting for the same partnerlink/operation as the initial activity which I believe is illegal.
 
Point #2 seems to be asking 'if someone sends a message and if that message cannot be handled, what error gets returned.' That sounds like a configuration issue to me. Is that in scope for BPEL?
-----Original Message-----
From: ws-bpel issues list editor [mailto:peter.furniss@choreology.com]
Sent: Saturday, September 20, 2003 10:13 AM
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Issue - 66 - Zero or multiple matches of correlation set

This issue has been added to the wsbpel issue list. The issues list is posted as a Technical Committee document to the OASIS WSBPEL TC pages on a regular basis. The current edition, as a TC document, is the most recent document with the title in the "Issues" folder of the WSBPEL TC document list - the next posting will include this issue. The list editor's working copy, which will normally include an issue when it is announced, is available at this constant URL.

Issue - 66 - Zero or multiple matches of correlation set



Status: open
Date added: 19 Sep 2003
Submitter: Ricky Ho
Date submitted: 16 September 2003
Description:

1) When an incoming message matches multiple process instances, which one will get the message ?

e.g. ProcessA is executing
    <receive portType="PT1" operation="oper" ...        createInstance="yes"/>
ProcessB is executing
    <receive portType="PT1" operation="oper" ...        createInstance="yes"/>
An instance of processC is executing
    <receive portType="PT1" operation="oper" ...   createInstance="no"/>
Lets say someone invoke "PT1/oper" and it matches the correlation set of the processC instance. Who gets the message ?

2) When an incoming message matches zero process instances, does the sender get a fault ? or the message will be queued until a matching process instances gets it later

e.g. A sender invoke "PT2/oper2" but no process is listening in that.
Changes: 19 Sep 2003 - new issue
To comment on this issue, please follow-up to this announcement on the wsbpel@lists.oasis-open.org list (replying to this message should automatically send your message to that list), or ensure the subject line as you send it starts "Issue - 66 - [anything]" or is a reply to such a message.

To add a new issue, see the issues procedures document.

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]