SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 206 of 233
10.8. Cascading Sensor Observation Services
Sensor Observation Services SOS as specified in section 8.2.2 can be used at many different places in applications built according to the SensorSA. Cascading of sensor observation services
may sometimes be an effective approach for fulfilling certain requirements. When SOS instances are cascaded, an SOS acts as the data source for an intermediate cascading SOS, which itself
provides a SOS interface to its clients. From an architectural point of view, a number of scenarios of using a cascading SOS are of interest and thus described in the following.
10.8.1 Data flow optimization
While on a conceptual level data is directly accessible from the service provider or data source, when engineering real-world applications some obstacles can hinder efficient direct usage of an
SOS by a client. Problems that may occur include:
-
Network performance problems
-
Limited resources on SOS servers
-
Support of different versions or feature sets of the SOS protocol in the client and server applications
To mitigate those negative effects without the need of changing servers andor clients a cascading SOS can be used as an intermediate service for optimizing the data flow from the
server to the client. Depending on the problem that should be solved the cascading SOS has to provide different functions, which are described in the following.
For decoupling the data flow from the server to the client, caching can be implemented on the intermediate SOS service. This reduces negative effects of limited network bandwidth,
unreliable network connections, unreliable servers, or limited performance of the original SOS service.
When the implementation details of the SOS protocol e.g. use of different SOS versions, impose a problem on the interoperability between a specific client and a server, the most
straightforward solution would be to change either the client or the server application or both. If that is not possible or feasible for economic or other reasons, an intermediate SOS service can
be used to translate between the unmodified client and server, and make interoperability between these systems possible.
From a network point of view the intermediate SOS can be placed near the original SOS servers or near the clients that are supposed to use it. The most effective location depends on
the issues that are about to be solved in this specific application scenario and thus cannot be defined on a generic level.
10.8.2 Providing alternative views to data
When implementing applications according to the SensorSA situations may arise where using the data directly in the form provided by the data source may not be feasible or possible.
Examples for such scenarios are:
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 207 of 233
-
Different data providers may implement different data models for their Sensor Observation Services because of differences in their requirements andor intentions.
While this is still compliant with the SensorSA, it may impose an additional burden on applications that have to use those different data sources.
-
Data models used by organizations internally may not be feasible or appropriate for publishing them or making them available for a specific purpose.
-
Organisations may need to provide an aggregated view of data collected by different providers, e.g. for implementing federated data pools
Cascading SOS can be used to facilitate cleaner and more robust implementation architectures in these cases. The intermediate SOS server provides a single interface to all the
underlying data sources. This results in a clean distinction between the data access and processing on the client side, and the aggregation, transformation andor filtering of the data that
is necessary for a specific purpose in the intermediate SOS.
10.8.3 Data pre-processing
