As I mentioned in part 2, the weather data is coming directly from NOAA.  The NOAA SOAP Web Service is a free web service for accessing all the available weather data.  Unfortunately the web service is difficult to work with.  To me it looks like the web service was implemented based on the architecture of the weather data with minimal regard for the consumer of the service.  Subsequently I had to spend a lot of time figuring out how to parse the data with Groovy (more on that later).

I had to decide exactly how I was going to access the NOAA web service.  I had a couple of choices.  I could use:

• Groovy – Groovy has some rudimentary capabilities for accessing SOAP web services.  I could use Skyway’s support for Groovy to access the web service.
• Apache Axis – I could use Axis to generate a client from the WSDL for accessing the web service.  I could take the code generated by Axis and include it in my project and invoke it using Skyway’s Invoke Java step.
• Skyway Builder Enterprise Edition (EE) – Skyway Builder EE can produce web services (contract-first or contract-last) and consuming SOAP web services.  My intention wasn’t to produce web services, but I could use Skyway Builder EE to integrate with the service using the WSDL.

Since I wanted users of open-source Skyway Builder Community Edition (CE) to be able to study and use this project, I decided against using Skyway Builder EE.  I ultimately decided to see how far I could get with Groovy.  If needed, I could always use Apache Axis.

I was principally concerned with getting weather data from the NOAA web service, but in order to do so I needed to provide coordinates (longitude and latitude) as an input to the service.  I didn’t want the end-user of the application to have to figure out the coordinates for a city on their own, so I used a different operation in the NOAA web service for getting a list of cities and the coordinates for the city.

Now I had a pretty good idea of the the data and operations that are available from the NOAA web service.  So in the modeling project I defined two data types for storing the data that I will get from the service and use in my Appcelerator application. The data types are:

• Location – for storing city and coordinates
• WeatherData – for storing forecasted temperatures, humidities, and weather icons.

Data Type: Location

Data Type: WeatherData

In order to minimize calls to the NOAA web service, I wanted to load the city and coordinates from the web service only once.  So upon the initial invocation of the web application, the locations would be loaded and persisted to a database.  Subsequent invocations will read the data from the database.  It seamed like a reasonable solution since the location data is just pairs of city names and latitude/longitude coordinates that shouldn’t change.  In order to be able to persist the Location data type, I created the LocationDAO (data store).

For getting the list of cities from the NOAA web service I used NOAA’s latLonListCityNames operation.  I tried to implement the Skyway operation (loadLocations) to use only Groovy for calling the NOAA weather service, but I ran into problems.   So instead I decided to use Apache Axis for calling the service.  I invoke Axis using Skyway’s Invoke Java Step, and I use Groovy’s excellent XML processing capabilities to parse the xml returning from the web service call and map each city/coordinate to a Location bean.  At the end of the Groovy step, I’m left with a collection of Locations (193 in total).  The load action (see screenshot below) show the implementation of the Spring service.  As you can see, in addition to the web service processing logic there’s some additional modeling logic to persist the web service data and to call the web service only if there aren’t any persisted locations in the database.

Operation: loadLocations

For getting the weather forecast for a particular city I used the NOAA’s NDFDgen operation.  Once again I decided to access this operation using Apache Axis and use Groovy for processing the XML.  It took me a while to figure out how to parse the XML, but at the end I figured it out.  I ended up with a simple collection of WeatherData objects.  As you can see from my implementation of the Skyway getWeatherForecast operation, this time I use Skyway’s Invoke Groovy Step for both invoking Axis and parsing the results.  This was done differently for no particular reason…I was just experimenting.

A quick note on Apache Axis.  I had to used a patched version of Apache Axis 1.4, and the WSDL2Java command line tool generated the java code for web service invocation from the WSDL of the NOAA web service.  This wasn’t particularly difficult to do.  Patching Axis was a bit of a pain, and the code generated by WSDL2Java tool was mostly implemented….but not completely implemented.  I copied the generated code for the client stub to the source folder of the web project and finished implementing the stubs in Eclipse.

Operation: getWeatherData

For reference I downloaded the NOAA SOAP WSDL to the file system and generated the client code using the following command:

C:\j2sdk1.5.0\bin\java -classpath %CLASSPATH% org.apache.axis.wsdl.WSDL2Java GeoCoder.wsdl

From the action diagrams that I modeled in the NOAAWeather project, Skyway Builder:

• generated to the web project all the Spring Beans representing the logic defined/modeled in the actions
• generated to the web project all the required Spring configuration files
• added the required entries to the web.xml
• added all the required libraries (Spring, Hibernate, etc…) to the web project

With Spring services implemented, the next step is to tie the Spring beans into Appcelerator which I’ll cover in part 4, where I will cover how this Spring services are made accessible as remote services to an Appcelerator-based web application.  Stay tuned!

<shameless-plug>Did you notice that I didn’t spend any time specifying anything related Spring?  This was all generated for me by Skyway Builder.  Clean and concise Spring code that’s blending effortlessly with java code originating from other sources (i.e. Axis) and Groovy scripting.  :-)</shameless-plug>

Here’s a list of my series of posts related to my Appcelerator/Spring/Skyway project:

* Part 1: Appcelerator RIA + Spring Services
* Part 2: Adding Appcelerator support to a web project
* Part 3: Spring Services and NOAA Web Service
* Part 4: Implementing Appcelerator Services using Spring
* Part 5: Building the Weather App with Appcelerator RIA

1. Introduction and Project Creation
2. Importing the Web Service
3. Creating the Web Layer
4. Appendix

Appendix

In case you are interested in checking out the SOAP request and response in the logs, you can easily do so by placing the following configuration in the config/WeatherProject_springconfig/web/jaxws/jaxws-web-context.xml file, inside the cxf:bus node:

<cxf:features>
       <cxf:logging/>
</cxf:features>

 

If you are interested, download a completed version of this application, OR if you would like more sophistication, like the SkyTower Omni HD Vipir, then check out our sample weather application. The sample weather application adds the following:
- Calls a second web service to retrieve the current conditions, and
- Makes use of exception handling around the web service calls.

And just for kicks, here are some fun Weatherman videos to check out :-)
- Cockroach versus WeathermanÂ
- Excited Weatherman
- Weatherman with green tie on green screen

Prev | 1: Intro | 2: Web Service | 3: UI | 4: Appendix

1. Introduction and Project Creation
2. Importing the Web Service
3. Creating the Web Layer
4. Appendix

Build the User Interface for the Web Service Read the rest of this entry »

1. Introduction and Project Creation
2. Importing the Web Service
3. Creating the Web Layer
4. Appendix

Import the Weather Web Service Read the rest of this entry »

This blog steps through the creation of a Skyway Project that makes use of a weather web service from CDYNE.  Skyway is a set of Eclipse plugins that provide modeling, generation, and deployment capabilities for building web services or web applications in the Spring 2.5 framework. The tutorial covers the following topics:
» Importing a Web Service into a Skyway Project
» Using Skyway to model, generate, and deploy a project that uses a Web Service
» Adding AJAX calls without writing javascript
» Implementing a loading animation technique for long running requests
» Using JSP EL syntax with Skyway variables

The blog is broken up into 4 parts.
1. Introduction and Project Creation
2. Importing the Web Service
3. Creating the Web Layer
4. Appendix

< :-) > Read the rest of this entry »