Assaf Arkin wrote:
> But I still believe we need to make a distinction between
> interactions
> that are finite in time (where finite could be 24 hours) and
> constrained
> to some fault-detecting context (e.g. a BPEL scope), and between
> interactions that are not finite in time and not constrained to a
> fault-detecting context and so are done using separate asynchronous
> operations. For example, if you consider submitting a
> purchase order and
> receiving an acceptance, that is typically finite in time and
> handled by
> the same sender.
I would not argue with the above characterizations. Certainly as a purely practical matter the finite time constraint is very important. My feeling is that the distinction you make based on fault-detecting context is in general more significant and should be viewed as /the/ distinction between synch/asynch interactions.
>
> But if you consider receiving an invoice and submitting
> payment, these
> two messages can be handled by different processes. In some
> implementations the invoice will be sent and the payment would be
> received by the same process. In another implementation the
> invoice will
> be sent by some process which then starts a payment
> collection process,
> and the payment is correlated and routed to the payment collection
> process (which can be used in other contexts as well). This
> is a clear
> case where using asynchronous interactions becomes more
> interesting. If
> a failure occurs while waiting for the payment this is not a
> problem for
> the process sending the invoice - you already shipped the
> order there's
> nothing you can do about it. It is, however, an issue for the payment
> collection process to deal with.
The case I am thinking of is something along the lines of a loan approval process where the loan parameters are submitted and the loan is either approved or denied. To me this is a synchronous request/response interaction; even though the approval process may take weeks, I would like to model such a process without asynchronous callbacks. This is particularly handy when nesting processes (i.e. when the loan approval process is a sub-process of a loan origination process), reducing considerably the complexity of the nesting processes.
-Maciej Szefler
