Home Articles Distributed Computing Architecture based on Geo Services; A Loosely Coupled Method for...

Distributed Computing Architecture based on Geo Services; A Loosely Coupled Method for Linking GIS and Environmental Models

Gholamreza Fallahi
Surveying and Geomatic Eng. Faculty – K.N. Toosi University of Technology Tehran, Iran GIS Dept. – National Cartographic Center, Azadi Sq., Meraj St. Tehran, Iran
[email protected]

Most of the environmental problems do have an obvious spatial dimension. In this regard Geographic Information Systems (GIS) can be widely used in various environmental disciplines for solving environmental problems. Therefore linking GIS and environmental models is becoming common and interest in merging the technologies. Currently different methods are used for linking which are based on loosely or tightly coupled relationship between monolithic GIS and environmental models or integration of one of them into another or tightly coupled relationship between GIS and environmental models in a distributed computing architecture. These methods as isolated islands are no longer appropriate for heterogeneous environmental disciplines due to the fact that they are still discipline specific. They can not support a good communication in an interdisciplinary effort for solving environmental problems due to their lack of interoperability. The motivations for adopting new methods are derived from the essential needs of environmental modelers and promoting interoperability between GIS and modelers of environmental disciplines.

This paper will discuss about current methods of linking GIS and environmental models their advantages and drawbacks. Then it is discussed about distributed computing technology based on web services as well as the role of interoperability in communication. Standard protocols for deploying, discovering and invoking geo services are explained. Geo services can be classified into geo data services and geo data service due to the fact that geo data services are tightly coupled to geo data. We pay attention to geo data services and requirements for producing a map as a picture, answering basic queries about the content of the map, and telling other programs what maps it can produce and which of those can be queried further. Then, the architectural view for a web map server based on OGC implementation specification which practically implemented is presented.

1. Introduction
The environmental models do have an obvious spatio-temporal nature. They are occurred in a part of spatial region like surface and subsurface water flow, soil erosion, impact assessment in the event of a chemical and/or oil spill or urban extend. Thus environmental modelers encourage using GIS for describing the models of how environment changes (e.g., models of erosion, flooding, vegetation growth and changes, urbanization).

Currently different approaches have been used to link GIS with environmental models. According to Goodchild these approaches can be classified to full integrate (embedding), loose coupling and close or tight coupling [Goodchild, 2000].

A variety of environmental disciplines have entered the modeling arena and a broad range of users belong to environmental disciplines are involved to exchange spatial data and operations. Thus close coupling and full integration approaches which lead to stand alone systems in which spatial data and operations are tightly coupled with environmental models, are not able to cover the needs of these broad ranges of user. These tightly coupled approaches are inflexible and cannot inherently take advantage of physical network and internet. These approaches suffer from the lack of interoperability.

Due to the popular use of the Internet and the dramatic progress of communications and telecommunications technology, the paradigm of linking GIS and environmental models is shifting into distributed computing technology with independently provided, specialized, interoperable geo services.

This paper presents the implementation of a web map server which provides the visualization of the physical fields for environmental modeler based on OGC (Open Geospatial Consortium) implementation specification. The structure of the paper is as follow:

In section 2 the related works about linking GIS and environmental models are briefly discussed. This section is followed by pointing to scientist’s conceptualization from environment. In section 3 we pay attention to new distributed GIS architecture which is based on web services, due to the fact that service oriented architecture is able to perform communication between experts and provide knowledge sharing between them. This section continues with explaining the role of interoperability in communication. In the next section the web service discovery and the protocols which are developed for deploying, discovering and invoking web services are introduced. In section 5, classification of geo services will be explained. We pay attention to geo data services and requirements for producing a map as a picture, answering basic queries about the content of the map, and telling other programs what maps it can produce and which of those can be queried further. In the next section, the development of an http server which can be used as a Web Map Services based on OGC implementation specification in order to prepare requirements for geo data services will be explained. This paper comes to the end with conclusion.

2. Background
There are two distinct conceptualization about the natural system called the object and field conceptualization [Couclelis, 1992; Smith and Mark, 2003].

Many scientists as environmental modelers conceptualize the world as fields. The field conceptualization assumes environment as continues space and involves apprehending reality in terms of distributions of properties (attributes) such as temperature, population density, pH of the soil, soil type or tree-coverage.

In the environmental modeling, when we model the environment, we concentrate on a set of states which describe the conditions of natural system under study [Casti, 1989]. Each state can be observed and measured in each location and according to the measurement a value can be associated to it and represented by a number. These numbers which can be classified into ration, interval, ordinal and nominal scale may describe soil type, land use type, elevation, distance of each location from a phenomenon, noise levels from an airport, radiation levels from a nuclear plant and so on. A wide range of geo operations can be performed on field data. These geo operations perform a mapping between new and old property values of physical fields.

