Re: [wsbpel] Topics for the "Review input from TC members" sessionof the F2FSome

[Assaf Arkin <arkin@intalio.com>]

Maciej Szefler wrote:

> I didn't mean to suggest that such a mode of operation be assumed; 
> merely that it should be considered as possibility. Currently when 
> people speak of synchronous operations it is often implicitly assumed 
> that they are speaking of an HTTP-like interaction where the response 
> is presented immediately following the request, in the same network 
> session. What I am suggesting is that this need not be the case, and 
> that the definition of an WSDL operation with both request and reply 
> messages is more properly interpreted as meaning "for each request 
> there is a corresponding response" rather than "for each request there 
> will be an immediate response in the same network session". How the 
> request/response messages are correlated is a protocol level issue 
> outside the scope of BPEL, but the idea that the response may occur 
> some time after the request (hourse, days, weeks...) should be 
> considered.

I do believe that it makes sense to use synchronous operations for 
request/response communication where the response time can be determined 
consistently. If the response time is, say 10 minutes maximum, then you 
can use a QoS extension to specify that a synchronous operation that 
does not complete within 10 minutes is considered to have failed, in 
effect generating a fault at the sender's end rather than blocking 
indefinitely. In practice I would expect synchronous operations to be 
more useful for short interactions in the order of minutes and possible 
a few hours, but not days or weeks.

On the other hand, using a HTTP-like interaction avoids the possibility 
to perform synchronous operations that take more than a minute or two. 
In the plain-SOAP-over-HTTP world there is no other option. But if you 
consider other technologies like WS-RM, then definitely you can do 
synchronous operations that take minutes or hours by using separate HTTP 
connections for request and response. The RM layer can easily deal with 
correlation of the request/response, and routing requests back to the 
sender, reducing the complexity of the application compared to using two 
separate asynchronous operations.

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.

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.

arkin

>Maciej Szefler
>Vice President - Product Development
>FiveSight Technologies Inc.
>213 N. Morgan Street
>Suite 1A
>Chicago, Illinois 60607
>phone: 312-432-0556 ext 226
>email: mbs@fivesight.com
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>  
>