You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by Lance Waterman <la...@gmail.com> on 2006/10/27 07:06:57 UTC
Opaque Routing
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
Re: Opaque Routing
Posted by Lance Waterman <la...@gmail.com>.
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 <bo...@intalio.com> 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 <la...@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
> >>
> >>
> >
>
>
Re: Opaque Routing
Posted by Alex Boisvert <bo...@intalio.com>.
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 <la...@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
>>
>>
>
Re: Opaque Routing
Posted by Maciej Szefler <mb...@intalio.com>.
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 <la...@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
>
>
Re: Opaque Routing
Posted by Alex Boisvert <bo...@intalio.com>.
I believe <reply> can only be used if it has a preceding <receive> with
the same {partnerLink, operation, messageExchange} tuple, regardless of
whether it uses an opaque or explicit correlation set.
Section 10.4.1. Message Exchanges of the BPEL 2.0 (Public Review Draft,
23th August, 2006) discusses this subject.
alex
Lance Waterman 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
>