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


+1

Mark.

----- Original Message -----
From: "Maciej Szefler" <mbs@fivesight.com>
To: "Mark Little" <mark.little@arjuna.com>; "Marin, Mike"
<MMarin@filenet.com>; <wsbpel@lists.oasis-open.org>
Sent: Tuesday, May 27, 2003 5:05 PM
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]