Multi-Agent Planning for Automatic Geospatial Web Service Composition in Geoportals

Abstract

Automatic composition of geospatial web services increases the possibility of taking full advantage of spatial data and processing capabilities that have been published over the internet. In this paper, a multi-agent artificial intelligence (AI) planning solution was proposed, which works within the geoportal architecture and enables the geoportal to compose semantically annotated Open Geospatial Consortium (OGC) Web Services based on users’ requirements. In this solution, the registered Catalogue Service for Web (CSW) services in the geoportal along with a composition coordinator component interact together to synthesize Open Geospatial Consortium Web Services (OWSs) and generate the composition workflow. A prototype geoportal was developed, a case study of evacuation sheltering was implemented to illustrate the functionality of the algorithm, and a simulation environment, including one hundred simulated OWSs and five CSW services, was used to test the performance of the solution in a more complex circumstance. The prototype geoportal was able to generate the composite web service, based on the requested goals of the user. Additionally, in the simulation environment, while the execution time of the composition with two CSW service nodes was 20 s, the addition of new CSW nodes reduced the composition time exponentially, so that with five CSW nodes the execution time reduced to 0.3 s. Results showed that due to the utilization of the computational power of CSW services, the solution was fast, horizontally scalable, and less vulnerable to the exponential growth in the search space of the AI planning problem.

1. Introduction

During the last decade, an enormous amount of spatial information and processing capabilities have been published over the internet. To meet the interoperability of the systems, Open Geospatial Consortium Web Services (OWS) have been used as the underlying technology. The need to integrate atomic OWS nodes into complex workflows is an important milestone on the path to fully benefit from published spatial data and functionality over the internet. This integration of OWSs, known as web service composition, provides the geospatial community with a flexible opportunity to address more complicated analytical requirements using distributed spatial information and knowledge organization systems.

Web service composition is defined as the process of creating web service chains and establishing new functionalities by composing a collection of web services [1]. Web service composition aims to arrange several web services into one complex service to achieve complex objectives [2,3,4].

Discovery and selection of proper OWSs and combining them into a new composite web service is a complex and time-consuming task, which requires experts with different proficiencies to handle it manually. Automatic generation of composite OWSs is a promising alternative that can significantly reduce the complexity of integrating OWSs. Using the automatic composition techniques, users formalize their requirements as a goal and send it to a composer component. The composer component utilizes the syntactic and semantic description of OWSs to generate a new workflow to address the user’s goal.

A few researchers in the geospatial community, including Yue et al. [5], Cruz et al. [6], Farnaghi and Mansourian [7], Farnaghi and Mansourian [8], and Al-Areqi et al. [9] have tried to solve the problem of automatic composition of OWSs. The overall approach in their studies was to semantically or syntactically describe specific characteristics of OWSs, and then exploit centralized artificial intelligence (AI) planning techniques [10] to generate an execution workflow from atomic OWSs. However, this approach encounters two critical challenges: Incompatibility with the distributed architecture of geoportals and exponential growth of the search space.

The first challenge is that centralized AI planning techniques, which have been used in previous studies for automatic composition of OWSs, are not compatible with the distributed architecture of geoportals [11,12], which have been developed and used over the last fifteen years in the geospatial community for the search and discovery of spatial data and OWSs. Based on the standard architecture of geoportals, OWSs are registered in Catalogue Service for Web (CSW) services [12]. Using the geoportal interface, users can specify the characteristics of their desired geospatial data or services. The geoportal then executes a distributed search over the registered CSW services and matching results are presented to the user. However, it is a challenging task to use a centralized planning technique for automatic composition in geoportals. The critical point is that, to be able to solve the composition problem, the centralized AI planning techniques require accessing all available OWSs simultaneously. Nevertheless, in geoportals, OWSs are registered in CSW services. To solve this problem, one may send a loose search condition to every CSW service, retrieve required information about all available OWSs from every CSW service, and then try to solve the composition problem on a single computational node. However, retrieving all available OWSs and trying to solve an AI planning problem with a massive amount of OWSs leads to a second challenge of the exponential growth of the search space as follows.

Although the AI planning techniques have proved to be the most promising solution for automatic composition of web services (see Reference [13] for a detailed comparison of web service composition techniques) and hence the automatic composition of OWSs, they still encounter serious problems in terms of dealing with real-world scenarios. Considering the huge amount of published OWSs over the internet, centralized AI planning techniques in which a planner agent is responsible for solving the whole planning problem alone, are not efficient and feasible. That’s mainly because, as the number of available OWSs increases, the search space of the AI planning grows exponentially (see References [14,15,16]). Therefore, in real-world scenarios the centralized planning techniques are not able to solve the automatic composition problem in an acceptable time.

