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


BPEL operational semantics only applies to the behavior of a single
process instance.  The mechanics and policies of the messaging layer are
clearly out of scope.

That said, correlation is a declarative way of declaring the
conversation keys used by a single instance, and hence it has
implications for the routing behavior at the web service messaging
layer.  Conversation keys ought to be unique, i.e., if they match that
should be by design.  If uniqueness is violated inadvertently this is a
bug, and I don't think we can arbitrate the behavior in the presence of
application bugs!

As for the "zero" case, this refers to a message that arrives when no
one is interested - web service messaging spam.  Possibly part of a
denial of service attack.  I don't understand why BPEL should deal with
this issue.

Satish

-----Original Message-----
From: Danny van der Rijn [mailto:dannyv@tibco.com] 
Sent: Tuesday, September 23, 2003 11:11 AM
To: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 66 - Zero or multiple matches of
correlation set

put another way, we have a question that has come up several times
before
with no conclusion:

if a request-reply message comes into the execution environment, and is
deliverable to multiple running (and/or startable) instances, how is
this
handled?  they can't all reply.  as BPEL doesn't deal with containers or
message delivery, the spec doesn't really state what should happen here.
but it probably should.

on related note, during a discussion over lunch at the F2F, i mused that
correlation sets are about routing to the process, and aren't about the
process itself.  here we see that semantics of the execution container
are
important enough to put notations about them in the BPEL process.  seems
like layer violation to me.  shouldn't we violate that layer abstraction
in
the above case as well?

what about queing or other ways of dealing with incoming messages that
can't
be delivered immediately?  timeouts for those?

there are a whole bunch of semantics for the execution container that
are
left as an exercise.  why aren't correlations (routing)?

danny

----- Original Message ----- 
From: "Ricky Ho" <riho@cisco.com>
To: <ygoland@bea.com>; <wsbpel@lists.oasis-open.org>
Sent: Tuesday, September 23, 2003 10:58 AM
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
> ><http://www.oasis-open.org/apps/org/workgroup/wsbpel>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
>
><http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php>WSBP
EL
> >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
> ><http://www.choreology.com/external/WS_BPEL_issues_list.html>this
constant
> >URL.
> >
> >Issue - 66 - Zero or multiple matches of correlation set
> >
> >
> >
> >Status: open
> >Date added: 19 Sep 2003
> >Submitter: <mailto:riho@cisco.com>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_workg
roup
.php.
> >
>


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_workgr
oup.php.





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