Sign in or 
| Version | User | Scope of changes |
|---|---|---|
| Oct 11 2009, 2:02 PM EDT (current) | sdrevik | 450 words added |
| Oct 11 2009, 1:57 PM EDT | sdrevik |
Changes
Key: Additions Deletions
AQI Web Service
For E-DAS Customers upgrading to AirVision, you will notice that the Access database has been replaced with the SQL Server database that now stores all the data for the system. A variety of data views are available for querying the data for web publishing.
One data type that is dynamically generated at is not available in a view is the AQI. Since it is mostly used for web site publishing, we have simplified the access to that data by adding a Web Service to the regular AirVision service on the server. This web server does not require the installation of Internet Information Services (IIS). Rather, it is exposed via WCF as a http web service. Normally a developer would write a custom client application to consume it (should be consumable frombasically any modern language that supports web services).
There are two service methods, one which accepts a SiteID (the unique identifier) and adateTime, the other accepts a SystemName/SiteName/DateTime in case you prefer to query it by natural keys (site name, parameter name) rather than the guid. Both return the same result.
SiteAQIResultData CalculateSiteAQIById(Guid sourceSiteID, DateTime,aqiDateTime);
SiteAQIResultData CalculateSiteAQIByNaturalKey(string systemName,string siteName, DateTime, aqiDateTime);
The base URL is this (of course replace the machine name):http://machinemame:9888/AirVision.Services.WebServices.AQI/AQIService/
That is the URL that consuming clients use. Also if you pull that up in aweb browser you'll get a friendly display page (although the generated linkon there will be susceptible to the localhost problem I mentioned before).
The WSDL is located at the same address + "?wsdl", like this:http://machinenamer:9889/AirVision.Services.WebServices.AQI/AQIService/?wsdl
The schema of the inputs/outputs are located at the base url + "?xsd=xsd0",like this:http://machinename:9889/AirVision.Services.WebServices.AQI/AQIService/?xsd=xsd0
This defines the input/output data structures used by the service operations.These URLs/ports (and all the other WCF options such as protocol, bindings, etc) can be changed in the service's app.config file. You can tweak it locally on your server, or we can update the default one in our source control if needed.
A useful test tool called WcfTestClient.exe, which comes with MS VS.NET. It autodiscovers the service and lets you fill in the input arguments manually, then executes the service method, and displays the result.
HOWEVER, these test tools is they seem to pull in the server's internal representation of the URL (e.g. http://localhost:9889/....) which causes problems if the client isn't on the same machine. To get around it you have to tweak the app.config of the service to have the actual machine name in there. A real app client can work with it as-is (no tweaking required), but these "automagical" test tools pull additional information from WCF to generate everything dynamically and they are the only case where the localhost thing is a problem.
For E-DAS Customers upgrading to AirVision, you will notice that the Access database has been replaced with the SQL Server database that now stores all the data for the system. A variety of data views are available for querying the data for web publishing.
One data type that is dynamically generated at is not available in a view is the AQI. Since it is mostly used for web site publishing, we have simplified the access to that data by adding a Web Service to the regular AirVision service on the server. This web server does not require the installation of Internet Information Services (IIS). Rather, it is exposed via WCF as a http web service. Normally a developer would write a custom client application to consume it (should be consumable frombasically any modern language that supports web services).
There are two service methods, one which accepts a SiteID (the unique identifier) and adateTime, the other accepts a SystemName/SiteName/DateTime in case you prefer to query it by natural keys (site name, parameter name) rather than the guid. Both return the same result.
SiteAQIResultData CalculateSiteAQIById(Guid sourceSiteID, DateTime,aqiDateTime);
SiteAQIResultData CalculateSiteAQIByNaturalKey(string systemName,string siteName, DateTime, aqiDateTime);
The base URL is this (of course replace the machine name):http://machinemame:9888/AirVision.Services.WebServices.AQI/AQIService/
That is the URL that consuming clients use. Also if you pull that up in aweb browser you'll get a friendly display page (although the generated linkon there will be susceptible to the localhost problem I mentioned before).
The WSDL is located at the same address + "?wsdl", like this:http://machinenamer:9889/AirVision.Services.WebServices.AQI/AQIService/?wsdl
The schema of the inputs/outputs are located at the base url + "?xsd=xsd0",like this:http://machinename:9889/AirVision.Services.WebServices.AQI/AQIService/?xsd=xsd0
This defines the input/output data structures used by the service operations.These URLs/ports (and all the other WCF options such as protocol, bindings, etc) can be changed in the service's app.config file. You can tweak it locally on your server, or we can update the default one in our source control if needed.
A useful test tool called WcfTestClient.exe, which comes with MS VS.NET. It autodiscovers the service and lets you fill in the input arguments manually, then executes the service method, and displays the result.
HOWEVER, these test tools is they seem to pull in the server's internal representation of the URL (e.g. http://localhost:9889/....) which causes problems if the client isn't on the same machine. To get around it you have to tweak the app.config of the service to have the actual machine name in there. A real app client can work with it as-is (no tweaking required), but these "automagical" test tools pull additional information from WCF to generate everything dynamically and they are the only case where the localhost thing is a problem.
