Version 2 (modified by spascoe, 12 years ago) (diff)


Client interactions and service chaining

A system is conceivable that allows all OWS interactions to be done between an AJAX application on the user's browser and an NDGDataServices component without the need for any service chaining.

However there are several drawbacks to this design.

  1. Complexity of the AJAX client. The configuration code to translate WFS responses into GUI widgets and requests to the other services would be very complex. Experience with the IPCC DDC suggests this code is much easier to implement on the web-application server.
  1. Cross-site scripting issues. Although more than one NDGDataService could be involved, all components would need to be in the same domain to avoid browser security restrictions (WMS is an exception to this since it only serves images). This would prevent overlaying datasets from multiple data providers.
  1. Publication quality overlays. Even if all components are in the same domain a WPSv could only combine data from one NDGDataService without some form of service chaining.
  1. Heavyweight data servers. This design combines all OWS services into one server (NDGDataService). If we wanted to install a CSMLDataService directly on NAS boxes this might be a system administration nightmare. Also it isn't very modular.

An alternative would be to implement a middle-man service (DataAggregator?) that brings selected data together. This service would be like a cross between the server portions of DataExtractor/GeoSplat? and the BADC /requests system. The WPSv service would be extended to support chaining of WPSa requests on other CSMLDataServices and store the resulting CSMLBundles locally (WPSv+a).

Several variations on this design are possible. E.g. move the WMS to the DataAggregator? or removing WPSa and combining the Store and DataAggragator?.