Most of research works related to linking GIS and environmental models use one of the full integration, loose coupling and tight coupling methods in order to use geo operations in their environmental models. [e.g. Sydelko, et al, 2000, Fedra, 1996, Djokic, 1996]. The highest level of integration is an embedded system, one in which GIS and modeling functions are interwoven elements of a software system (or full integration). [Goodchild, 2000].

Two systems are considered loosely coupled if the only mandate imposed on both systems is to understand the self-describing, text-based messages. In loose coupling between two standalone systems, developer and the user are confronted with tedious batch conversion tasks, import/export obstacles, and distributed resource access barriers imposed by heterogeneous processing environments and heterogeneous data [Buehler and McKee, 1996].

Tightly coupled systems, on the other hand, impose a significant amount of customized overhead to enable communication and require a greater understanding between the systems. A disadvantage of many tight coupling approaches is the difficulty involved in modifying and integrating system components. The integration based on the existing closed and monolithic GIS and simulation models includes a high risk in designing systems, being again closed, monolithic, and therefore costly [Fedra 1996]. Since these systems are incorporating interfaces, programs and data. Every element is embedded inside GIS and can not be separated from the rest of the architecture. The problems resulting from tight coupling and full integration could be hindered by the facts that each method is unique to a model/GIS combination, modifying of integrated components are difficult.

In order to reduce the drawbacks of these methods it is needed to identify a new method which capable to share data and operations over a communicating environment between broad ranges of environmental disciplines involved in linking GIS and environmental models. In this regard, some research efforts focused on using open systems, object oriented method and framework to develop tools. They aim to link different behavior of environment in a domain [Bernard and Krüger, 2000, OpenMI_Newsletter, MDSF, Feng, 2000].

However, linking GIS and environmental models by using distributed computing technologies such as COM (Component Object Model), DCOM (Distributed Component Object Model), RMI (Remote Method Invocation) or CORBA (Common Object Request Broker Architecture) could lead to tightly coupled relationship between client and server. Due to tightly coupled relationship these technologies can not inherently take advantage of the existing World Wide Web [Newcomer, 2002]. The intelligence for understanding how to map a message into a software program is contained within the interface itself, which tightly couple the service name to the program being invoked.

Due to the popular use of the Internet and the dramatic progress of communications and telecommunications technology, the paradigm of linking GIS and environmental models is shifting into increasingly distributed computing architecture based on loosely coupled relationship between client and server. The loosely coupled interactions are better suited to integrating disparate software domains and bridging incompatible technologies. In regard to map overlay, a set of common interfaces perform the loose coupling interaction between different client and server for communicating a few basic commands/parameters. This set of interfaces is known as the OpenGIS Implementation Specification [OpenGIS], and includes the Web Map Server (WMS) interface implementation specification [Cookbook, 2003].

3. Distributed Computing Architecture Based on Web services
Web services are self-contained, self-describing, modular applications that can be published, located, and invoked across the Web. Web services perform functions, which can be anything from simple requests to complicated business processes. Once a Web service is deployed, other applications (and other Web services) can discover and invoke the deployed service [IBM’s tutorial].

A service is basically a software module that is accessed only through its interface, usually in request/reply manner [Natis, 2003]. The service interface must be described using an implementation-independent description language, so that all service requesters are able to inspect the interface (e.g. protocol bindings and transport details).

A service must be self-contained and perform a specific task, in such way that the client is not expected to know anything about the internal functionality of the service [Capeclear, 2005].

Web services make possible the exchange of data in the form of XML messages between heterogeneous systems. The only assumption made between the client and the server is that recipients will understand the messages they receive. In other words, the client and server agree to a contract and then communicate by generating messages that honor the contract over a specified transport like HTTP.

Fig 2 illustrates the interaction between service provider, service requester and service broker. The service requester invokes services which are provided by service provider and service broker enables the service requesters to dynamically find service providers or registry where services can be published or advertised. These can be performed through three activities including publish, find, and bind.

These activities can be fulfilled through the communication protocols. Thus establishing communication between service requester, service provider and service broker is basic requirement for interoperation between geo services. Interoperability has a basic role in communication. On the other words communication can be enhanced by promoting the interoperability between systems.

Fig. 2: the basic model of service interaction

3.1. Interoperability
Interoperability comprises intercommunication at communication level protocol, hardware, software, and data compatibility layers. The aforementioned might be called syntactic interoperability, in the sense of parameter passing.