To address these two mentioned problems, this article presents a novel solution for automatic composition of OWSs. The solution proposes a new multi-agent artificial intelligence (AI) planning algorithm in which OWSs are semantically annotated and registered in CSW services (Catalogue Service for Web, [12]). The CSW services are considered as agents that work in a multi-agent system. Unlike the centralized algorithms, the proposed algorithm utilizes the computational powers of the distributed CSW services to solve the composition problem collaboratively. The solution is an extension to the distributed architecture of geoportals [17,18,19]. In addition to being fast and scalable, this solution is expected to be less vulnerable to the exponential growth in the search space of the composition problem. The feasibility of the algorithm is demonstrated using a case study and a simulated testbed of one hundred OWSs.

The remainder of this article is organized as follows. In Section 2, related studies on the automatic composition of OWSs and other web service types are described, and current challenges in automatic web service composition are highlighted. The proposed solution for automatic composition of OWSs is thoroughly described in Section 3. Section 4 is dedicated to implementation and demonstration of the results. Finally, Section 5 provides a discussion and Section 6 concludes the paper.

2. Related Studies

In the geospatial community, most studies have been concentrated on the manual or semi-automatic composition of OWSs (see References [20,21,22,23,24,25,26,27,28]). However, automatic generation of composite OWSs has received significant attention in recent years. Yue et al. [5] have utilized a HTN (Hierarchical Task Network) planning technique to generate composite geospatial web services out of semantically described OWSs. OWL-S (Semantic Markup for Web Services, [29]) was used as an underlying technology to describe semantic aspects of OWSs. In another study, Cruz, Monteiro, and Santos [6] presented a solution for the automatic composition of OWSs based on geodata quality. The OWSs were semantically described by OWL-S and a backward planning algorithm was used to generate the composite web service. Farnaghi and Mansourian [7] reported a study in which OWSs were semantically described by a WSMO (Web Service Modeling Ontology, [30]) framework, and the composition process was conducted using the Graphplan algorithm. In another study, Farnaghi and Mansourian [8] proposed a comprehensive method for annotating OWSs using SAWSDL and WSMO-Lite (Lightweight Semantic Descriptions for Services on the Web, [31]), and then used a planning algorithm to generate composite OWSs. Du et al. [32] presented an architecture for the model-driven composition of OWSs, where the quality of service (QoS) was considered as an affecting factor. Al-Areqi, Lamprecht, and Margaria [9] reported a constraint-driven composition solution based on a web service modeling tool called PROPHETS. The tool synthesizes web services based on a search algorithm by evaluating constraints defined in SLTL (Semantic Linear Time Logic). However, to the best of the authors’ knowledge, none of the proposed solutions for automatic composition of OWSs in the geospatial community were compatible with the distributed architecture of geoportals. Instead, they are centralized and do not have any solution for dealing with the huge amount of OWSs published over the internet.

In the information technology community, few studies have used multi-agent systems for the automatic composition of web services to overcome the above-mentioned issue. Vaithiyanathan and Govindharajan [33] proposed a system in which two agents cooperated with each other to generate composite W3C (World Wide Web Consortium) web services. However, in their system, the composition is done by one of the agents and the other agent is just responsible for the search and discovery of available web services. Therefore, the processing overload of the web service composition is not delegated to multiple agents. In two other studies, Küngas and Matskin [34] and Charif and Sabouret [35] separately developed multi-agent systems to enable dynamic composition and execution of W3C web services. Their systems were designed to dynamically execute the composition, which meant that the output compositions were not registered in an orchestration engine, and hence were not reusable in future. El Falou et al. [15] presented a distributed, multi-agent algorithm for automatic generation of composite W3C web services. They utilized a multi-agent AI planning algorithm to generate the composition. However, they focused on the syntactic aspects of W3C web services, and semantic description of web services was not used in the composition algorithms. These studies in the information technology community do not conform to the standards of OWSs that are generally accepted in GIS communities, and therefore cannot be used for automatic composition of OWSs.

3. Method

The conventional geoportals, based on the OGC (Open Geospatial Consortium) geoportal architecture [11,36], leave users alone when there is no geospatial data or service that can satisfy the users’ requirements [37]. To improve the functionality of the conventional geoportals with the ability to automatically compose OWSs, this study proposes a solution based on multi-agent AI planning techniques. Multi-agent AI planning is a coordination mechanism [38,39,40,41] wherein to coordinate agents’ actions and avoid conflicts, a plan consisting of actions of all participating agents is generated, so that execution of that plan leads to the satisfaction of the global goal of the system along with the personal goal of every agent (for a detailed review of multi-agent AI planning techniques see Reference [41]). The proposed solution in this study considers a geoportal as a collection of agents that are working together with the same goal of satisfying the user’s need. Where the system cannot find a proper OWS to address a user’s need, it tries to generate a composite web service through the proposed multi-agent AI planning algorithm.

