Thanks Alex, that partnerLink on the reply was a typo on my part. I was trying to focus on the flaw Maciej pointed out.
Lance On 10/27/06, Alex Boisvert <[EMAIL PROTECTED]> wrote:
Just to be sure, I think Maciej and I are pointing out different flaws of the examples. I think Maciej is saying that the two consecutive <receive>'s cannot work in practice (I guess that depends on the protocol-level correlation). And what I'm saying is the last <reply> is illegal because it doesn't have a matching <receive> alex Maciej Szefler wrote: > That is what Ali G would call "barely legal BPEL" (non-create receives > should specify a correlation set). It is barely legal because ODE will > assume an implicit "protocol-level" correlation identifier when none is > specified in the process. However, for this to work, the message needs to > actually carry this identifier in the header. In your snippet this is not > possible, since there is no obvious way for the client to know this > identifier until it receives the reply, which in the snippet occurs only > after the receive. > > -mbs > On 10/27/06, Lance Waterman <[EMAIL PROTECTED]> wrote: >> >> I would like to know if the following is valid ... >> >> <bpel:sequence> >> <bpel:receive name="receive1" createInstance="yes" >> operation="operation1" partnerLink="testCorrelationOpaquePL1" >> portType="wns:testCorrelationOpaquePT" variable="input1"/> >> <bpel:receive name="receive2" createInstance="no" >> operation="operation2" >> partnerLink="testCorrelationOpaquePL1" >> portType="wns:testCorrelationOpaquePT" variable="input2"/> >> <bpel:reply name="reply" operation="operation2" >> partnerLink="testCorrelationOpaquePL2" >> portType="wns:testCorrelationOpaquePT" variable="output"/> >> </bpel:sequence> >> >> I am anticipating that the second receive will route based on the >> partnerLink but that does not appear to be happening. I don't see >> anything >> in the spec that seems to exclude this, however I could be missing a >> subtlety somewhere. Looking at the ODE implementation it appears that >> the >> second receive must have a correlation set to route the message. >> >> Thanks, >> >> Lance >> >> >
