text: 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.\n\nSince 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.\n\nI'm assuming these devices can be accessed via TCP/IP.  Lacking any drawing tools, the architecture is fairly simple.  \n\n[Polling Server] -- [Clarity Monitoring Devices]\n    |\n    |\n[Database Server]\n    |\n    |\n[Web Service]\n    |\n    |\n[Clients] or [Web Server]\n\nWhat 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).\n\nIf you would like additional details, please e-mail me at melancholygiant@yahoo.com.