[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Attempt to Understand BPEL Multi-Start Behavior
Danny van der Rijn wrote: >i'm certainly not advocating any restrictions on freedom UNLESS the BPEL >author desires it. even then, i'm not sure that classifying > >Giving people more then enough rope to hang themselves > >counts as freedom > > mm1: Between the multiple discussions, Danny, Yaron and Satish, a use case seems in order to put this into perspective. :-) >danny > >----- Original Message ----- >From: "Satish Thatte" <satisht@microsoft.com> >To: "Danny van der Rijn" <dannyv@tibco.com>; <wsbpel@lists.oasis-open.org> >Sent: Friday, October 24, 2003 6:35 PM >Subject: RE: [wsbpel] Attempt to Understand BPEL Multi-Start Behavior > > >My case is that predictability without the freedom to support interesting >scenarios is not a desirable tradeoff in this case .. > >-----Original Message----- >From: Danny van der Rijn [mailto:dannyv@tibco.com] >Sent: Friday, October 24, 2003 4:16 PM >To: wsbpel@lists.oasis-open.org >Subject: Re: [wsbpel] Attempt to Understand BPEL Multi-Start Behavior > >Satish wrote: >"What I am trying to convince you (and the TC) of is that there are a host >of deployment and usage scenarios that require different rules of engagement >across instances. We cannot legislate those in any effective way without >causing more harm than good." > >well, you haven't convinced me yet. > >there is a real issue with bindings that are not able to be multiplexed. >and with connection-based bindings. (these might not be 2 separate >categories). saying "that not all bindings are connection oriented, >therefore its a deployment problem" does a disservice to the users of the >simple case. > >for instance, if 2 instances are waiting for the same message, and it comes >in over TCP, operating systems will allow the socket to be handed to both >instance simultaneously. however, neither will be able to read the thing >correctly, nor write an error to it. i know that this is an obvious >problem. are we going to leave all of the implementers to solve it in N >ways? or do we want to supply something to conform to? i strongly prefer >the latter. > >danny > >----- Original Message ----- >From: "Satish Thatte" <satisht@microsoft.com> >To: "Danny van der Rijn" <dannyv@tibco.com>; <wsbpel@lists.oasis-open.org> >Sent: Friday, October 24, 2003 3:56 PM >Subject: RE: [wsbpel] Attempt to Understand BPEL Multi-Start Behavior > > >Danny, > >There are several problems with your questions > >A. You are assuming that the messaging endpoints are owned by some BPEL >engine. This will in general not be the case. Thus "engine receives a >message that doesn't create an instance" might be a meaningless description >in many deployments where some common queue or topic or other endpoint is >being watched by many consumers. > >B. Asserting "exclusive ownership" of incoming messages raises a host of >security authorization issues that we definitely should stay out of. And is >almost impossible to enforce in multi-hop delivery architectures such as the >SOAP message path architecture with intermediaries. > >C. In the case of any message exchange pattern where an incoming message >results in some response message(s), multiple destination services are going >to cause a fault somewhere but how and where is very platform dependent. On >the other hand the request may be watched by some sort of auditing or fraud >detection daemon which may even spawn off a special process instance that >keeps the correlation and watches further exchanges on that correlation >without getting involved. How do you allow for that with rules of the kind >you seem to want? > >What I am trying to convince you (and the TC) of is that there are a host of >deployment and usage scenarios that require different rules of engagement >across instances. We cannot legislate those in any effective way without >causing more harm than good. > >Satish > >-----Original Message----- >From: Danny van der Rijn [mailto:dannyv@tibco.com] >Sent: Friday, October 24, 2003 11:47 AM >To: wsbpel@lists.oasis-open.org >Subject: Re: [wsbpel] Attempt to Understand BPEL Multi-Start Behavior > >i'm thinking along the lines of: > >- once a BPEL engine receives a message that doesn't create an instance, how >long should it wait for a some process to get to a <receive> before deciding >to drop the incoming message. easily specifiable on the receive, but we >seem to not want to do that, for some reason. > >- can a <receive> specify that it should be the ONLY recipient of a message, >in cases where it could make sense to deliver to more than one process? > >- if there are 2 or more processes waiting on the same message, and it's an >HTTP request/reply message, what happens? > >i might be able to come up with others, but at least you get the gist of my >thinking. > >danny > >----- Original Message ----- >From: "Yaron Goland" <ygoland@bea.com> >To: "'Danny van der Rijn'" <dannyv@tibco.com>; <wsbpel@lists.oasis-open.org> >Sent: Thursday, October 23, 2003 5:47 PM >Subject: RE: [wsbpel] Attempt to Understand BPEL Multi-Start Behavior > > > > >>I tried to think through what requirements you could write regarding the >>BPEL engine's message routing behavior that would allow for some >> >> >meaningful > > >>level of portability without unnecessarily limiting the BPEL engine >>implementation's behavior. I am sorry to say I could only come up with >> >> >two: > > >>A BPEL process instance MUST only be created if it is delivered a message >>that matches the local address, transport, partner endpoint reference, >>portType and operation of one of the BPEL process definition's >>createInstance activities. >> >>A BPEL process instance MUST only receive messages that match the address, >>transport, partner endpoint reference, portType, operation and correlation >>set requested by a receive or pick that is active in the process instance. >> >>Note that the endpoint reference MAY be a 'match any' wildcard. >> >>Are there more? >> >>Yaron >> >> >> >>>-----Original Message----- >>>From: Danny van der Rijn [mailto:dannyv@tibco.com] >>>Sent: Wednesday, October 22, 2003 9:54 AM >>>To: wsbpel@lists.oasis-open.org >>>Subject: Re: [wsbpel] Attempt to Understand BPEL Multi-Start Behavior >>> >>> >>>satish - >>> >>>i'm not advocating legislating cross-instance behavior. i'm >>>trying to point >>>out that the spec doesn't legislate ANY engine behavior >>>(except for the >>>routing behavior that can be inferred from startInstance, >>>correlation sets, >>>and the like). so the behavior that i specified might be the >>>completely >>>valid choice of an implementor. in short, i'm saying that >>>for question #2, >>>all the spec says is that the receive is no longer active. >>>and it stops >>>there. >>> >>>while i may be beating a dead horse, i believe that i still >>>see it moving >>>out of the corner of my eye. >>> >>>danny >>> >>>----- Original Message ----- >>>From: "Satish Thatte" <satisht@microsoft.com> >>>To: "Danny van der Rijn" <dannyv@tibco.com>; >>><wsbpel@lists.oasis-open.org> >>>Sent: Tuesday, October 21, 2003 11:31 PM >>>Subject: RE: [wsbpel] Attempt to Understand BPEL Multi-Start Behavior >>> >>> >>>Danny, >>> >>>While I understand your concern here, trying to legislate >>>cross-instance >>>behavior is a bad idea IMO because there is no end to the >>>cases - and as you >>>know many pub/sub delivery mechanisms take delivery to >>>multiple (in this >>>case service instance) destinations in their stride .. So I >>>prefer to leave >>>cross-instance behavior to the platform to determine. I >>>expect different >>>usage patterns will require different answers to many of >>>those questions. >>> >>>Satish >>> >>>-----Original Message----- >>>From: Danny van der Rijn [mailto:dannyv@tibco.com] >>>Sent: Tuesday, October 21, 2003 4:06 PM >>>To: wsbpel@lists.oasis-open.org >>>Subject: Re: [wsbpel] Attempt to Understand BPEL Multi-Start Behavior >>> >>>for the 2nd question, another possibility is that while the >>>receive is no >>>longer active (how could it be?) the engine could enforce that the >>>correlation set can only exist in one instance, thereby not >>>delivering the >>>message to instance P1, but also not creating another >>>instance. at such >>>time as P1 completes, it might instantiate another instance >>>and deliver it >>>to that. >>> >>>not specifying any engine behavior leads us into messes like this.. >>> >>>----- Original Message ----- >>>From: "Yaron Goland" <ygoland@bea.com> >>>To: "'Satish Thatte'" <satisht@microsoft.com> >>>Cc: "'Ugo Corda'" <UCorda@SeeBeyond.com>; "'Eckenfels. Bernd'" >>><B.Eckenfels@seeburger.de>; <wsbpel@lists.oasis-open.org> >>>Sent: Tuesday, October 21, 2003 3:33 PM >>>Subject: [wsbpel] Attempt to Understand BPEL Multi-Start Behavior >>> >>> >>> >>> >>>>Satish, >>>> I wanted to get your opinion on the following three questions: >>>> >>>>Question 1 - Is my description of multi-start activity >>>> >>>> >>>behavior in BPEL as >>> >>> >>>>given below accurate? >>>>Question 2 - Are start activities on process instances >>>> >>>> >>>perpetually active? >>> >>> >>>>Question 3 - Are multi-start activities allowed to wait on the same >>>>portType, operation and correlation set? >>>> >>>>Question 1 - Is my description of multi-start activity >>>> >>>> >>>behavior in BPEL as >>> >>> >>>>given below accurate? >>>> >>>><process> >>>> ... >>>> <flow> >>>> <receive partnerLink="P1" portType="A" createInstance="yes" >>>>operation="foo" variable="A"> >>>> <correlations><correlation set="c" >>>> >>>> >>>initiate="yes"/></correlations> >>> >>> >>>> </receive> >>>> <receive partnerLink="P2" portType="A" createInstance="yes" >>>>operation="bar" variable="B"> >>>> <correlations><correlation set="c" >>>> >>>> >>>initiate="yes"/></correlations> >>> >>> >>>> </receive> >>>> </flow> >>>></process> >>>> >>>>Time 0 - Message Mfoo arrives on operation foo. A new BPEL process >>>> >>>> >>>instance >>> >>> >>>>P1 is created. P1 initializes correlation set c using Mfoo. >>>> >>>>Time 1 - Message Mbar arrives on operation bar. >>>> >>>>A very careful reading of section of section 6.4 will pick out the >>>> >>>> >>>sentence >>> >>> >>>>"...When a message is received by such an activity, an >>>> >>>> >>>instance of the >>> >>> >>>>business process is created if it does not already >>>> >>>> >>>exist..." The apparent >>> >>> >>>>implication of this sentence is that rather than creating a >>>> >>>> >>>new process >>> >>> >>>>instance Mbar, because it matches correlation set c, will >>>> >>>> >>>actually be >>>routed >>> >>> >>>>to instance P1. >>>> >>>>Although a naive reading of the BPEL specification would >>>> >>>> >>>lead the reader >>>to >>> >>> >>>>believe that a bpws:correlationViolation fault should be >>>> >>>> >>>thrown since the >>> >>> >>>>second receive to which Mbar will be delivered explicitly tries to >>>> >>>> >>>initiate >>> >>> >>>>correlation set c which was already initiated at Time 0 in >>>> >>>> >>>this case no >>> >>> >>>>fault is thrown because any multi-start activities executed >>>> >>>> >>>after the >>>first >>> >>> >>>>multi-start activity in a process instance will behave as >>>> >>>> >>>if the initiate >>> >>> >>>>attribute was set to No. >>>> >>>>Therefore the result is that at Time 1 Mbar will be delivered to the >>>> >>>> >>>second >>> >>> >>>>receive of process instance P1. >>>> >>>>Question 2 - Are start activities on process instances >>>> >>>> >>>perpetually active? >>> >>> >>>><process> >>>> ... >>>> <flow> >>>> <receive partnerLink="P1" portType="A" createInstance="yes" >>>>operation="foo" variable="A"> >>>> <correlations><correlation set="c" >>>> >>>> >>>initiate="yes"/></correlations> >>> >>> >>>> </receive> >>>> <wait../> <!-- Will wait for 10 hours--> >>>> </flow> >>>></process> >>>> >>>>Imagine the following timeline: >>>> >>>>T0 - Message Mfoo arrives for operation foo causing the new process >>>> >>>> >>>instance >>> >>> >>>>P1 to be created, the message is passed to the receive and >>>> >>>> >>>correlation set >>>c >>> >>> >>>>is initiated. >>>>T1 - The receive activity completes >>>>T2 - Message Mfoo2 arrives for operation foo and matches >>>> >>>> >>>the correlation >>>set >>> >>> >>>>c. Process instance P1 is still active because the wait >>>> >>>> >>>activity hasn't >>> >>> >>>>expired yet. >>>> >>>>What happens to message Mfoo2? >>>> >>>>I can think of at least two likely outcomes: >>>> #1 - A start activity can only be called once so >>>> >>>> >>>effectively P1 >>>has >>> >>> >>>>no receive outstanding waiting for a message on operation foo with >>>>correlation set c. Therefore a new process instance will be >>>> >>>> >>>created to >>> >>> >>>>handle Mfoo2. >>>> #2 - A start activity is perpetually active >>>> >>>> >>>therefore Mfoo2 will >>>be >>> >>> >>>>sent to P1 and the receive will be executed for a second time. >>>> >>>>Question 3 - Are multi-start activities allowed to wait on the same >>>>portType, operation and correlation set? >>>> >>>>The following is a copy of my first example with the change that the >>>>partnerLinks on the two start activities are identical. Section 11.4 >>>>explicitly forbids the following but some of your comments >>>> >>>> >>>made me think >>> >>> >>>>that you thought this is legal if the activities involved >>>> >>>> >>>are all start >>> >>> >>>>activities. I wanted to get clarification - do you believe >>>> >>>> >>>this example is >>> >>> >>>>legal BPEL? >>>> >>>><process> >>>> ... >>>> <flow> >>>> <receive partnerLink="P" portType="A" createInstance="yes" >>>>operation="foo" variable="A"> >>>> <correlations><correlation set="c" >>>> >>>> >>>initiate="yes"/></correlations> >>> >>> >>>> </receive> >>>> <receive partnerLink="P" portType="A" createInstance="yes" >>>>operation="bar" variable="B"> >>>> <correlations><correlation set="c" >>>> >>>> >>>initiate="yes"/></correlations> >>> >>> >>>> </receive> >>>> </flow> >>>></process> >>>> >>>> Thanks, >>>> Yaron >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Satish Thatte [ mailto:satisht@microsoft.com >>>>> >>>>> >>>><mailto:satisht@microsoft.com> ] >>>> >>>> >>>>>Sent: Monday, October 20, 2003 7:22 PM >>>>>To: ygoland@bea.com >>>>>Cc: Ugo Corda; Eckenfels. Bernd; wsbpel@lists.oasis-open.org >>>>>Subject: RE: [wsbpel] Issue - 37 - Initiating Correlation Set >>>>>More Than >>>>>Once >>>>> >>>>> >>>>>The assumptions here in the context of the original >>>>>discussion were that both receives use the same correlation >>>>>set and hence this is a special case of the "multiple start >>>>>activities" example. In which case the single instance will >>>>>receive both identically correlated messages. All this is >>>>>saying is that there is no requirement in the multiple start >>>>>activities case to have two distinct portType/partnerLink >>>>>attributes for the multiple receives. So in the case of a >>>>>trade settlement example the buy-side and sell-side entities >>>>>may use two different operations on the same portType. >>>>> >>>>>Does that help? >>>>> >>>>>Satish >>>>> >>>>>-----Original Message----- >>>>>From: Yaron Goland [ mailto:ygoland@bea.com >>>>> >>>>> >>><mailto:ygoland@bea.com> ] >>> >>> >>>>>Sent: Monday, October 20, 2003 5:10 PM >>>>>To: Satish Thatte >>>>>Cc: 'Ugo Corda'; 'Eckenfels. Bernd'; wsbpel@lists.oasis-open.org >>>>>Subject: RE: [wsbpel] Issue - 37 - Initiating Correlation Set >>>>>More Than Once >>>>> >>>>>So if we have: >>>>><process> >>>>> <flow> >>>>> <receive portType="A" createInstance="yes" >>>>>operation="foo" variable="A"/> >>>>> <receive portType="A" createInstance="yes" >>>>>operation="bar" variable="B"/> >>>>> </flow> >>>>></process> >>>>> >>>>>then isn't it impossible to ever have a situation in which a >>>>>single process instance receives messages on both receives? >>>>> >>>>>For example, if a message comes in for operation foo then a >>>>>new instance will be created to handle it. If a message comes >>>>>in for operation bar then a new and separate instance will be >>>>>created. So we now have two separate instances. >>>>> >>>>>What's confusing me is your comment in the original example >>>>>that: "You get one instance with the two messages in two >>>>> >>>>> >>>variables." >>> >>> >>>>>I'm having trouble seeing how we can have a single instance >>>>>that received both messages. >>>>> >>>>> Thanks for taking the time to help clarify this for me, >>>>> >>>>> Yaron >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Satish Thatte [ mailto:satisht@microsoft.com >>>>>> >>>>>> >>>><mailto:satisht@microsoft.com> ] >>>> >>>> >>>>>>Sent: Monday, October 20, 2003 4:43 PM >>>>>>To: ygoland@bea.com >>>>>>Cc: Ugo Corda; Eckenfels. Bernd; wsbpel@lists.oasis-open.org >>>>>>Subject: RE: [wsbpel] Issue - 37 - Initiating Correlation Set >>>>>>More Than >>>>>>Once >>>>>> >>>>>> >>>>>>I fortunately didn't specify operations or message types, >>>>>>just used the same port ;-) But you are right that this >>>>>>would not work if the operations were the same. >>>>>> >>>>>>Satish >>>>>> >>>>>>-----Original Message----- >>>>>>From: Yaron Goland [ mailto:ygoland@bea.com >>>>>> >>>>>> >>><mailto:ygoland@bea.com> ] >>> >>> >>>>>>Sent: Monday, October 20, 2003 4:24 PM >>>>>>To: Satish Thatte >>>>>>Cc: 'Ugo Corda'; 'Eckenfels. Bernd'; wsbpel@lists.oasis-open.org >>>>>>Subject: RE: [wsbpel] Issue - 37 - Initiating Correlation Set >>>>>>More Than Once >>>>>> >>>>>>I'm confused about this example: >>>>>> >>>>>> >>>>>>><process> >>>>>>> <flow> >>>>>>> <receive portTypeA initial="yes" variable=A/> >>>>>>> <receive portTypeA initial="yes" variable=B/> >>>>>>> </flow> >>>>>>> ... >>>>>>></process> >>>>>>> >>>>>>> >>>>>>Section 11.4 states "A business process instance MUST NOT >>>>>>simultaneously enable two or more receive activities for the >>>>>>same partnerLink, portType, operation and correlation >>>>>>set(s)." I am not aware of any exception made for initial >>>>>>activities. Therefore wouldn't the previous example be >>>>>>illegal assuming that the operation (which isn't specified) >>>>>>is the same for both receives? I'm having trouble >>>>>>understanding how a single message could, as you state >>>>>>"...get one instance with the two messages in two variables." >>>>>> >>>>>>I appreciate any help you can give in clarifying the issue, >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yaron >>>>>> >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Satish Thatte [ mailto:satisht@microsoft.com >>>>>>> >>>>>>> >>>><mailto:satisht@microsoft.com> ] >>>> >>>> >>>>>>>Sent: Thursday, October 16, 2003 9:02 PM >>>>>>>To: Ugo Corda; Eckenfels. Bernd; wsbpel@lists.oasis-open.org >>>>>>>Subject: RE: [wsbpel] Issue - 37 - Initiating Correlation Set >>>>>>>More Than >>>>>>>Once >>>>>>> >>>>>>> >>>>>>>The specification does not prevent something like >>>>>>><process> >>>>>>> <flow> >>>>>>> <receive portTypeA initial="yes" variable=A/> >>>>>>> <receive portTypeA initial="yes" variable=B/> >>>>>>> </flow> >>>>>>> ... >>>>>>></process> >>>>>>> >>>>>>>You get one instance with the two messages in two variables. >>>>>>>It also does not currently prevent >>>>>>> >>>>>>><process> >>>>>>> <flow> >>>>>>> <receive portTypeA initial="yes" variable=A/> >>>>>>> <receive portTypeA initial="yes" variable=A/> >>>>>>> </flow> >>>>>>> ... >>>>>>></process> >>>>>>> >>>>>>>Although one of the two messages will be lost to the process >>>>>>>instance which receives them. I think it is unnecessary to >>>>>>>eliminate this by restriction. There are many useless things >>>>>>>people can do with a notation as powerful as BPEL and it is >>>>>>>not possible to eliminate all of them by making more rules. >>>>>>> >>>>>>>Satish >>>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Ugo Corda [ mailto:UCorda@SeeBeyond.com >>>>>>> >>>>>>> >>>><mailto:UCorda@SeeBeyond.com> ] >>>> >>>> >>>>>>>Sent: Thursday, October 16, 2003 7:05 PM >>>>>>>To: Eckenfels. Bernd; wsbpel@lists.oasis-open.org >>>>>>>Subject: RE: [wsbpel] Issue - 37 - Initiating Correlation Set >>>>>>>More Than Once >>>>>>> >>>>>>>Yes, what is an implementation supposed to do in the last two >>>>>>>cases below? It does not seem to make sense to create a >>>>>>>second instance with the same correlation value, so it's not >>>>>>>possible to throw a fault on a second instance. Should a >>>>>>>fault be thrown on the first instance? >>>>>>> >>>>>>>Ugo >>>>>>> >>>>>>> >>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: Eckenfels. Bernd [ mailto:B.Eckenfels@seeburger.de >>>>>>>> >>>>>>>> >>>><mailto:B.Eckenfels@seeburger.de> ] >>>> >>>> >>>>>>>>Sent: Thursday, October 16, 2003 4:30 AM >>>>>>>>To: wsbpel@lists.oasis-open.org >>>>>>>>Subject: RE: [wsbpel] Issue - 37 - Initiating >>>>>>>> >>>>>>>> >>>Correlation Set >>> >>> >>>>>>>>More Than >>>>>>>>Once >>>>>>>> >>>>>>>> >>>>>>>>if you receive 2 messages with the same correlation key to >>>>>>>>the same port, the first one will create a new instance, the >>>>>>>>second one is the problem. On the other hand, it will be >>>>>>>>allowed to receive a message on a different port, with the >>>>>>>>same correlationb key. >>>>>>>> >>>>>>>>I am refering to the auction example: >>>>>>>> >>>>>>>> >>><process><flow><receive >>> >>> >>>>>>>>portA initial="yes"/><receive portB initial="yes" /></flow> >>>>>>>> >>>>>>>>in this example >>>>>>>> >>>>>>>>message cor=a port=a >>>>>>>>message cor=a port=b >>>>>>>> >>>>>>>>is allowed, also: >>>>>>>> >>>>>>>>message cor=a port=a >>>>>>>>message cor=a port=b >>>>>>>> >>>>>>>>but not: >>>>>>>> >>>>>>>>message cor=a port=a >>>>>>>>message cor=a port=a >>>>>>>> >>>>>>>>or >>>>>>>> >>>>>>>>message cor=a port=b >>>>>>>>message cor=a port=b >>>>>>>> >>>>>>>>right? >>>>>>>> >>>>>>>>Mit freundlichen Grüßen >>>>>>>>Bernd Eckenfels >>>>>>>>Chief Architect >>>>>>>>-- >>>>>>>>SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany >>>>>>>>Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256 >>>>>>>>mailto:b.eckenfels@seeburger.de >>>>>>>> >>>>>>>> >>>mailto:b.eckenfels@seeburger.de> - >>> >>> >>>>http://www.seeburger.de <http://www.seeburger.de> >>>> >>>> >>>>>>>>-----Original Message----- >>>>>>>>From: Satish Thatte [ mailto:satisht@microsoft.com >>>>>>>> >>>>>>>> >>>><mailto:satisht@microsoft.com> ] >>>> >>>> >>>>>>>>Sent: Tuesday, October 14, 2003 11:54 PM >>>>>>>>To: Eckenfels. Bernd; wsbpel@lists.oasis-open.org >>>>>>>>Subject: RE: [wsbpel] Issue - 37 - Initiating >>>>>>>> >>>>>>>> >>>Correlation Set >>> >>> >>>>>>>>More Than >>>>>>>>Once >>>>>>>> >>>>>>>> >>>>>>>>A createInstance receive activity cannot be in a loop since >>>>>>>>second iteration on it would not be an initial >>>>>>>> >>>>>>>> >>>activity. How >>> >>> >>>>>>>>would it receive a second message? >>>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: Eckenfels. Bernd [ mailto:B.Eckenfels@seeburger.de >>>>>>>> >>>>>>>> >>>><mailto:B.Eckenfels@seeburger.de> ] >>>> >>>> >>>>>>>>Sent: Tuesday, October 14, 2003 8:48 AM >>>>>>>>To: wsbpel@lists.oasis-open.org >>>>>>>>Subject: RE: [wsbpel] Issue - 37 - Initiating >>>>>>>> >>>>>>>> >>>Correlation Set >>> >>> >>>>>>>>More Than Once >>>>>>>> >>>>>>>>Hello, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>B) References to already initialized correlation set are >>>>>>>>> >>>>>>>>> >>>>>>>>treated as if initiate="no" >>>>>>>> >>>>>>>> >>>>>>>>> regardless of the specified value. >>>>>>>>> -- Only for start activities. >>>>>>>>> >>>>>>>>> >>>>>>>>If we have 2 start activities with "initiate=Yes" and on the >>>>>>>>same correlation set, then the first activity will add a new >>>>>>>>correlation entry, and the second one is allowed to receive >>>>>>>>in the same correlation. But neigter the initial receive nor >>>>>>>>the second receive is allowed to receive another message for >>>>>>>>that correlation set? No? >>>>>>>> >>>>>>>>Mit freundlichen Grüßen >>>>>>>>Bernd Eckenfels >>>>>>>>Chief Architect >>>>>>>>-- >>>>>>>>SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany >>>>>>>>Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256 >>>>>>>>mailto:b.eckenfels@seeburger.de >>>>>>>> >>>>>>>> >>>mailto:b.eckenfels@seeburger.de> - >>> >>> >>>>http://www.seeburger.de <http://www.seeburger.de> >>>> >>>> >>>>>>>>-----Original Message----- >>>>>>>>From: Yuzo Fujishima [ mailto:fujishima@bc.jp.nec.com >>>>>>>> >>>>>>>> >>>><mailto:fujishima@bc.jp.nec.com> ] >>>> >>>> >>>>>>>>Sent: Tuesday, October 14, 2003 8:22 AM >>>>>>>>To: Satish Thatte; wsbpel@lists.oasis-open.org >>>>>>>>Subject: Re: [wsbpel] Issue - 37 - Initiating >>>>>>>> >>>>>>>> >>>Correlation Set >>> >>> >>>>>>>>More Than >>>>>>>>Once >>>>>>>> >>>>>>>> >>>>>>>>Satish, >>>>>>>> >>>>>>>>Thank you for the comment. >>>>>>>> >>>>>>>>As far as I understand, your opinion is very close >>>>>>>> >>>>>>>> >>>to, if not >>> >>> >>>>>>>>the same as, my proposal >>>>>>>>(please note the last line): >>>>>>>> >>>>>>>>B) References to already initialized correlation set are >>>>>>>>treated as if initiate="no" >>>>>>>> regardless of the specified value. >>>>>>>> -- Only for start activities. >>>>>>>> >>>>>>>>Below is my another try to capture the idea: >>>>>>>> >>>>>>>>B') It is allowed to define a process definition such that >>>>>>>>multiple start activities >>>>>>>>initiate the same correlation set(s). In such case, only the >>>>>>>>start activity that actually >>>>>>>>created the process instance initiates the correlation >>>>>>>>set(s). For the remaining >>>>>>>>start activities, the correaltion set(s) is (are) treated as >>>>>>>>if initiate="no". >>>>>>>>For all other cases, a bpws:correlationViolation fault is >>>>>>>>thrown if an activity tries >>>>>>>>to initiate an already-initiated correlation set. >>>>>>>> >>>>>>>>What do you think? >>>>>>>>(I welcome rephrasing.) >>>>>>>> >>>>>>>>Yuzo Fujishima >>>>>>>>NEC Corporation >>>>>>>> >>>>>>>> >>>>>>>>----- Original Message ----- >>>>>>>>From: "Satish Thatte" <satisht@microsoft.com> >>>>>>>>To: "Yuzo Fujishima" <fujishima@bc.jp.nec.com>; >>>>>>>><wsbpel@lists.oasis-open.org> >>>>>>>>Sent: Monday, October 13, 2003 1:06 PM >>>>>>>>Subject: RE: [wsbpel] Issue - 37 - Initiating >>>>>>>> >>>>>>>> >>>Correlation Set >>> >>> >>>>>>>>More Than Once >>>>>>>> >>>>>>>> >>>>>>>>Yuzo, >>>>>>>> >>>>>>>>After thinking about this again, my opinion is that >>>>>>>> >>>>>>>> >>>we should >>> >>> >>>>>>>>stick with the intent of the original authors. I >>>>>>>> >>>>>>>> >>>recognize the >>> >>> >>>>>>>>similarity with the multiple start activities but there is >>>>>>>>also a crucial difference. In the case of multiple start >>>>>>>>activities, the >>>>>>>>multiple initiations of the correlation are >>>>>>>> >>>>>>>> >>>unavoidable since >>> >>> >>>>>>>>there is no other way to achieve the rendezvous of >>>>>>>> >>>>>>>> >>>the multiple >>> >>> >>>>>>>>non-deterministically ordered activation messages. In the >>>>>>>>cases where instance creation is not involved, there must >>>>>>>> >>>>>>>> >>>>>>>already be a >>>>>>> >>>>>>> >>>>>>>>known correlation for the message to be delivered to the >>>>>>>>instance and hence it is not a case of >>>>>>>>rendezvous-by-correlation. I cannot >>>>>>>>think of real examples where multiple initiations of a >>>>>>>>correlation set would be meaningful other than in the >>>>>>>> >>>>>>>> >>>>>>multiple start >>>>>> >>>>>> >>>>>>>>activities case. I therefore have to agree with Yaron that >>>>>>>>this is most likely to arise as a process design error. >>>>>>>> >>>>>>>>Satish >>>>>>>> >>>>>>>>________________________________ >>>>>>>> >>>>>>>>From: Yuzo Fujishima [ mailto:fujishima@bc.jp.nec.com >>>>>>>> >>>>>>>> >>>><mailto:fujishima@bc.jp.nec.com> ] >>>> >>>> >>>>>>>>Sent: Sat 9/27/2003 2:02 AM >>>>>>>>To: wsbpel@lists.oasis-open.org >>>>>>>>Subject: Re: [wsbpel] Issue - 37 - Initiating >>>>>>>> >>>>>>>> >>>Correlation Set >>> >>> >>>>>>>>More Than Once >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>Hi, >>>>>>>> >>>>>>>>Here is my summary of our discussion on Issue 37 at the last >>>>>>>>F2F meeting: >>>>>>>> >>>>>>>>Issue 37: What will happen if a correlation set is initiated >>>>>>>>more than once >>>>>>>> during the lifetime of the >>>>>>>> >>>>>>>> >>>corresponding scope? >>> >>> >>>>>>>>The intent of the original authors was (Satish) >>>>>>>>A) bpws:correlationViolation fault is always thrown >>>>>>>> -- for executable processes and the situation >>>>>>>> >>>>>>>> >>>is marked >>> >>> >>>>>>>>as "undefined" >>>>>>>> for abstract processes. >>>>>>>> >>>>>>>>My comment was: >>>>>>>> A is somewhat incompatible with the interpreation of the >>>>>>>>Mulitple Start Activities >>>>>>>> example described in the specification document. >>>>>>>> >>>>>>>>My proposal was: >>>>>>>>B) References to already initialized correlation set are >>>>>>>>treated as if initiate="no" >>>>>>>> regardless of the specified value. >>>>>>>> -- Only for start activities. (This line was >>>>>>>> >>>>>>>> >>>added today.) >>> >>> >>>>>>>>Danny's proposal/comment: (Please correct if wrong) >>>>>>>>C) We may introduce an attribute value >>>>>>>> >>>>>>>> >>>initiate="yesIfNotYet" >>> >>> >>>>>>>>or the like. >>>>>>>> >>>>>>>>Somebody's proposal/comment (Sorry I forgot who)(Please >>>>>>>>correct if wrong) >>>>>>>>D) Remove initiate attribute completely. >>>>>>>> >>>>>>>> >>>Correlation sets are >>> >>> >>>>>>>>initialized >>>>>>>> at the first use. >>>>>>>> >>>>>>>>Yaron's comment: (Please correct if wrong) >>>>>>>> Tolerating multiple initialization may raise the >>>>>>>>possibility of the user's >>>>>>>> making inadvertent mistakes. >>>>>>>> >>>>>>>>Yuzo Fujishima >>>>>>>>NEC Corporation >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>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/le >>> >>> >>>><http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le> >>>> >>>> >>>>>>>ave_workgroup.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/le >>>>>>> >>>>>>> >>>><http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le> >>>> >>>> >>>>>>ave_workgroup.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/le >>>>> >>>>> >>>><http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le> >>>> >>>> >>>>>ave_workgroup.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/le >>>>> >>>>> >>>><http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le> >>>> >>>> >>>>>ave_workgroup.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/le >>>>> >>>>> >>>><http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le> >>>> >>>> >>>>>ave_workgroup.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/le >>>>> >>>>> >>>><http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le> >>>> >>>> >>>>>ave_workgroup.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/le >>>>> >>>>> >>>><http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le> >>>> >>>> >>>>>ave_workgroup.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/le >>>ave_workgroup.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/le >>>ave_workgroup.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/le >>>ave_workgroup.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/le >>>ave_workgroup.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_workgroup.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_workgroup.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_workgroup.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_workgroup.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_workgroup.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_workgroup.php. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]