OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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" session of the F2FSome


>> I have seen so far no mention of handling for long-running synchronous
>>invocations and would suggest that they be explictly  mentioned in the
>>specification. Using asynchronous callbacks for all long-running
>>interactions is a bit of a burden; with increased adoption of web services
>>technology it seems inevitable that more web services will be deployed on
>>reliable asynchronous messaging systems where the issue is very pronounced.
>>Specifically I am proposing that the notion that a synchronous request/reply
>>operation is always completed in a "reasonable amount of time"  (ie in one
>>HTTP session) be eliminated.
>>

>I'm not sure this is realistic. Using reliable messaging imposes an
>overhead: you don't get something for nothing, especially in the area of
>fault-tolerance. There are many situations where fault handling can be more
>efficiently managed at the application level simply because it has the
>necessary semantic information to do that. I think we have to be pragmatic
>and support what people are using now as well as what they *may* use in the
>future - I for one don't have a scrying glass to see the future ;-)
>Mark.

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.  

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]