[quoted text, click to view] On Apr 26, 9:53 am, beachdog <dhor...@pactolus.com> wrote:
> I have a scenario that I think is probably not all that uncommon, and
> I would like to fall into the standard pattern of implementing it, if
> one exists. I have a process which wants to expose a web service that
> is a bit more complicated that an standard request-response, or in-
> out, message exchange pattern. In my case, my service will receive a
> request and transmit a response immediately acknowledging the
> request. I then want to send one or more notifications as the request
> is processed, ending with a final notification.
>
> So it seems to me that my service starts off like a standard "in-out"
> web service, but then has to act as a client in sending notifications
> back to the original requestor (which started off looking like a
> client, and now has to act like a server).
>
> I am using HTTP/SOAP as the transporting/encoding between the two
> servers.
>
> My questions are:
>
> 1) Is it typical to establish one persistent TCP connection with
> keepalive over which the initial request/response are transmitted,
> along with the ensuing notifications? Or would it be more common for
> a separate connection to be opened for the request/response and then
> for each ensuing notification?
>
> 2) Any tricks to doing this using Visual Studio/C# to act in the role
> of the initial requestor? I have the initial request/response working
> fine, using wsdl to generate my proxy stub for consuming the remote
> web service, do I know have to implement code to expose a web service
> of my own to receive the notifications?
Any help on this?