To thoroughly describe the proposed solution, the components of the system are briefly described, first, from an architectural point of view in Section 3.1. Then, the semantic annotation mechanism which has been adapted to describe different aspects of OWSs is reviewed in Section 3.2. To define a proper notation for an in-depth description of the proposed composition algorithm, a conceptual framework is defined afterward in Section 3.3. Finally, using the conceptual model, the AI planning algorithm is comprehensively elaborated in Section 3.4.

3.1. Architecture

With the purpose of adding the ability of automatic OWS composition to geoportals, this study suggested that three components of an OWS composition interface, an orchestration engine, and a composition coordinator component should be added to the typical architecture of geoportals (Figure 1). Additionally, the CSW services should be improved to be able to participate in the proposed multi-agent AI planning algorithm.

In the architecture depicted in Figure 1, like any conventional geoportal, OWSs are registered in CSW services. Using the search and discovery interface, users can specify the characteristics of the desired geospatial data or services. The interface then executes a distributed search through the CSW proxy component over the registered CSW services. If the search is successful, matching data and services are presented to the user through the search and discovery interface, and in some cases, the user can also visualize the output data or services on the map.

Where users cannot find proper data or service to satisfy their needs, they can use the composition capabilities of the system. Using the OWS composition interface, an expert user will be able to manually combine a list of selected OWSs, generate a composition, and register it into the orchestration engine, so that the new composite web service can be executed. This architecture also enables the user to generate composite OWSs automatically. In this regard, the user sends their requirements as a composition goal to the composition coordinator component. The composition coordinator component commences the proposed multi-agent AI planning algorithm (see Section 3.4) to automatically generate a composition that satisfies the user’s goal. The output composite web service is then registered in the orchestration engine as a new OWS.

3.2. Semantic Annotation of OWSs

Automatic generation of composite OWSs requires that a software component first locates the available OWSs and evaluates their characteristics. To address these requirements, the OWSs have to be described in a machine-readable and machine-understandable way [42]. This can be realized through a syntactic and semantic description of OWSs. While the OGC implementation specifications (see References [43,44,45,46,47]) address the syntactic aspects of OWSs, the semantic annotation can be used to provide the semantic description.

In this study, an approach based on WSDL (Web Service Definition Language), SAWSDL (Semantic Annotation for WSDL, [48]) and SPARQL (pronounced "sparkle", a recursive acronym for SPARQL Protocol and RDF Query Language) [49], proposed by Farnaghi and Mansourian [8], was adapted for semantic annotation of OWSs. Contrary to comprehensive and demanding top-down approaches like OWL-S [50], SWSF [51], and WSMO [30], which assume the semantic description of a web service is developed in parallel with the web service itself, the selected semantic annotation approach is bottom-up, light-weight, and agile. Therefore, it is well suited for semantic annotation of available services that are already implemented syntactically [8].

Based on the semantic annotation approach (Figure 2), the capability document of an OWS is supported by a WSDL document, where service, interface, operations, and types of the OWS are annotated through links to their respective semantic concepts, and lowering and lifting transformations using SAWSDL. SAWSDL is a W3C recommendation standard, which supports adding semantic annotations to WSDL documents. Using SAWSDL, the service element in the WSDL points to ontological concepts in non-functional ontology and OWS classification ontology. The operations in the WSDL document are marked by operation types in OWS classification ontology. Additionally, the conditions upon which an operation can be executed and the information that will be added after execution of the operation are defined by SPARQL [49] ask and update queries (see Section 3.3) as condition and effect, respectively, and linked to the operation. The SPARQL queries are defined based on the service ontology. The types that are used in the definition of operations in the WSDL document are also annotated by ontological concepts defined in service ontology.

