[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
Danny, I think we agree on what BPEL does but perhaps not on what it should. When I wrote "BPEL operational semantics only applies to the behavior of a single process instance" I meant to say that if the operational semantics needs to speak of the behavior of an abstract messaging layer to explain correlation, it only needs to speak of it as though the instance in question were the only instance in existence. As for the RosettaNet example, I agree that there are cases where additional policies regarding unexpected messages may apply when the message is properly authenticated and validated. There are also policies that have to do with SLAs and signatures/non-repudiation, etc. I believe these policies should not be expressed within BPEL. As you say they are part of some kind of global model, and BPEL is not providing such a global binding and policy model. Satish -----Original Message----- From: Danny van der Rijn [mailto:dannyv@tibco.com] Sent: Wednesday, September 24, 2003 10:16 AM To: Satish Thatte; wsbpel@lists.oasis-open.org Subject: Re: [wsbpel] Issue - 66 - Zero or multiple matches of correlation set <Satish> 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! </Satish> my point is that correlation has NO operational semantics for a single process instance. it is clearly only intended as a shorthand for an interaction with the messaging layer, registering interest in certain messages, and not in others. don't get me wrong, i think that this is a good thing. <Satish> 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> the problem here is that all web services interactions don't get choreographed perfectly. sometimes there is a misstep. messages get lost, retried, found when they were presumed dead, etc. when you look at a "global model" spec like RosettaNet, there are specific requirements for what happens when an unexpected message is received - what kinds of faults are thrown, when connections get closed without answer, etc. as i stated several months ago, it is not possible to implement RosettaNet using only the current BPEL spec, and i think that this is a problem. i'm very interested in the use cases work being done in this area, because maybe i'm wrong. maybe it's worth me opening a separate issue for this to make sure it gets dealt with. danny ----- Original Message ----- From: "Satish Thatte" <satisht@microsoft.com> To: "Danny van der Rijn" <dannyv@tibco.com>; <wsbpel@lists.oasis-open.org> Sent: Tuesday, September 23, 2003 10:46 PM 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. 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. 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]