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
