Web Services

  • Thread starter Thread starter ozbear
  • Start date Start date
O

ozbear

I am somewhat confused as to when a web service application gets
started and/or terminated by IIS.

What I want is to be able to start an IIS web service that runs
continuously acquiring new data from an external source that it
squirrels away in an MS SQL database. The service acquires this
data approximately every 15 seconds.

Web clients connect and display the latest (or whatever date-time
they like) but there is no guarantee that anyone will be
connected to the web service.

How do I get my web service to "run" in the total absence of any
client browsers?

Oz
 
Sounds like you need to use something like a
System.Timers.Timer on your web service, which gives you
an Elapsed event - assuming you're writing it in visual
studio .net you can just drop the component onto your web
service.

Regards
Helen
 
An alternative is to partition your app into 2 pieces - one pice that runs
"all the time" regardless wheteher anyone is connected. This is the role
of a Windows service, not a webservice. A Windows service runs "all the
time" in the background and is not designed to respond to client requests,
per se. You can build a Windows Service within Vs.NET.

The second piece then handles incoming client requests - in other words a
classic webservice. It gets started by IIS on demand - that is, when an
incoming webservice request comes in.

You will need some sort of interconnect or communication between the two
pieces. Since you already have a SQL Server, that can be the interconnect.
The Windows Service writes to the MS SQL Server, and the Web service reads
from it.

-D
 
An alternative is to partition your app into 2 pieces - one pice that runs
"all the time" regardless wheteher anyone is connected. This is the role
of a Windows service, not a webservice. A Windows service runs "all the
time" in the background and is not designed to respond to client requests,
per se. You can build a Windows Service within Vs.NET.
<snip>
Thank you for your reply. I am still unclear on exactly when a
web service gets started by IIS and when it gets terminated.
My guess is that it is started when the first client connects and
gets snuffed when the last one leaves.

After getting started, though, if I have a System.TImer that fires
periodically, will that keep it running or will the web service be
extinguished by IIS anyhow?

Oz
 
Oz,

Web service is a piece of code on ur web server. So if you have it hosted on
your localhost and if your localhost is running your webservice is also
running.
Running in the sense, client can connect to it. I think you should try using
a private method invoked by a timer to communicate to another webservice or
say a remoting server to fetch the data.

hope this helped.

Hermit Dave
 
ozbear said:
Thank you for your reply. I am still unclear on exactly when a
web service gets started by IIS and when it gets terminated.
My guess is that it is started when the first client connects and
gets snuffed when the last one leaves.

A webservice is started "on demand" - when a request comes in. It may be
stopped or recycled after it reaches a settable limit.

For IIS5:
ASP.NET sits on top of IIS. IIS runs in a process called Inetinfo.exe. It
hands off requests for ASPX files and other ASP.NET resources to an ISAPI
DLL named Aspnet_isapi.dll which, by default, runs in-process to
Inetinfo.exe. Aspnet_isapi.dll forwards the requests to the ASP.NET worker
process, Aspnet_wp.exe, using a named pipe. (There are actually several
named pipes connecting Inetinfo.exe and Aspnet_wp.exe, some synchronous and
some asynchronous. ASP.NET also uses a named pipe, for example, to call back
to IIS to resolve calls to Server.MapPath.) Inside Aspnet_wp.exe are
AppDomains segregating the ASP.NET apps running on the host server. Once a
request is assigned to a specific AppDomain, it travels through ASP.NET's
HTTP pipeline and is ultimately processed by the HTTP handler that
corresponds to the requested file type (eg, ASMX). The response is returned.
The worker process hangs around.

ASP.NET supports recycling worker processes based on a number of criteria,
including age, time spent idle, number of requests serviced, number of
requests queued, and amount of physical memory consumed. The global .NET
configuration file, machine.config, sets thresholds for these values (see
the processModel element). When an instance of aspnet_wp.exe crosses one of
these thresholds, aspnet_isapi.dll will mark the process "expired" and will
stop sending it requests, and will stop the process itself, either
forcefully (if a memory limit has been exceeded), or gracefully, allowing
all requests to complete. If new requests come in, then IIS launches a new
instance of the worker process and starts sending it requests. If no new
requests come in, then no new worker process is started.

In your case the idleTimeout may apply - but by default it is "infinite".
Which means, ASP.NET will not recycle a worker process, even if no new
requests come in for a year.

For IIS6, the details are different.
Bu the process recycling still happens.

references:
http://www.msdn.microsoft.com/msdnmag/issues/02/09/HTTPPipelines/default.aspx
http://www.microsoft.com/technet/pr...roddocs/standard/aaconprocessmodelelement.asp

After getting started, though, if I have a System.TImer that fires
periodically, will that keep it running or will the web service be
extinguished by IIS anyhow?

The <processModel> settings determine when the worker process will be
stopped or recycled.

-D
 
I enounter the same problem as you do, I solve it with a Windows Serive
running at the backgroud, and the client side web service put the parameter
into the database then call the customer command of the windows service.
This will work well for you I guess.

For the client side a javascript is wrote to refresh (hence invoke the web
service) the page once a certain period of time.
 
Back
Top