- Hi all,
I'm a bit of a SOAP newbie, so if this is a FAQ please refer me to
RTFM (but do point out which FM as i've search most and haven't
gotten a good answer).
I'm in the process of converting a proprietery SMTP like protocol
we had, into a SOAP service (and hopefully compatible with .NET).
But I have more of a design question.
The service we provide is similar to stock quotes, in that while
they can be polled, most frequently you want to push them in real
time. So in a way, i supposed i'm asking how to return multiple
responses, but it's an arbitrarily large never ending stream of
Aside from that direct question, the corolary is whether that's
typically handled properly by client SOAP implementations. If it
requires a lot of work on the client side to get it working, it
defeats the purpose.
The only option I'm left with, is something where our customer
would write a SOAP client, and a SOAP service. The SOAP client
would register their request with our SOAP service, which would
from that point forward behaving like a SOAP client and push the
updates to their SOAP service?
I'm not sure I was especially lucid in this description. Please let
me know if I can clarify. Thanks for any help.
> they can be polled, most frequently you want to push them in realyou can create session-like object on the server side; each client would
> time. So in a way, i supposed i'm asking how to return multiple
> responses, but it's an arbitrarily large never ending stream of
'register' which type of events/changes he is interested in receiving;
then client would receive actual snapshot of the data and later client can
poll for 'any change'
server session object would monitor whether such change occurs, maintain a
queue of untransmitted changes and send all of them as a response to the
next poll from client
i have used similar mechanism, works quite fine ...
good thing is, that as soon as both server and clients are running, they
can cope with network connection drop-out, reconnect later and get all
untransmitted changes, etc ..