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
