## 4 Service-Oriented Architecture for PGIS
### Service Engine Layer  
The services engine is the core component in the architecture to aggregate and co-operate the services; it is a scheduler or planner of the services in the lifecycle of data processing. It should be noted that a service engine is a very complex system, and some topics (e.g., automatic services discovery and composition) are still open questions in the field. Therefore, this paper only introduces the functions of the main steps of the service engine in PGIS, which include task analysis, sensor plan, services discovery, services composition, and service chain execution.  
(1) Task analysis  
There is a semantic gap between the task requirements and services description. The purpose of task analysis is to build a connection between task semantics and services. In the proposed architecture, task analysis decomposes a complex task to several simple tasks and connects those tasks with  
Figure 8: An example of the OWL-S structure.  
different requirements based on the geospatial attributes, such as the temporal attributes, resolution attributes, and spectrum attributes for remote sensing images.  
(2) Sensor plan  
Sensor plan is a module mapping the tasks to the sensors and managing the sensors to finish the tasks. The function of sensor plan is to schedule and optimize sensors to implement the task. In SWE, sensor plan is a standard web service interface for requesting user-driven acquisitions and observations, to (re-)calibrate a sensor or to finish the task using the sensors [3].  
(3) Services discovery  
This step deals with finding suitable services to fill in the roles in the adaptation service chain. To achieve this task, a semantically rich description for the capabilities of each service is needed first. OWL-S, in combination with the domain ontology, is used to describe the services in this paper. Finding candidate services is based on the OWL-S description of the services, more specifically on the Service Profiles which states what a service does. Each of the roles in the service chain contains information about the required input and output parameter types and values of a manipulation step. Using the OWL-S service profiles, it is then possible to select candidate services that suit the necessary roles. The result of the selection process is a list of services matching the roles in the services chain. This process is repeated for every service chain until all roles in the list are filled with services.  
(4) Services composition  
Services composition is the process that chains small scale services to complex services, _i.e._, using the GISC to implement user's complicated tasks. In the proposed architecture, the GISC is represented using a straightforward action-driven model consisting of operations and data objects. Data objects model the changes of data attributes after each service process. A reasoning system is used to derive a service chain from a set of attributes of the source data during the design stage.  
(5) Service chain execution  
After the services composition, the service chain has to be combined and executed, which is the GISC execution. GISC execution is an optimization procedure according to QoS property of services [35]. An important issue in GISC execution is monitoring and recovering after failures, especially for detecting and replacing failing services, in which the correct behavior of services prior or later in the chain is essential.