Integration into Web Services

7.4.2 Integration into Web Services

Becuase of the fact that a simulator does not differ from a sensor with respect to the provision of spatio-temporal data it only differs in the way in which it estimates the requested value and its virtually temporal independence, it is allowed to use simulators instead of sensors. Two different scenarios can be distinguished. In the first case, the simulator is continuously running, independently of the user. It is started, parametrized and maintained by the data provider and has no interface to the user other than at the point of data access. These simulators are e.g. a weather forcast that provide values for the parameters temperature, precipitation and wind speed, or air or water quality assessments. It is even possible that a user will not even notice that the provided data results from calculations rather than from real measurements e.g. if the values are interpolated from a wide-ranging measuring network. Those simulators will be encapsulated by a simple datastore that is accessible using a Sensor Collection Service. It can be handled purely synchronously and follows the service trading publish – subscribe – bind paradigm. In the second case, a simple encapsulation is insufficient. All observations or even simulations that require preceding feasibility studies, complex control and management activities, or intermediate andor subsequent user notifications, can not be handled synchronously anymore, but become heavily asynchronous. In this second case the service interactions become much more complex. A list of services will become necessary. The SPS handles the main part of the simulation. The SPS provides interfaces that allow requesting a simulation run, feeding the necessary parameters to the simulator and to start the simulation run. Sensor Planning Services as facades for simulation models are the first step within the integration process of simulators into web services. Currently, a rather tight coupling is unavoidable. This situation will be improved when the first generic simulation interfaces become available, providing simulation management that is independent of the underlying simulation system. 8 Transactions The Sensor Planning Service interface facades often complex asset management systems that do not provide an immediate response to GetFeasibility request operations as the asset has to be analysed first. This might be a time consuming task. In other cases wants a client to task an asset and wants to be informed in the moment the data is available for retrieval. Either case, we have to deal with long term transactions that require the implementation of an asynchronous interaction pattern. Assuming that the application level of the OSI protocol stack is where HTTP resides, then there are conceptually three additional protocol layers or perhaps they should be called application level sublayers in the SPS transaction model. 28 Copyright © 2007 Open Geospatial Consortium, Inc. All Rights Reserved. HTTP, FTP, SMTP, Messaging Operation Layer Transaction Layer Collaboration Layer HTTP, FTP, SMTP, Messaging Operation Layer Transaction Layer Collaboration Layer Client Service Provider Figure 3: Protocol layers The operation layer uses the basic application layer protocol – HTTP, for example – to implement the request response pairs that form the OGC operations such as are used in the GetMap or GetFeature interfaces of WMS or WFS. The transaction layer uses the operations in the operation layer to implement long-term or advanced transactions. At the collaboration layer transactions are choreographed into collaborations. An example of a transaction is the interaction which takes place when a request for information is submitted through a SPS, and is retrieved committed through some other service; then a third service provides the notification that the results are ready. An example of a collaboration is the interaction which takes place between a client, a registry, and a service during the publish, find, and bind sequence. Another example of a collaboration is the interaction between a transaction which returns a schema, and the transaction that uses that schema to formulate a query. In both of these cases it is principally the client software that maintains the state of the collaboration. For the SPS, there is an important collaboration between the DescribeTaskingRequest operation and the Submit transaction.

8.1 Short Term Transactions