Re: Asynchronous callbacks + www-ws

Alek,

I was trying to avoid polling, but so far that's the only solution that
looks workable.

Thanks,

Steve

----- Original Message -----
From: "Aleksander Slominski" <aslom@cs.indiana.edu>
To: "Steven Gollery" <sgollery@cadrc.calpoly.edu>
Cc: <www-ws@w3.org>
Sent: Friday, January 25, 2002 2:25 PM
Subject: Re: Asynchronous callbacks + www-ws


> Steven Gollery wrote:
>
> > I'm probably missing something here: the technique being discussed in
the
> > message you refer to seems to me to be applicable if one resource
(reachable
> > through a URL) is subscribing to messages from another resource (also
> > reachable through a URL). Is this correct? What if the subscriber is an
> > application -- is there some way to make this technique work in that
case?
>
> hi,
>
> there is actually a solution to this: have event publisher to expose pull
interface
> (instead of push where subscriber must provide contact endpoint with URL
that is
> used to push events) and have an application to use an agent library that
will be
> periodically pulling events and then notify application (using call-backs
as was
> described before).
>
> that will allow to run application to get events even if run behind
firewall and if
> event publisher maintains messages in persistent storage application can
retrieve
> events even if there were temporary failures (network going down, event
publisher
> restarted, etc.).
>
> thanks,
>
> alek
>
> ps. we are to soon publish XEVENTS that is implementation of event
framework on top
> of SOAP that provides pull interfaces, generic and persistent event cannel
on top
> of SQL database and other goodies ...
>
>
>
>
>

Received on Friday, 25 January 2002 19:32:11 UTC