[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Topics for the "Review input from TC members" sessionof the F2FSome
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]