Printer friendly format

Page 2 of 3
Previous | Next

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

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 [http://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 (http://www.arcwebservices.com/services/v2006/MapImage.wsdl). 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.