The conversion between the semantic and syntactic representation of each type is defined using lowering and lifting transformations. Elements of service ontology, OWS classification ontology, and non-functional ontology are all defined based on classes and properties from WSMO-Lite ontology [31] and WSMO-Lite Extension ontology (for definition of condition, effect, functional classification, and non-functional parameter); GML Coverage Profile ontology and GML Simple Feature Profile ontology (for definition of geographical concepts, e.g., point, polyline, polygon, etc.); and COSMO (COmmon Semantic Model, available at http://micra.com/COSMO/COSMO.owl) top-level ontology and COSMO Extension ontology (for refereeing to real-world objects and phenomena, e.g., river, mountain, land, etc.). The COSMO ontology was selected due to its ability to provide broad semantic interoperability by integrating concepts from other foundation ontologies including OpenCyc, SUMO, DOLCE, and BFO. MSO and OntoMap are the two other foundation ontologies that could have been used in this sense.

3.3. A Conceptual Model for Automatic Composition of OWSs

To formally describe the proposed automatic composition algorithm, a conceptual model is presented that defines different roles of the participating elements of the algorithm. The model utilizes RDF (Resource Description Framework) language for representation of states in AI planning and SPARQL ask and update queries for condition checking and state transitions. The conceptual model supposes that several OWSs are registered in each CSW service. Each OWS is semantically annotated (see Section 3.2) and CSW services are accessible by the composition coordinator component. The formal representation of the model is as follows.

• $R=\left[r_0, r_1, r_2, \dots \right]$ is a set of possible states. Each state $r_i\in R$ is represented as an RDF graph.
• $q$ is a SPARQL ask query composed of one or more triple patterns that are connected by conjunction and disjunction operators.
• $\zeta \left(q,r\right)$ receives a SPARQL ask query, $q$, and an RDF graph representing a particular state, $r$. This function executes $q$ on $r$ and returns $true$ if there exists at least a match for the query $q$ in the graph $r$ and $false$ if there is not.
• $\epsilon \left(u, r\right)$ executes a SPARQL update operation, $u$, on an RDF graph representing a particular state, $r$, and returns the updated RDF graph, representing the new state.
• $r_0\in R$ is the initial state.
• $g$ is a SPARQL ask query that represents the composition goal.
• $CNF\left(q\right)$ is a function that converts a SPARQL ask query, $q$, to a conjunctive normal form (CNF) (see References [52,53]), where the query is represented as a conjunction of triple patterns.
• $a$ is an operation of an OWS service. Since OWSs are semantically annotated, each operation is defined as $a=\left[condition, effect\right]$.

  ⚬

  $a.condition$, is a SPARQL ask query that determines whether $a$ is applicable to a particular state.

  ⚬

  $a.effect$, is a SPARQL update query that inserts some triples to the RDF graph of the underlying state. The added triples describe the information that will be added after the execution of the operation.

• Given an operation $a$, and a state, $r\in R$, $a$ is applicable to $r$ if $\zeta \left(a.condition, r\right)$ returns $true$. Applying $a$ on $r$ will be done by the execution of $a.effect$ on $r$ and will result in a new state $r_{new}= \epsilon \left(a.effect,r\right)$.
• $\pi =A^1\succ A^2\succ \dots \succ A^k|A^i=\left\{a_1,\dots ,a_{ni}\right\}$ is a partial-ordered plan, represented as an ordered sequence of sets of OWSs operations. Each set is composed of OWS operations.
• $\mathrm{E}\left(\pi ,r\right)$ executes a partial-ordered plan, $\pi$, on a particular state, $r$, and generates a result state. $\pi$ can be executed on $r$ if all operations in its first set are applicable to $r$. Execution starts from the first set. All operations in the first set are executed on $r$ using $\epsilon \left(a.effect, r\right)$ and a result state is generated. Then the operations of the second set are executed on the result state of the first set. This sequetional execution of operations of a set on the result state of the previous set continues to the last set in $\pi$. $\pi$ is a valid partial-ordered plan, if every operation in each set is executable on the result state of the previous set.
• Solving the automatic composition problem is to find a valid partial-ordered plan, where its execution on the initial state, $r_0$, results in a final state, $r_f$, so that the goal, $g$, is satisfied and $\zeta \left(g, r_f\right)=true$.
• $cc$ is the composition coordinator component. This component implements the following methods:

  ⚬

  $GenerateMultiAgentPlan\left(r, g\right)$ receives an initial state, $r$, a goal, $g$, and returns a valid partial-ordered plan, if there is any, as the result of the multi-agent AI planning algorithm.

  ⚬

  $GetRegisteredCswAgents()$ returns the list of registered CSW services as $\left[C{A}^1, C{A}^2, \dots \right]$.

• $C{A}^i$ is a CSW service, which in addition to the standard operations of CSW services [12] implements the following methods:

  ⚬

  $GetRegisteredOWSOperators()$ returns a list of every operation of OWSs which are registered in $C{A}^i$ in the form of $A^i=\left[a_1^i, a_2^i, \dots \right]$. These operations are considered as actions of the AI planning model.

  ⚬

  $GenerateExecutablePartialOrderedPlans\left(r_c\right)$ is a method that receives a state, $r_c$, and the goal, $g$, and tries to find every possible executable partial-ordered plan composed of the operations in $A^i$ and are executable on $r_c$.

Based on this conceptual model, Section 3.4 describes the automatic composition algorithm.

3.4. Automatic Composition Algorithm

The proposed algorithm is a distributed descendant of A* heuristic search algorithm. As a generic, best-first search algorithm, A* tries to solve a problem by searching among all possible paths to the goal, where the search is guided through a heuristic function that calculates cost of every path in the graph and forces the algorithm to pursue the path with minimum cost that appears to lead most quickly to the goal.

The proposed algorithm perceives the composition as a pathfinding problem in a graph, where states are the nodes and partial-ordered plans are the links. The algorithm runs in a multi-agent environment where a composition coordinator component directs the search within the graph, and multiple CSW agents are responsible for expanding the search graph. None of the agents has complete knowledge of the search space, each CSW agent only knows the operations of their OWSs, and the composition coordinator agent has no knowledge of OWSs registered in the CSW services.

3.4.1. Composition Coordinator Component

The automatic composition algorithm starts when the Generate Multi Agent Plan method of the composition coordinator component is called. Figure 3 shows the corresponding pseudo code. The algorithm receives the initial state $r_0$, and the composition goal, $g$, as inputs, and tries to generate a plan that can satisfy $g$. The composition coordinator component first retrieves the list of all registered CSW services by calling the $Get Registered Csw Agents$ method. Then it generates an initial search node $initNode$, with an empty plan, state $r_0$, and infinitive cost. It creates an open set $openSet$, which will contain the search nodes that have not yet been expanded, and a closed set, $closedSet$, which includes all the search nodes that have been recently expanded (lines 1 to 5, Figure 3). In this step, the open set only includes the initial state and the closed set is empty. The algorithm starts a loop which continues whilst the open set is not empty (lines 6 to 24, Figure 3). Within the loop, the algorithm first calculates the cost for every node in the open set using $f\left(node, g\right)=c\left(node\right)+h\left(node, g\right)$, where:

• $c\left(node\right)$ calculates the cost of reaching from the initial state to a state of interest, $node.State$. In the composition, it is expected to reach the goal state by applying a minimum number of OWS operations. To model this condition, in Equation (1), Sigmoid function is applied on the number of operations that compose the plan of the node. Sigmoid function was used, so that the output value is between 0 and 1.
• $h\left(node, g\right)$ is a heuristic function that estimates the cost to go from $node.State$ to the goal state, $g$. When the state of a search node has satisfied more RDF triples in the SPARQL ask query of the goal, it is more likely that expansion of that node will lead the algorithm to the final state. Therefore, Equation (2) counts the number of triples in the CNF form of $g$ that are not satisfied in $node.State$ and divide it by the total number of triples in the CNF form of $g$.

  $$c\left(node\right)=\frac{1}{1+e^{-\left(\#operationsinnode.Plan-x_0\right)}}$$

  (1)

  $$h\left(node,g\right)=\frac{\#triplesofCNF\left(g\right)notsatisfiedbystatenode.State}{\#triplesofCNF\left(g\right)}$$

  (2)

The output of the cost function is a value between 0 and 2, and nodes with lower costs are more likely to lead to the final state. Having the costs, the node with minimum cost in the open set is considered as the current search node (lines 7 to 9, Figure 3). If the current node satisfies the goal condition, the plan of that node is chained with the plans of its successive parents, a deordering algorithm (Figure 4) [54] is applied on the resulting plan, and the resulting plan is returned as the composition plan (lines 10 to 14, Figure 3). The deordering algorithm tries to move data retrieval operations which do not rely on the execution of the previous operations, to the initial steps of a partial-ordered plan.

If the current node does not satisfy the goal, the current node is supposed to be expanded by the CSW services. First, the current node is removed from the open set and added to the closed set. Then the partial-ordered plans, which are executable on the state of the current node $current.State$, are generated by each CSW agent through calling the $GenerateExecutablePartialOrderedPlans$ method. Having the partial-ordered plans, the current node is expanded, and new search nodes are created and added to the open set (lines 16 to 24, Figure 3). To expand the current node using an executable partial-ordered plan, the received plan $\pi$, is applied on the state of the current node, $current.State$. The result state $r$, along with $\pi$ are used to create a new search node, $newNode$, which is added to the open set afterwards (lines 21 to 24, Figure 3). This best node selection, condition checking, and expansion mechanism continuous till the goal state is reached or there is no search node for expansion in the open set. Figure 5 figuratively shows a simplified execution of the algorithm, where two CSW agents work with a composition coordinator to expand the search graph and find the composition plan.

3.4.2. CSW Component

To be able to work in the proposed multi-agent AI planning algorithm, a CSW service has to provide a $GenerateExecutablePartialOrderedPlans$ method. The method receives a current state $r_c$, and returns a list of partial-ordered plans executable on $r_c$. The developed tree expansion algorithm is represented in Figure 6. Starting from $r_c$, the algorithm creates an initial node; an open set (with initial node as its only member); a closed set; and a list of executable partial-ordered plans (lines 2 to 6, Figure 6). While the open set is not empty, the algorithm randomly selects a current node from the open set, removes the current node from the open set, and then adds it the closed set (lines 8 to 11). The operations that are applicable to the state of the current node and do not exist in the plan of the current node are selected afterwards (lines 12 to 16, Figure 6). Having a list of applicable operations, the current node is expanded by the applicable operations and the new nodes are added to the list of executable partial-ordered plans (lines 17 to 23, Figure 6). Finally, the algorithm returns the list of executable partial-ordered plans to the composition coordinator.

4. Implementation

The proposed multi-agent AI planning algorithm for automatic composition of OWSs was developed and implemented in this study. The composition coordinator component and the CSW service have been written in Java programming language. The RDF handling functionalities along with the SPARQL 1.1 support have been provided through Apache Jena API. OWSs have been implemented in GeoServer.

4.1. Case study: Site Selection for Sheltering

To demonstrate the applicability of the proposed solution, the problem of site selection for sheltering after an earthquake based on spatial data and processes, which are available online through OWSs, is selected as the case study. It is assumed that participating disaster management organizations have published their spatial data and functionalities through OWSs in two separate CSW services: Regional CSW of Tehran and National CSW of Iran SDI. These CSW services are registered in the geoportal of the Emergency Management Organization (EOC) of Tehran.

Table 1. CSW services along with registered OWSs.

CSW	Registered OGC Web Services
	Web Service	Organization	Type	Description
Regional CSW of Tehran	wfsMun	Tehran Municipality	WFS	This service presents the municipal data. Layers: Parcel, Park, Vacant Land, etc.
	wfsEOC	Emergency Operation Center (EOC) of Tehran	WPS	This service returns a polygon of affected areas with dense building damage. Layers: Affected_Area
	wpsEOC_EvacuationPlanning	Emergency Operation Center (EOC) of Tehran	WFS	This service handles the site selection processes. In the case of sheltering, it receives various input datasets and calculates suitable evacuation sheltering sites.
National CSW of Iran SDI	wfsFRW	Forest and Watershed Management Organization	WFS	This service presents the spatial data from the Forest and Watershed management organization. Layers: Forest_Park, Watershed, Land Cover, etc.
	wcsNCC	National Cartographic Center	WCS	This service presents the elevation data for the entire country as coverage data. Layers: DEM
	wpsNCCSurface	National Cartographic Center	WPS	This service performs all of the surface operations, including slope, aspect, contour, hillshade, and viewshed generation.
	wpsNCCCT	National Cartographic Center	WPS	This service performs coordinate transformations. It provides two processes: ProjectFeatureDataset and ProjectCoverageDataset.

shows each of the CSW services and the registered OWSs of the participating organizations.

Having access to the CSW services and the OWSs, a disaster management planner in the EOC of Tehran must be able to ask the composition coordinator agent to automatically generate a composite web service based on the atomic OWSs registered in the CSW services. The output web service must return polygon features with the following characteristics:

• The polygons can be vacant areas, parks, or forests.
• The area within the selected polygon features should be flat.
• The selected polygons should not be adjacent to damaged areas.

Considering the specified characteristics of the evacuation site, the disaster management planner sends their initial state and composition goal to the composition coordinator component. Figure 7 depicts the RDF graph of the initial state, which defines the bounding box of the study area and required spatial reference system. The SPARQL ask query that defines the user goal by expressing the characteristics of the desired output sites is shown in Figure 8. Figure 9 and Figure 10 represent the condition and effect of project feature operation of wpsNCCCT WPS (Web Processing Service) service (Table 1), respectively.

4.2. Planning Results

The composition coordinator component and both CSW services were implemented in a test environment (Figure 11 shows the initial settings of the execution environment). Providing the initial state and the composition goal of the case study as input arguments, the GenerateMultiAgentPlan method of the composition coordinator component was called.

The composition coordinator was able to find a valid plan after interaction with CSW agents. Figure 12 shows the resultant plan.

4.3. Translation to BPEL and Execution

The output plan was translated to an XML-based orchestration language called BPEL [55]. Using BPEL, the composite web service can be described and then an orchestration engine will able to execute the composite web service. In this study, the output plan was automatically translated into a BPEL process document. The BPEL document was registered in the Java Business Integration (JBI) runtime over the GlassFish server. The JBI runtime environment includes the BPEL Service Engine, which provides functionalities for executing BPEL processes. The JBI environment presents the composite OWS as a web service. Providing the required inputs, the web service was executed and returned appropriate sites for sheltering.

4.4. Performance Demonstration

Since the number of available OWSs in the case study was limited and there was no testbed of semantically described OWSs in the geomatics community, a service simulator program was developed that could produce computer-generated OWSs. Using the simulated OWSs the feasibility of the proposed multi-agent planning algorithm in dealing with real-world, complex circumstances was tested. The goal of the test was to demonstrate how adding new CSW services to the geoportal could increase the performance of the composition generation process.

The service simulator program was developed so that it can generate OWSs, and then semantically annotate them based on predefined templates. A list of ninety-two tuples, each including the required information for generation of a simulated OWS was compiled. Each tuple contained a combination of information, including service type from OWS classification ontology, feature type from Geography Markup Language (GML) [56] ontology or GML-coverage profile ontology, class name from the fundamental ontology or the domain ontology, spatial reference identifier, and a random bounding box. The service simulator application looped through the list and by replacing the required information of each tuple, generated ninety-two OWSs.

The test process utilized the ninety-two simulated OWSs along with the eight OWSs of the case study as the testbed. A network of six virtual nodes with Ubuntu 16.04.3 operating systems on Oracle VirtualBox virtualization software, where each node had two gigabytes of RAM and two CPUs, were used so that on the first node the composition coordinator component was installed and on the five other nodes, five CSW services were deployed. The test started with the composition coordinator node and two CSW service nodes, where each CSW service had fifty OWSs registered in it. The initial state and the goal state of the case study were sent to the composition coordinator component and the execution time was saved. In the next step, another CSW service node was added, the one hundred OWSs were registered in the three CSW services and the execution time was saved. This process continued to the point all five CSW service nodes were used.

To account for unwanted effects from the background processing of the operating systems and the virtualization software, the test process was run 20 times. Figure 13 presents the execution results of the different settings of the CSW services for 20 iterations. For the combination of one coordinator node, two CSW services, and one hundred registered OWSs, on average, the system was able to solve the composition problem in 20 s, which is a reasonable time for a web services composition task. As the number of CSW nodes increased, the composition time of the system of one hundred OWSs reduced exponentially, so that for five CSW services the average execution time was 0.3 s. This reduction proved that by using the computational power of CSW services, the proposed distributed OWS composition solution horizontally scaled up by adding new nodes. Therefore, it is less vulnerable to the exponential growth of the search space and would be able to deal with complex problems of the real world.

5. Discussion

The proposed solution in this study was able to address the two critical challenges of the automatic composition of OWSs in geoportals mentioned in the introductory section. The algorithm is distributed and compatible with the distributed architecture of geoportals. It does not need to fetch the information about all registered OWSs in the CSW nodes to a central node and generate a vast search space. Instead, the computational powers of CSW nodes are exploited, so that with the help of a coordinator component, CSW nodes can collaboratively solve the composition problem. While the case-study showed that the system could solve the automatic composition problem in a real-world scenario, the performance demonstration in a simulation environment proved that by adding new CSW nodes to the geoportal, the performance of the algorithm increased exponentially, which meant that the system was horizontally scalable.

To apply the proposed solution in any geoportal, we need to add a composition coordinator component that implements the automatic composition algorithm (Section 3.4.1), and also force the CSW services that are registered in the geoportal to implement the $Generate Executable Partial Ordered Plans$ method and its underlying algorithm (Section 3.4.2), in addition to the standard methods of CSW. This additional method of CSW services can be considered as a possible extension to the CSW standard in future revisions or simply be provided through a standard WPS [46] interface. In this condition, the geoportal will be able to automatically compose the semantically annotated OWSs using the proposed solution. Meanwhile, a motivating resolution for widespread adoption of the proposed solution is to extend opensource geoportal software, e.g., GeoNetwork (https://geonetwork-opensource.org/), GeoNode (http://geonode.org/), pyCSW (http://pycsw.org/) and Deegree (https://www.deegree.org/), and add the required functionalities to them, so that they can be easily implemented in spatial data infrastructures. Among available opensource geoportal software, GeoNetwork seems to be more appropriate to be extended because it already has broad supports for working with SPARQL and RDF.

In the proposed solution, geospatial aspects of OWSs are semantically annotated using GML and GML-coverage profile ontology, and SPARQL is used as the query language. Meanwhile, GeoSPARQL [57] has been developed and commonly accepted in the geospatial community for handling semantic geospatial data. GeoSPARQL provides a framework for the semantic description of geospatial features based on GML and OGC Simple Feature [58] ontologies, along with a SPARQL query interface. With these in mind, a question may arise as to why GeoSPARQL were not used in this study? The proposed solution of this study works based on the update functionalities of SPARQL 1.1 Update Standard (see https://www.w3.org/TR/sparql11-update/ and Section 4.3 of the paper). At the time of writing this article, there was no semantic web engine that supported both GeoSPARQL and SPARQL 1.1 Update standard. Therefore, GeoSPARQL was not used for the definition of the conditions and effects of OWSs in the case study. However, as soon as the leading semantic web engines, e.g., Apache Jena, support GeoSPARQL, the developed system can be modified to work with GeoSPARQL. This is just a discussion about possible tools and does not influence the approach used in this study.

To evaluate the performance of a web service composition solution, researchers typically use a testbed of sample web services (see References [59,60,61]). However, in the geospatial community, there is no testbed of semantically annotated OWSs to be used for evaluation of the proposed composition methods. Owing to this limitation, other researchers, e.g., Yue et al. [5], Cruz, Monteiro, and Santos [6], Du et al. [32], Al-Areqi, Lamprecht, and Margaria [9], have proved the feasibility of their OWS composition solution using case studies with limited numbers of OWSs. However, there are still issues related to the test of the performance. To address these issues, in this study, a service simulator program was developed to simulate a testbed of 100 OWSs. The simulated services on six computational nodes were utilized to test the ability of the algorithm to deal with real-world circumstances. However, generation of a standard testbed of semantically annotated OWSs with thousands of OWSs seems to be necessary to be considered by the geospatial community. Such testbeds will provide the ability to benchmark and compare the performances of proposed OWS composition solutions in future.

Based on OGC Catalog Service Standard [36], CSW can be cascaded by other CSW services. Additionally, an OWS may be published through multiple CSW services. The complexity resulting from multiple access points to an OWS service and repetition of OWSs in CSW services, should be addressed in the future extension of the proposed solution. Utilization of a URI (Unified Resource Identifier) as a global identifier of OWSs as proposed in the linked data principals [62] can be an answer in this regard. Including the global identifier of OWSs in the partial-ordered plans that are communicated between the composition coordinator component and the CSW nodes, will help the CSW nodes to distinguish the same OWSs, and therefore avoid using OWSs that have already been added to the composition by other nodes.

The proposed algorithm in this study, was developed based on A* algorithm. Using a heuristic function to lead the search protects the algorithm from the explosion of the search space and expansion of the search tree in arbitrary directions. Using an open set containing all search nodes that have not yet been explored ensures the completeness of the algorithm. Nissim and Brafman [40] proved that a similar distributed A* algorithm was both complete and optimal.

The proposed algorithm does not use semantic similarity measures and semantic matching techniques to detect similar concepts, which have been defined with different terminologies. Addressing the requirement for similarity recognition in the composition process is an important issue that should be considered as another future work. Additionally, considering data quality and quality of service in the multi-agent AI planning algorithm is a future work for this research. This approach should also be implemented on a large-scale geoportal so that its pros and cons can be thoroughly evaluated.

6. Conclusions

This article presents a solution for automatic composition of OWSs. A multi-agent AI planning algorithm has been introduced which exploits the computational power of CSW services to generate composite web services out of atomic OWSs. The proposed solution delegates the processing overload of the web service composition to the CSW service nodes. The solution horizontally scales up by registering new CSW service nodes. Therefore, it is less vulnerable to the exponential growth of the search space of the AI planning algorithms. It is also an extension to the distributed architecture of geoportals, which has been widely exploited in the geospatial community, and is therefore an appropriate choice to be implemented and used in real-world scenarios.

To demonstrate the functionality of the proposed solution, a prototype system was developed. The system was used to solve geospatial web service composition problems in a case-study related to site selection for sheltering after an earthquake. In a collaboration among the components of the geoportal, including the CSW services, the geoportal was able to automatically generate the requested composition out of the OWSs which were registered in the CSW services. The performance of the solution was also tested in a simulation environment with one hundred OWSs and five CSW services. The test showed that the solution was fast and horizontally scalable, so that by adding new CSW services, the execution time reduced exponentially.

Implementation of the proposed solution in futuristic spatial data infrastructures and resource publishing environments, e.g., the European INSPIRE Geoportal or the NSDI Clearinghouse of the United States, can facilitate the process of dissemination, integration, and utilization of spatial data and functionality from various sources, which eventually leads to providing value-added services for users. Additionally, the proposed multi-agent algorithm can be used in cloud computing environments as a broker that helps consumers to compose the data and functionalities out of the pool of services provided by service providers.