ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 王雷 <mail.lei.w...@gmail.com>
Subject Re: Questions About Correlation Sets
Date Wed, 15 Jun 2011 08:00:36 GMT
Hi Christophe,

    Sorry that I did explain it clearly. By talking about
"client" orchestration and "server side", I am talking about 2 independent
workflow. The following is what I want to do: One workflow, name it workflow
A, sends the same invoke message twice. Another workflow, name it workflow
B, receives the same invoke messages twice.
    I am not famaliar with correlation sets very much. I find in your
comments you said that the correlation set in the "client side" are non
sense. Did you mean in the workflow A (client side), for the invoke
activities, I do not need to put correlation set information in them?
    The two points you metioned are confirmed.
     - For workflow B (server side), the correlation set is initialized in
the first receive activity with initiate property valued to "yes". The
     - The correlation property of c1 is exactly the same.

    However, it still works in the following way: For the first invoke
activity, workflow B (server side) creates a new instance for the
invocation. For the second invoke activity, the engine routes the request
message to the existing running instance of workflow B correctly. However,
while at the same time, the workflow B (server side) create a new instance
and also routes this message to the newly created instance. I do know
whether my question is clearly explained or not. If necessary, I can put the
source code somewhere and share it with everyone. Thanks for helping.

    Best Regards

2011/6/15 Christophe Noel <Christophe.Noel@spacebel.be>

> Hello Lei,
> I work a lot with correlations.
> I don't understand correctly your question especially when you talk about
> the "client" orchestration and the "server side" ? Are you talking about 2
> independent workflow ?
> If yes, the correlation set in the "client side" are non sense.
> You should first explain what you want to do...
> Anyway, in the server side part, if you want to create a correlation on the
> first receive, then correlates with the second receive :
> - you should specify that the first correlation set should initiation the
> correlation (attribute iniate = yes)
> - you should be sure that the correlation property of c1 is exactly the
> same in the first and second receive
> Kind regards,
> Christophe.
> -----Original Message-----
> From: 王雷 [mailto:mail.lei.wang@gmail.com]
> Sent: mardi 14 juin 2011 23:58
> To: user
> Cc: a.wombacher
> Subject: Questions About Correlation Sets
> Hi,
>    I have a question about Correlation Sets. If I design a client
> orchestration as the following:
> <process ...>
>    ...
>    <invoke name="invoke1" operation="o1"...>
>        <correlations>
>            <correlation set="c1" pattern="request-response".../>
>        </correlations>
>    </invoke>
>    <invoke name="invoke2" operation="o1"...>
>        <correlations>
>            <correlation set="c1"... pattern="request-response".../>
>        </correlations>
>    </invoke>
> </process>
>    The feature is that I make the two invoke activities ("invoke1" and
> "invoke2") invoke the same operation "o1" for two times.
>    For the server side, I design this way:
> <process ...>
>    <receive name="receive1" operation="o1" createInstance="yes">
>        <correlations>
>            <correlation set="c1" pattern="request-response".../>
>         </correlations>
>    </receive>
>    <reply .../>
>    <receive name="receive1" operation="o1" createInstance="no">
>         <correlations>
>             <correlation set="c1" pattern="request-response".../>
>         </correlations>
>     </receive>
>     <reply .../>
> <process>
>    The feature is that I make the orchestration receives the two
> invocations one by one.
>    When the first message sent and received by the receiver, a new instance
> created and everything is OK.
>    After that I find strange things happens. When the client send the
> second invocation message, which is the same to the first invocation
> message, for the server part, as I expected, the message is still in a
> correlationset and the engine should route the message to the currently
> existing instance.
>    However, the actual behavior is: the engine route the message to the
> currently existing instance, then the engine create a new instance and also
> routes the message to the newly created message. Finally, when both
> orchestrations deployed and tested, it ends up with one completed client
> instance but two server instance, one in complete state but the other ends
> up with active state waiting for a message which will never come.
>    As I didn't find any information in BPEL specification about this. I
> want to ask whether this is expected behavior or a bug? Thanks.
>    Best Regards
>                 Lei

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