 |
| High level architecture diagram showing interactions between components. |
The Soils to Satellite portal is the integration point. This portal is written using the Grails platform version 2.1 and makes use of:
- OpenLayers version 2.12 javascript mapping library
- JQuery version 1.7 javascript library
- Bootstrap version 2.2.1 front end development framework
This portal relies on web services from AEKOS and ALA. These services are predominantly JSON services and are stateless. Environmental layers are served from ALA using WMS via Geoserver.
The development of the portal is being achieved using the Intellij IDE.
One of the most important parts of the technology being used are the stateless of the web services and the fact we are favouring JSON as core output. This should hopefully promote re-use by external tools in addition to making consumption of the data from AEKOS and ALA straightforward for the Soils to Satellite portal. The choice of Grails as the core platform for the Soils to Satellite portal has the following benefits:
Development of a user-friendly interface which handles the complexity of ecological data. Presenting this data in a way that is navigable and simple for users to follow will also lead to user satisfaction.
The development of the portal is being achieved using the Intellij IDE.
One of the most important parts of the technology being used are the stateless of the web services and the fact we are favouring JSON as core output. This should hopefully promote re-use by external tools in addition to making consumption of the data from AEKOS and ALA straightforward for the Soils to Satellite portal. The choice of Grails as the core platform for the Soils to Satellite portal has the following benefits:
- Grails runs on the industry proven Java Virtual Machine platform
- It supports rapid application development
- Has a convention over configuration style
- Gives an out of the box recongisable structure to software projects with clear separation of Model, View and Controller.
Development of a user-friendly interface which handles the complexity of ecological data. Presenting this data in a way that is navigable and simple for users to follow will also lead to user satisfaction.
2 comments:
The use of JSON in this project seems to be the key technology... are there considerations that need to be made for good practice in passing JSON, especially given the data types and how best to architect the syntax for JSON in passing those datasets? Is there consideration for geoJSON?
Please do post more on this as it sounds very interesting in terms of innovating JSON.
Also is dependency on JSON like this a risk, if not, why? BTW I'm a big fan of JSON so more posts exclaiming the virtues as well as pitfalls in archtiecting multiple systems would be greatly appreciated to help feedback to other projects as well as future funding initiatives.
Hi David,
We use JSON primarily for a) web service calls to the AEKOS/AusPlots data store from the Soils2Sat portal, b) service calls from the Soils2Sat portal and the ALA Spatial Portal, and c) between the browser and the Soils2Sat server for loading dynamic/lazy loaded content on portal pages.
Although it seems like an integral component of the architecture, it is one that could be replaced by any other structured data representation (XML being the most likely candidate). Having said that, though, the schema free nature of JSON offers us a high degree of agility, which is especially important during the prototype/development phase of the project and as the service interface evolves. JSON also offers an efficiency and bandwidth advantage over XML, as it is less verbose, and is also somewhat human readable, allowing easy inspection for debugging purposes. This, along with the plethora of 3rd party libraries available for quickly and efficiently marshalling to/from JSON make it a good choice for the transmission of hierarchically structured data, at least until the service interface is finalised.
One risk introduced by using JSON, however, is that changes to the service contract cannot be automatically detected via schema validation, and therefore modifications to data structures need to be clearly communicated. In addition, XML schemas offer developers a reliable reference on how to format their payloads, whereas with JSON external developers must rely on API documentation, ideally including detailed examples, which may not remain accurate as changes are made. The Soils2Sat project addresses this risk by maintaining a Services Interface Specification document that describes each service, its input parameters and its expected output.
The Soils2Sat portal uses WMS service calls to render base and environmental layers in OpenLayers. Study Location markers are currently added as a dynamic layer using data retrieved from the AusPlots data store. At this stage the portal does not use geoJSON to do this, although it could – and it may prove advantageous to do this as an enhancement later, should the point layer be useful to other applications.
Regards David
Developer, Atlas of Living Australia
Post a Comment