Interoperability can be defined in a technical way as [https://en.wikipedia.org/wiki/Interoperability, ISO TC204, document N271]: The ability of systems, units, or forces to provide services to and accept services from other systems, units or forces and to use the services so exchanged to enable them to operate effectively together.

In the other words two components X and Y (e.g. modeler and Geo Services) can interoperate (are interoperable) if X can send requests R for services to Y, based on a mutual understanding of R by X and Y, and if Y can similarly return mutually understandable responses S to X (see Fig. 7) [Bordie, 1992].

Fig. 7: the diagram illustrate the interoperability between X and Y components.

Bishr discussed that there are six levels of interoperability in communication between two systems and semantic interoperability has the highest level [Bishr, 1998]. The modeler and geo services should be independent and yet can transparently communicate at the semantic level.

4. Fundamental Protocols for Deploying, Invoking and Discovering of Web Services
Key to the interoperation of Web services is an adoption of a set of enabling standard protocols. The Web service protocol stack is the collection of computer networking protocols that are used to find, define, implement, and make Web services interact with each other. The Web services stack consists of five layers, as it is illustrated in Fig. 3.

Fig. 3: The five-layer model of the Web services stack

These layers consist of the following elements:

4.1. Transport (HTTP)
At the lowest level, two components in a distributed architecture must agree on a common transport mechanism. Because of the near universal acceptance of port 80 as a less risky route through a firewall, HTTP became the standard for the transport layer.

4.2. Encoding (XML (eXtensible Markup Language))
The basic foundation on which Web services are built provides a language for defining data and how to process it. XML represents a family of related specifications published and maintained by the World Wide Web Consortium (W3C) and others.

4.3. Description (WSDL (Web Services Description Language))
WSDL is the key concept in developing, deploying and discovering Web services. According to W3C, WSDL defines service description about the message formats, data types, transport protocols, and transport serialization formats as a machine-process able specification of the Web service’s interface [W3C, 2004].

WSDL file sets up requirements including name, data types, methods and parameters for each exposed component. It is like a contract between the provider and the requester. WSDL describes the data types of the input-output variables, the name of the set of operations in each service, the format that the client must follow to invoke a service, and so on.

For example, a WSDL file defines an ESRI’s ArcWeb Service called mapImage ). This service describes operations such as getMaps, getSavedMap, and getValueMap. This file can be placed on the server. A requester who wants to send a request to the provider first obtains a copy of this WSDL file from the server. The requester then uses the information in this file to format a request. The requester sends this request to the server. The server executes the requested operation and sends the result back to the requester as a response.

In a WSDL file, there are five primary elements including types, messages, portTypes, binding and services. The element that describes the input and output messages for getValueMap operation in ImageMap service can be traced in the following segment of WSDL file. The input message is named getValueMap7In and the output message is named getValueMap7Out.


4.4. Standard Structure (SOAP (Simple Object Access Protocol))
To guarantee interoperability, both provider and requester must know what to send and what to expect. SOAP is a lightweight, message-based protocol to exchange information between nodes in a decentralized, networked environment built on XML and standard Internet protocols, such as HTTP. The SOAP protocol specification defines an XML structure for messages (the SOAP envelope), data type definitions, and a set of conventions that implement remote procedure calls and the format of any returned data (the SOAP body). As shown in Fig. 4, a SOAP message consists of header and body information.

Fig.4: SOAP Message

4.5. Discovery (UDDI (Universal Description, Discovery, and Integration)) Catalog service is a component in service oriented architecture to discover the types of service and data and their relevant instances. A catalog service plays a ‘directory’ role in helping providers to describe and advertise the resources availability and requestors to discover the right resources. UDDI provides three basic functions, popularly known as publish, find, and bind:

  • Publish: How the provider of a Web service registers itself.
  • Find: How an application finds a particular Web service.
  • Bind: How an application connects to, and interacts with, a Web service after it’s been found.

According to above explanations the relation between the elements of web service stack and service broker, service provider and service requester can be illustrated in Fig 5.

Fig.5: The basic model of service and the elements of Web services stack. https://en.wikipedia.org/wiki/Web_service

5. Geo-Services

According to definition from ISO 19119 geo-services can be defined as a collection of geo-operations, accessible through an interface [ISO, 2001]. For example The Environmental Easements web service contain geo operations such as GetCentroids returns the polygon centroid, LatLonExtentForOrtho returns the spatial extent for the orthophoto image in terms of latitude and longitude, GetEasementFromTerraServerArea returns polygon data for the easements within the extent of the TerraServer ortho image area and so on [Barclay et al, 2002].

