neither client nor server be I

[beachdog]

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?

[beachdog]

On Apr 26, 9:53 am, beachdog <[e-mail]:

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?