You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ode.apache.org by Monica <mo...@hotmail.com> on 2012/02/14 02:24:07 UTC
correlation-set usage
Hello,
I'm evaluating the use of ODE in our organization and one thing that I'm not
clear about is how one can get the status of, and eventually continue, an
existing instance of a process.
So the scenario is this: a client makes a call to a process deployed on ODE.
As
a result, ODE starts a new instance of the process, which internally is calling
a
bunch of services. While the process is executing, the blocking connection
between the client and ODE is severed, but the client needs to be able to get a
status or continue that same instance of the process.
Is this possible?
Would correlation-sets help here? If the client passes a correlation-id header
as
part of its initial request to ODE, and ODE starts the instance of the process
as
described above. Then if the client sends the exact same request again, with
the
same correlation-id, would ODE start a new instance or continue the one that
stopped in the middle?
I'm asking several questions here, please let me know if you need more
information.
thank you!
M
Re: correlation-set usage
Posted by Denis Weerasiri <dd...@gmail.com>.
On Tue, Feb 14, 2012 at 4:10 PM, Tammo van Lessen <tv...@gmail.com>wrote:
> Hi Monica,
>
> thanks for your interest in ODE. Please see my comments inline:
>
> On 14.02.2012 02:24, Monica wrote:
> > So the scenario is this: a client makes a call to a process deployed on
> ODE.
> > As
> > a result, ODE starts a new instance of the process, which internally is
> calling
> > a
> > bunch of services. While the process is executing, the blocking
> connection
> > between the client and ODE is severed, but the client needs to be able
> to get a
> > status or continue that same instance of the process.
> >
> > Is this possible?
>
> Yes, this is possible. BPEL is taylormade for such scenarios and
> provides the needed concepts for that (correlation, event handling). I'd
> avoid to use synchronous interactions for long-running processes since
> this will likely result in (HTTP) timeouts, which are difficult to handle.
>
> For the "get status" scenario there are basically two possibilities:
> 1) start the process instance with a one-way request and let the
> process asynchronously notify the caller. This, however, requires that
> the original caller manually correlates the response since there are no
> traces to the original request in the message.
> 2) start the process instance with a one-way request and attach an
> event handler to the root scope of the process. This handler is active
> during the life cycle of the process instance and consume any messages.
> Your client can use this to poll for status etc.
>
> In order to continue a process instance, you can model a second receive
> activity on a different operation but with the same correlation set. The
> process instance will wait until this message arrives, and when a
> message is sent to ODE, ODE will check its correlation tokens and will
> route it to the matching instance.
>
> All approaches involve correlation. Since running business
> processes are first class business artifacts, they are in practice
> identified in business terms and thus it is a design goal of BPEL to
> support correlation using business terms instead of artificial
> correlation identifiers.
Hi Monica,
+1, and a small addition as you have mentioned "correlation-id header"; you
can't use parts in SOAP header for the correlations sets. It should be
parts in the SOAP body.
> This means you can define correlation based on
> parts of your messages, e.g. an order number or customer ID or a
> combination of both. You can even use different correlation sets for
> different partner interactions. This is a powerful tool that should help
> you with your scenario. However, it is important to keep correlation
> tokens unambiguous. You should take this into account when designing the
> correlation sets and the WSDL operations.
>
> For more information about correlation I can recommend reading the BPEL
> primer document [1] (in case the whole spec [2] is too heavy-weight,
> which it definitely is -- people keep telling it is as dense as
> plutonium ;).
>
> I hope I could help you a little.
>
> Best,
> Tammo
>
> [1] http://docs.oasis-open.org/wsbpel/2.0/Primer/
> [2] http://docs.oasis-open.org/wsbpel/2.0/
>
> --
> Tammo van Lessen - http://www.taval.de
>
--
Thanks,
Denis
----------------------------------------------------------
*Denis Weerasiri*
*
*
<http://wso2.com/>**** <http://wso2.com/>*site: **
https://sites.google.com/site/ddweerasiri/*<https://sites.google.com/site/ddweerasiri/>
*blog: **http://ddweerasiri.blogspot.com* <http://ddweerasiri.blogspot.com/>
*
twitter: **http://twitter.com/ddweerasiri* <http://twitter.com/ddweerasiri>*
linked-in: **http://lk.linkedin.com/in/ddweerasiri*<http://lk.linkedin.com/in/ddweerasiri>
Re: correlation-set usage
Posted by Tammo van Lessen <tv...@gmail.com>.
Hi Monica,
thanks for your interest in ODE. Please see my comments inline:
On 14.02.2012 02:24, Monica wrote:
> So the scenario is this: a client makes a call to a process deployed on ODE.
> As
> a result, ODE starts a new instance of the process, which internally is calling
> a
> bunch of services. While the process is executing, the blocking connection
> between the client and ODE is severed, but the client needs to be able to get a
> status or continue that same instance of the process.
>
> Is this possible?
Yes, this is possible. BPEL is taylormade for such scenarios and
provides the needed concepts for that (correlation, event handling). I'd
avoid to use synchronous interactions for long-running processes since
this will likely result in (HTTP) timeouts, which are difficult to handle.
For the "get status" scenario there are basically two possibilities:
1) start the process instance with a one-way request and let the
process asynchronously notify the caller. This, however, requires that
the original caller manually correlates the response since there are no
traces to the original request in the message.
2) start the process instance with a one-way request and attach an
event handler to the root scope of the process. This handler is active
during the life cycle of the process instance and consume any messages.
Your client can use this to poll for status etc.
In order to continue a process instance, you can model a second receive
activity on a different operation but with the same correlation set. The
process instance will wait until this message arrives, and when a
message is sent to ODE, ODE will check its correlation tokens and will
route it to the matching instance.
All approaches involve correlation. Since running business
processes are first class business artifacts, they are in practice
identified in business terms and thus it is a design goal of BPEL to
support correlation using business terms instead of artificial
correlation identifiers. This means you can define correlation based on
parts of your messages, e.g. an order number or customer ID or a
combination of both. You can even use different correlation sets for
different partner interactions. This is a powerful tool that should help
you with your scenario. However, it is important to keep correlation
tokens unambiguous. You should take this into account when designing the
correlation sets and the WSDL operations.
For more information about correlation I can recommend reading the BPEL
primer document [1] (in case the whole spec [2] is too heavy-weight,
which it definitely is -- people keep telling it is as dense as
plutonium ;).
I hope I could help you a little.
Best,
Tammo
[1] http://docs.oasis-open.org/wsbpel/2.0/Primer/
[2] http://docs.oasis-open.org/wsbpel/2.0/
--
Tammo van Lessen - http://www.taval.de