On Tue, Feb 14, 2012 at 4:10 PM, Tammo van Lessen <[email protected]>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>