The geo-services can be categorized into geo data services which are tightly coupled with specific data sets and offer access to customized portions of that data and geo operation services which provide operations for processing or transforming data in a manner determined by user-specified parameters.

One of the tasks which are needed by environmental modeler is to visualize geo data or physical fields which are represented by different maps or raster from multiple dissimilar servers. The OpenGIS Web Map Service Interface Implementation Specification offers a way to enable the visual overlay of complex and distributed geographic information maps simultaneously, over the Internet.

In contrast the geo operation services are not associated with specific data sets. [Alameh N., 2003]. A geo operation is defined by its inputs, outputs and function. The operation uses a certain geo operation algorithm to derive new data from data inputs. The outputs usually represent a new geospatial data product.

6. Implementation of a WMS
The OpenGIS Web Map Service Interface Implementation Specification offers a way to enable the visual overlay of complex and distributed geographic information maps simultaneously, over the Internet. In the context of WMS a “map” is a raster graphic “picture” of the data rather than the actual data itself [Cookbook, 2003].

The Web Mapping Server (WMS), which produces maps as two-dimensional visual portrayals of geospatial data performs three operations including produce a map, answer queries and tell other programs about maps it can produce by providing three types of interface which are called GetCapabilities (required), GetMap (required), and GetFeatureInfo (optional) [OGC, 2000].

Fig.6: Architectural view and main Component of WMS

The diagram illustrated in Fig 6 presents the architectural view and main components of web map services. In this case, environmental modeler as a client sends a request through his/her web browser to a server which is called web server. The web server understands requests and how to fulfill them. The web server sends the respond to the web browser according to which of operations mentioned in the request. The sending request and response can be done through a communication protocol called HTTP (over TCP/IP). If a request is sent to a Web server using vocabulary it doesn’t understand, it will respond with an error. In essence, the WMS Specification defines the vocabulary and the syntax of the commands/operations that enable Web servers and clients to communicate over the HTTP protocol.

