Create web service to return personal weather station or airport weather station data from wunderground.com.
The web service will return JSON or XML data. wunderground.com API returns XML data.
When a user request weather information for a location, the web service will return the closest weather information for that location that is available. If nothing is available, or the closest is deemed to be too far away, the user will be asked if this is good enuogh and a message will be added to our logs informing the application administrator that closer weather data is required.
If the user, or an administrator adds a new weather station, the longitude and latitude will be added to the database, as with the name of the station, a link, and an ID that will map to a file system location, when it was added and if the last update was successful. Weather stations once added will be updated every 3 hours, 8 times in a 24 hour period. These will be translated into JSON files when requested.
The directory system will be based on weather station ID and the date in the form YYYYMMDD. Each directory will only contain up to 8 XML files, relating to a single weather station and day. Each directory may also contain JSON files. Perhaps a PHP XSLT engine, or C XSLT engine could be used to generate the desired JSON and JSONP files. We may utilise a library such as Xalan-C to generate JSON files. I’ve investigated XSLT solutions and it appears that PHP has suitable XSLT functions. I will modify this procedure, but it shows that the functionality is suitable.
$proc = new XSLTProcessor();
if (!$proc->hasExsltSupport())
{
die('EXSLT support not available');
}
// Load the XML source
$xml = new DOMDocument;
$xml->load('test.xml');
$xsl = new DOMDocument;
$xsl->load('test.xsl');
// Configure the transformer
$proc->importStyleSheet($xsl); // attach the xsl rules
if(isset($_GET["callback"])) echo $_GET["callback"]."(";
echo $proc->transformToDoc($xml)->firstChild->wholeText;
if(isset($_GET["callback"])) echo ")";
We will be able to resolve the closest weather station or stations to a particular point and (in our user interface) allow a user to select the favoured weather station.
SoapUI is a useful little tool for reading wsdl files, from a URL or as a file. It can then generate default request messages for each method allowing you to go through and tailor a set of test data. It has been developed in Java and builds requests and displays responses from the web service. I’ve got version 1.5 which is completely suitable for my current needs, though I notice they are up to version 2.5 and they have a professional release.
TCPMon was part of the Apache Axis1 project, but it is now an independent Apache project. The only available version is 1.0, released in March 2006! TCPMon is useful for debugging traffic between any TCP client and server. You set up a local port and point it to a server and port. TCPMon then shows you the communication. Very useful for any TCP based project, especially so for SOAP.
I’d love to see some! I was reading an ex-colleagues blog (Big Geek Consulting) which presents some tools for building useful documentation.
Big Geek’s list is a collection of tools included in a Slashdot discussion:
- FOP is an Apache XML XSL-FO renderer, written in Java. So it doesn’t really address the documentation issue, Apache FOP only provides a rendering solution.
- Xetex is a latex descendant. TeX solutions do not solve technical documentation issues, but I believe text based solutions like LaTeX do provide better version tracking opportunities that a binary formatted document.
- Lout Vaguely wiki like (but pre-dating) style of document writing, but with support for all the bits you need to create a document, not just text. Uses Knuth algorithms for line spacing. Lout is a document formatting system designed and implemented by Jeffrey Kingston at the Basser Department of Computer Science, University of Sydney, Australia.
- Prince An HTML based commercial solution for making real documents. It supports new and fancy CSS properties that let you make real documents. Mergable, diffable, standards based, but not free.
I think DocBook should also be added to the list; DocBook is an Oasis supported XML standard for xml technical documentation, used by CERN, FreeBSD, Linux, Gnome and co. From which you can use XSL-FO (or FOP) to render into whatever pretty format you want.
Purposefully excluded from the list:
Both of these applications now support XML based document formating. I think this makes both applications acceptable technical documentation options, as long as Open XML standards are used, then real difference comparisons could be made between versions.
My issue with technical and project documentation is that it does not represent a dynamic system well. Typically business users and management will want to use Microsoft word products and turn on change tracking to manage change. The problem I have with this approach is it is almost impossible to understand a document that has change on; it is impossible to compare different versions of that document and the document grows to incredible size to manage it.
A XML or other plain text markup solution offers simplicity in change management, it can be delegated to a content management system with difference tools – like subversion or CVS, where most of the project deliverables are maintained. Where such a solution would fail would be with business users , or anybody who wants to create a document quickly.
For me, this would make OpenOffice or Microsoft word (if users saved files as XML) the best solutions. The user would be able to quickly create XML based documents that are easy to read and anybody who wanted to compare any particular version would be able to do so from the source management system.
