Loading ...
Sorry, an error occurred while loading the content.

Persistent connection?

Expand Messages
  • Pablo Averbuj
    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
    Message 1 of 2 , Mar 2, 2003
    View Source
    • 0 Attachment
      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
      responses.

      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.

      --
      -Pablo
    • Martin Hajduch
      ... you can create session-like object on the server side; each client would register which type of events/changes he is interested in receiving; then client
      Message 2 of 2 , Mar 2, 2003
      View Source
      • 0 Attachment
        > 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
        > responses.

        you can create session-like object on the server side; each client would
        '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 ..

        regards,
        martin
      Your message has been successfully submitted and would be delivered to recipients shortly.