6.1. Web Map Server Implementation
According to architecture view the main components of Web Map Server are Web server, Web map services and field data or raster map. A web server is a server that understand request and send response through the HTTP. We installed the Apache HTTP server (https://www.apache.org/) which implements version 1.1 of the protocol, referred to as HTTP/1.1. On Windows, Apache is normally run as a service on Windows NT, 2000 and XP.

For implementing WMS it is needed to write a CGI (Common Gateway Interface) program. It defines a way for a web server to interact with external content-generating programs, which are often referred to as CGI programs or CGI scripts.

An example of CGI program which has been developed in order to bring a chunk of field data or raster map to the web browser can be found in .

A CGI program must be preceded by a MIME-type header. MIME-type is a way to describe the kind of document being transmitted. Its name comes from that fact that its format is borrowed from the Multipurpose Internet Mail Extensions. This is HTTP header that tells the client what sort of content it is receiving.

The output needs to be in HTML, or some other format such as gif image, or other non-HTML content that a browser will be able to display. In our case study we used the image of the world as sample of field data or raster map.

6.2. Client Side
In the client side, there is no need to install additional program. An environmental modeler can send a request through his/her web browser. The response which is sent by server is represented in web browser. For example the following hypothetical URL requests the capabilities of web map services in a server called localhost:


The result of GetCapabilities operation is illustrated in Fig 7:

Fig.7: The result of GetCapabilities request on web browser
And the following hypothetical URL requests a chunk of image on that server:


The result is depicted in the following figure:

Fig.8: The result of GetMap request

7. Conclusion
In this paper we discussed that environmental modeler needs to use GIS capabilities including geo data and geo services in order to visualize and process physical fields used in model. In this regard we presented different linking methods. As consequence, the linking between GIS and environmental model based on web services which use loose coupling interaction satisfies the communication between modeler and GIS. The OpenGIS WMS as geo data services contains operations for visualizing physical fields.

In these types of services the data is tightly coupled to service. However in addition to visualization of physical fields, modeler needs geo operation services in order to get new physical field value from old data. Semantic ambiguities are barriers against efficient use of these types of services.

The future work is to study these semantic ambiguities and propose a solution for formal description of geo operation services.


  • [Alameh, 2003], Nadine Alameh, SEPTEMBER • OCTOBER 2003 Published by the IEEE Computer Society, 1089-7801/03/$17.00©2003 IEEE, IEEE INTERNET COMPUTING
  • [Barclay et al, 2002], Tom Barclay, Jim Gray, Eric Strand, Steve Ekblad, Jeffrey Richter, June 2002 TerraService.NET: An Introduction to Web Services, Technical Report MS-TR-2002-53, Microsoft Research Advanced Technology Division, Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
  • [Bernard and Krüger, 2000] Lars Bernard, Thomas Krüger, 2000, “Integration of GIS and Spatio-temporal Simulation Models: Interoperable Components for Different Simulation Strategies”, “(3+1) D-GIS” project, funded by the German Science Foundation grant no. STR 172/8-1
  • [Bishr, 1998], Yaser Bishr, “Overcoming the semantic and other barriers to GIS interoperability”, int. j. geographical information science, 1998, vol. 12, no. 4, 299-314
  • [Brodie, 1992], Brodie, M. L., 1992, The promise of distributed computing and the challenge of legacy lnformation systems. In Proceedings of the IFIP WG2.6 Database Semantics Conference on Interoperable Database Systems (DS-5), L orne, V ictoria, Australia (Amsterdam: North Holland ), pp. 1-31
  • [Buehler and McKee, 1996] Buehler, K. and McKee, L. 1996, “The OpenGIS Guide – Introduction to Interoperable Geoprocessing”, Technical report, Open Geodata Interoperability Specification (OGIS), Open GIS Consortium Inc.
  • [Capeclear, 2005] An introduction to service-oriented architecture. Cape Clear Software Inc. Available at: . Accessed 4 Jan 2005
  • [Casti, 1989], Casti, John L, 1989, Alternate Realities: Mathematical Models of Nature and Man, John Wiley & Sons
  • [Cookbook, 2003], OpenGIS Web Map Server Cookbook, April 28, 2003, Editor: Kris Kolodziej, OGC Document Number: 03-050, Version: 1.0.0
  • [Couclelis, 1992], Couclelis, H. 1992, People manipulate objects (but cultivate fields): beyond the raster-vector debate in GIS. Theories and Methods of Spatio-Temporal Reasoning in Geographic Space. A. U. Frank, I. Campari and U. Formentini, Springer-Verlag. 639: 65-77
  • [Djokic, 1996] D. Djokic 1996, “Toward a general-purpose decision support system using existing technologies”. In GIS and Environmental Modeling: Progress and Research Issues, pages 353-356, GISWorld Books, Fort Collins, CO
  • [Fedra 1996] Fedra K 1996, “Distributed Models and Embedded GIS: Integration Strategies and Case Studies”. In M F Goodchild, L T Steyaertand B O Parks (eds) GIS and Environmental Modeling: Progress and Research Issues. Fort Collins, GIS World Books: 413-418
  • [Feng, 2000] Chen-Chieh Feng, 2000, “Open Hydrologic Model for Facilitating GIS and Hydrologic Model Interoperability” 4th International Conference on Integrating GIS and Environmental Modeling (GIS/EM4): Problems, Prospects and Research Needs. Banff, Alberta, Canada, September 2 – 8, 2000. GIS/EM4 No. 6
  • [Goodchild, 2000], Michael F. Goodchild, 2000” SPATIAL ANALYSIS and GIS” ESRI USER CONFERENCE, Pre-Conference Seminar
  • [IBM’s tutorial] IBM’s tutorial www-4.ibm.com/software/solutions/webservices/
  • [ISO, 2001], ISO 19119:Geographic Information –Services. https://www.isotc211.org.
  • [MDSF] “Modeling and Decision Support Framework” https://www.mdsf.co.uk/
  • [Natis, 2003] NATIS, Y. V. Service-oriented architecture scenario. Gartner, Inc., April 2003
  • [Newcomer, 2002], Understanding Web Services- XML, WSDL, SOAP and UDDI, Copyright © 2002 by Eric Newcomer; published by Addison-Wesley, Boston
  • [OGC, 2000], Open GIS Consortium, Inc. (OGC) 2000, OpenGIS Web Map Server Interface Implementation Specification (Revision 1.0.0). Wayland, Massachusetts: Open GIS Consortium, Inc., URL: https://www.opengis.org/techno/specs.htm
  • [OpenMI_Newsletter], “OpenMI: A new era in integrated water management” [OpenGIS], https://opengis.org/techno/implementation.htm
  • [Smith and Mark, 2003], Barry Smith and David M Mark, Environment and Planning B: Planning and Design 2003, volume 30, pages 411 – 427
  • [Sydelko, et al, 2000], Pamela J. Sydelko, Jayne E. Dolph, Kimberly A. Majerus, Thomas N. Taxon, 2000, “An advanced object-based software framework for complex ecosystem modeling and simulation”, 4th International Conference on Integrating GIS and Environmental Modeling (GIS/EM4): Problems, Prospects and Research Needs, Banff, Alberta, Canada, September 2 – 8, 2000.
  • [Wikipedia], Wikipedia, https://en.wikipedia.org/wiki/Ontology