ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maciej Szefler" <...@intalio.com>
Subject Re: Opaque Routing
Date Fri, 27 Oct 2006 15:05:56 GMT
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.

On 10/27/06, Lance Waterman <lance.waterman@gmail.com> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message