Re: [wsbpel] Issue - 66 - Zero or multiple matches of correlationset

[Prasad Yendluri <pyendluri@webmethods.com>]

I agree these are valid issues though I am being thrown off a bit by the use
of the terms "Process Instance".

On Sub-Issue1:

IMO we certainly want to permit the same portType being part of two or more
different process definitions; and more specificaly as part of a receive
activity that is also a start activity.

I see no conflict as long as the process definitions use different
CorrelationSets. However the issue being raised is, when the correlation
sets are also identical. This is a unique case that would only work if the
specific "ports" involved in each process-type are different. Obviously
there is no-conflict with the same process(type) instances sharing the same
port (diferent instances resolved by the correlationSets). However we do
need to warn users of desiging processes that share the same
portType/CorrelationSets if they need to share the same physical port as
well. Could happen accidentally via two independent efforts that use the
same collection Web services. 

Can we really fix this in the spec? 

On sub_issue# 2:

IMO If there is no matching process-instance and it is not creating a new
instance, it should be an error (returned to the sender). Could happen I
guess when the message that should have created the instance was *lost* and
never received (need for reliability .

Regards, Prasad

-------- Original Message --------

Subject:	RE: [wsbpel] Issue - 66 - Zero or multiple matches of correlation set
Date:	Tue, 23 Sep 2003 10:58:51 -0700
From:	Ricky Ho <riho@cisco.com>
To:	<ygoland@bea.com>, <wsbpel@lists.oasis-open.org>
References:	200309201712.SAA25088@wren.choreology.com"><200309201712.SAA25088@wren.choreology.com>

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.