ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance Waterman" <lance.water...@gmail.com>
Subject Re: Opaque Routing
Date Fri, 27 Oct 2006 18:09:21 GMT
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 <boisvert@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 <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
> >>
> >>
> >
>
>

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