[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.aspnet.webservices

self-refresh of client according webservice answer

Frank Dzaebel

7/26/2003 7:08:00 AM

Hello,
I want a client-side to refresh itself when a webservice-
answer says "ok,refresh,new data".
.
I do not want a permanent submit() like this:
window.setTimeout("document.Form1.submit()",2000);
Similar to a refresh-meta-tag this would be too much
communication traffic.
.
So a small webservice-method, telling me "new data is
available" would be nice. But that call must be on the
client side !
How can I accomplish that ?

Thanks, an answer would be great, Frank
2 Answers

Dino Chiesa [MSFT]

7/28/2003 10:07:00 PM

0

If what you are getting at is how to inform the client that there is new
information, this is a general problem that has been well explored.

There are two common approaches:
Polling. the client polls the server, asking "Any new info?" every once
in a while. this is a lightweight call and doesn't necessarily send the new
info (although it may do so).

Pub/sub. The client registers interest with the server on a particular
topic ("subscribes"), and provides to the server a way to communicate with
the client. The Server tracks when information is updated (a "publish
event), then notifies the registered interested parties. [NB: pub/sub =
publish / subscribe ]

These approaches are general, and can be implemented using a variety of
technologies (RPCs, message queues, whatever). Both work with web services,
of course. In the latter case the "client" must actually listen for
incoming SOAP requests; in other words, the client becomes a server. This
may be a blocking factor in some networks.


An approach that is generally dismissed as non-scalable, but which may work
in your scenario, is to have the client send a request, and allow the
request to block at the server indefinitely, until such time as there is
fresh information to send. Only then will the server respond with the
information. This tends to consume threads, memory, and other resources on
the client but also (and more significantly) on the server, and for this
reason will not scale well. But it may work in your situation.

-dino



"Frank Dzaebel" <Post@FranksSeite.de> wrote in message
news:046e01c35344$948bb050$a601280a@phx.gbl...
> Hello,
> I want a client-side to refresh itself when a webservice-
> answer says "ok,refresh,new data".
> .
> I do not want a permanent submit() like this:
> window.setTimeout("document.Form1.submit()",2000);
> Similar to a refresh-meta-tag this would be too much
> communication traffic.
> .
> So a small webservice-method, telling me "new data is
> available" would be nice. But that call must be on the
> client side !
> How can I accomplish that ?
>
> Thanks, an answer would be great, Frank


Frank Dzaebel

7/29/2003 6:39:00 AM

0

Thanks Dino, valuable answer as is!
ok, if I decide to do Polling, what can I do?
Is it the right decision?
I also thought on 'Remote scripting', but that seemed to
be an ASP-only solution to be (so no ASP.NET).

The Scenario: Intranet with 15 Clients(WindowsCE4.1) and
1 Server(W2k), Full trust, everyone has IExplorer,
ASP.NET-hosted Website[C#].

The Problem is that the CE4.1-IExplorer-BEHAVIOR-
attribute does not work there.

So I must use Polling a webservice without BEHAVIOR-
attribute. How is that possible ?

thanks, Frank


>-----Original Message-----
>If what you are getting at is how to inform the client
that there is new
>information, this is a general problem that has been
well explored.
>
>There are two common approaches:
> Polling. the client polls the server, asking "Any new
info?" every once
>in a while. this is a lightweight call and doesn't
necessarily send the new
>info (although it may do so).
>
> Pub/sub. The client registers interest with the
server on a particular
>topic ("subscribes"), and provides to the server a way
to communicate with
>the client. The Server tracks when information is
updated (a "publish
>event), then notifies the registered interested
parties. [NB: pub/sub =
>publish / subscribe ]
>
>These approaches are general, and can be implemented
using a variety of
>technologies (RPCs, message queues, whatever). Both
work with web services,
>of course. In the latter case the "client" must
actually listen for
>incoming SOAP requests; in other words, the client
becomes a server. This
>may be a blocking factor in some networks.
>
>
>An approach that is generally dismissed as non-scalable,
but which may work
>in your scenario, is to have the client send a request,
and allow the
>request to block at the server indefinitely, until such
time as there is
>fresh information to send. Only then will the server
respond with the
>information. This tends to consume threads, memory,
and other resources on
>the client but also (and more significantly) on the
server, and for this
>reason will not scale well. But it may work in your
situation.
>
>-dino
>
>
>
>"Frank Dzaebel" <Post@FranksSeite.de> wrote in message
>news:046e01c35344$948bb050$a601280a@phx.gbl...
>> Hello,
>> I want a client-side to refresh itself when a
webservice-
>> answer says "ok,refresh,new data".
>> .
>> I do not want a permanent submit() like this:
>> window.setTimeout("document.Form1.submit()",2000);
>> Similar to a refresh-meta-tag this would be too much
>> communication traffic.
>> .
>> So a small webservice-method, telling me "new data is
>> available" would be nice. But that call must be on the
>> client side !
>> How can I accomplish that ?
>>
>> Thanks, an answer would be great, Frank
>
>
>.
>