text: describe a web services application.? describe a web services application for monitoring the clarity of water of lakes in minnesota. the department of natural resources (dnr) has placed a wireless sensor under the water in the middle of each lake that measures the clarity every minute and reports a single number indicating water clarity. the sensors have wireless network connections and each run a web server that reports  the result as a simple html page. the sensor has limited power, so you want its web server to only be touched once per minute. your web service runs on a computer on the shore of each lake. it scrapes the screen of the sensor web site, and presents the results as a web service. we want a main dnr web site to have a display of the clarity of water in all of the lakes in the state.   draw an architecture of the entire system, including the  sensors and the final web site. explain how it works.   what are the practical and philosophical differences between  having the sensor run a web server and a web service directly technically a web server is a web service - of sorts.  it responds to http requests, typically with html documents.  however, the documents do not adhere to the soap standards implemented by most newer web services so the only recourse is to hunt the html for keywords and tags that indicate where the data you're scraping for is located.  since you have some practical limitations on how frequently these devices could be called, my first inclination would be to develop a centralized "collection" service that periodically polled the various clarity monitoring devices and stored the data in a local database (timestamped from an accurate, central time source).  it would still do the "scraping" from the various devices, but would act as a proxy to minimize the amount of traffic each device was required to handle.  the polling interval would be based upon how frequently you needed to update the data.  i'm assuming these devices can be accessed via tcp/ip.  lacking any drawing tools, the architecture is fairly simple.    [polling server] -- [clarity monitoring devices]     |     | [database server]     |     | [web service]     |     | [clients] or [web server]  what would help is if you have the ability to modify the web page on the monitoring devices.  if so you could customize the html response to conform to a standard soap document that could be called as a remote object from the polling server (instead of having to parse the html).  alternatively, you may also be able to have the web server on the monitoring devices respond in an xml format that can be much more easily parsed by the polling server.  i am assuming this is possible since the web server on these devices provides clarity information on-demand (which typically requires some sort of scripting).  if you would like additional details, please e-mail me at melancholygiant@yahoo.com.