A Climate Database Web Service: 1st Review

The first week before the break I spent some efforts to integrate my software development project into NIWA’s software development process and environment. So it is ensured that once I have finished the eResearch project, the software can be maintained by NIWA staff afterwards. They also provide an elegant and robust development environment with the Eclipse IDE, source code revision management (Subversion), continuous integration (Jenkins) and testing. This shall ensure software quality and functionality being checked automatically with every code commit for everything that is developed within the research institute. 

In the first week I also had a very comprehensive interview with the software development team leader. He explained the information “ecosystem” and we drew a picture, where and how my project will be integrated and I also explained the software concept in terms of data modeling and data delivery through the web service (Fig 1).

NIWA whiteboard, discussion information ecosystem

Figure 1: The big picture

 

In my second week (I started on 7th already) I actually got my hands on the code. My project is actually two-fold: 

I am using 52North SOS server (4.0.0 dev), an open source software implementation, where I will customise the original database layer to source data from the already existing NIWA climate database. This new version fully supports the latest Opengeospatial Consortium’s Sensor Observation Service standard specification (OGC SOS 2.0). 

 Secondly, I will “backport” the SOS 1.0.0 specification for the 52N SOS server, as many legacy clients still only support SOS 1.0.0. This will be streamed back to the Open Source Community. 

I analysed the architecture and the data flow in the software. The 52N SOS server support GET (KVP – key-value-pair), POST (POX plain old XML) and POST/SOAP requests and the request decoders and response encoders are implemented through Java ServiceLoaders. This Java spec is already natively included since Java 1.6 and supports dynamic loading of additional classes through their generic interfaces. And I will use those to add de- and encoders for SOS 1.0.0 XML queries. In the next blog entry I will describe the SOS standards and how the geo-spatial web services work in general a bit more detailed.

Status (end of 2nd week):

  • build environment in place (incl svn, Jenkins and test deployments eg for internal staff testing)
  • software architecture and data flow analysed
  • preliminary request decoding and output for the GetCapabilities and DescribeSensor requests

Goals for this week (3rd week):

  • start request decoding for GetObservation
  • start response encoding for GetObservation (O&M 1.0 and GML3)
  • discuss automated unit testing (JUnit) and functional testing (Selenium?, Schematron rules?) with 52North open source group and NIWA development team

Overall Milestones:

  • M1) understand 52North SOS server - check :-)
  • M2) learn and implement SOS 1.0.0 spec for 52North SOS server - started (tbd week 5)
  • M3) implement/integrate NIWA climate database backend in 52North SOS server (tbd week 8)
  • M4) demo web-client and/or authorisation concept (tbd week 9) 
  • M5) last testing, review documentation and tidy up (tbd week 10)

AttachmentSize
Image icon niwa-whiteboard1.jpg237.8 KB
Submitted by AlexKmoch on