ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <ar...@intalio.com>
Subject Re: Question about handling in-out operations
Date Fri, 13 Mar 2009 19:43:20 GMT
2009/3/13 Andi Abes <aabes@progress.com>

> The BPEL spec demands of engines to handle messages received by them before
> the corresponding receive activity has executed.
> This makes sense since it avoids various race conditions and
> inconsistencies among diff bpel engines (see quote below).
>
> As such, ODE is correct in holding the message pending, until the receive
> activity is activated.
> Potentially a better modeling approach would be to use a pick activity and
> an onAlarm as a means to implement the 10 minute timeout.
> An alternative could be to event handlers in scope containing the <wait>
> sop you can process the incoming message (even if only to reject it using
> some application error).



>
>
> Quote from p.92 of BPEL spec:
>
> Race conditions may occur in a business process execution. Messages that
> target a particular process instance may arrive before the corresponding
> <receive> activity is started. For example, consider a process that receives
> a series of messages in a loop where all the messages use the same
> correlation. At runtime, the messages will arrive independent of the
> iterations of the loop. The fact that the correlation is already initiated,
> however, should enable the runtime engine and messaging platform to
> recognize that these messages are correlated to the process instance, and
> handle those messages appropriately. Another example is a process that may
> invoke a remote service then initiate a correlation set for an expected
> callback message. For a variety of reasons, the callback message may arrive
> before the corresponding <receive> activity is started.
>

The remainder of the paragraph:

The correlation data in the arriving message should enable the engine
to recognize that the message is targeted for this process instance.
Process engines MAY employ different mechanisms to handle such race
conditions. This specification does not mandate any specific
mechanism. Details of message delivery mechanisms are outside of the
scope of this specification. However, a WS-BPEL processor should
deliver messages to the process instance according to the quality of
service of the underlying message delivery and transport mechanisms.
For the purposes of handling race conditions, an <onMessage> clause in
a <pick> and an <onEvent> event handler are equivalent to a receive
(see sections 11.5. Selective Event Processing - Pick and 12.7.1.
Message Events).


When doing request/response with SOAP over HTTP, the quality of service
guarantee is that of HTTP, which doesn't allow requests to be held
indefinitely, so Ode should reject the request if it can't service the
operation quickly enough.

If this was one-way over asynchronous transport, queuing the message and
handling it 10 minutes later would be the correct approach.

Assaf



>
>
>
> > -----Original Message-----
> > From: Rafal Rusin [mailto:rafal.rusin@gmail.com]
> > Sent: Friday, March 13, 2009 8:40 AM
> > To: user@ode.apache.org
> > Subject: Question about handling in-out operations
> >
> > I have a following process:
> > <receive1 operation1 correlationSet1/>
> > <reply1/>
> > <wait 10min./>
> > <receive2 operation2 correlationSet1/>
> > <reply2/>
> >
> > When I send a message for operation2 during wait, I get timeout.
> > Shouldn't it be some fault exception like "no such operation" without
> > any delay instead?
> >
> > I'm attaching an example with soapUI test case.
> >
> > Regards,
> > --
> > RafaƂ Rusin
> > http://www.touk.pl
> > http://www.mimuw.edu.pl/~rrusin
>

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