several responses from same webservice?

[Davey]

hi there
Im new to webservices and I think they can help solve a communication
problem.
We are designing a system that will have a core server type
application and several client applications.
The core application will have a webserver bolted on so all the client
apps can communicate with it.
Each of the client apps will only ever use one of the webservices
available.

Once a request is made to the webservice, there may be several
responses to that cient app,each sending the same type of information.
This is because the client is doing reports on the information from
the server app.
The server app cannot do the reports.
The client app is also responsible for ending the communication,once
it has satisfied all its criteria.

So my questions are:
Can I have an application connect to a webservice and recieve several
responses? i.e. can i have it sit and wait for responses
Can I send a cancel request after the webservice has provided enough
information?
Should we use webservices?

The main reason we want to use webservices is that we have some older
apps in c++ that we want to integrate with the new ones.


Any help would be great
Thanks
Dave

 

[Trebek]

Dave,

I would say this is a better candidate for remoting vs a webservice. Web
services really don't offer much with regard to 'persistent' connections
since it really is simple http request/response under the soap covers. You
usually have to establish some sort of polling architecture if you want to
drive things from the client. You can always host your remote object in
IIS. It's very simple and would offer you much of the same web service
benefits.

Alex

 

[Davey]

Hi Alex,
Thanks for the reply. Yes,I wasnt sure if web services were built for
that kind of scenario. I'll look into remoting. Thanks again.
Dave

 

[Dino Chiesa [Microsoft]]

there is a WS-Eventing spec that covers this model of communication, but it
is just a spec, not implemented and available in the framework yet.

the downside with the use of remoting is that it is a non-standard model.

since your client "waits for responses" from the server anyway, there are
two approaches worth exploring: one is the polling mechanism. when the
client wants more data, it should just ask, "any more for me?" and the
server can hand it over.

else, the client itself can expose a webservice interface, and the server
can call it back. there are examples of this, using cassini. the client
and server then act more as peers. both can initiate the dialog.

 

[Davey]

Hi Dino,
yes, the polling approach would work for the reporting alright.
The idea of having both apps with a webservice could also be an good
enough solution (although it might be a bit longwinded). I think it
might be wasteful for the server app to connect to the client
webservice and send data for every event.

So I was thinking something like this might be better.
1 - A client uses a webservice to notify the server app that it wants
START to do reports on events coming into the server. The server app
responds stating that it is in report mode.
2 - The server then collects information on incoming events
3 - Then every minute (if there are any events) it connects to the
clients webservice and passes this information to it.
4 - At any stage the client app can call the servers webservice to
STOP sending events.


Remoting sounds good aswell but i've only started reading about it.
Think I need to read more about both technologies!

Thanks guys, Its good to know we have a few options.

Dave