Home Articles A Comparative Assessment of Giservices Architectures

A Comparative Assessment of Giservices Architectures

Wilaiporn Sriphaisal, Arun K. Pujari
Department of Computer and Information Sciences,
University of Hyderabad,
Hyderabad 500046, Andhra Pradesh, India
[email protected], [email protected]

Abstract
The development of GIS technology has evolved from mainframe GIS to desktop GIS to distributed GIS. The traditional GIS, referring to mainframe GIS and desktop GIS, are called GISystems. Distributed GIS is referred as GIServices which includes wired Internet GIS and wireless mobile GIS. The major difference between them is that GISystems work on wired, while GIServices work through both wired and wireless networks. Today technologies of interoperability standards give the ability of a system or components of a system to provide geographic information portability and inter-application. The user who cannot support immense budget for building their own GISystems can access, exchange and process geographic information from different providers. Getting clearance maps and data from ready-to-use mapping providers may not difficult but time consuming. GIServices are effective tools for decreasing both budget and processing time for the end user. Numerous users from anywhere are able to access, exchange, and process geographic information from various providers at any time.

The present work is a study of recent GIServices Architectures. In this paper, we discuss the strengths and weaknesses of these architectures. Besides the general aspects of the architecture, we concentrate to specific aspects namely, real-time, on-the-fly geoprocessing. It is interesting to note that many of major GIServices architectures have not given proper emphasis on on-the-fly geoprocessing. In this paper, we try to justify that this is one of the most desirable features of any GIServices. The objective is to arrive at a new architecture that can enhance real-time and on-the-fly characteristics.

1. Introduction
A survey of the GIS Web services available on the Internet shows that most of those sites are static in the sense that the Web pages are manually prepared and updated. Users frequently have trouble of getting user-defined maps and/or geographic information because they get bogged down in the real-time and on-the-fly geoprocessing. GIS Web Services, so called GIServices, are software components that can be accessed through the World Wide Web (WWW) and used by other applications [12]. GIServices provide spatial data or functionality on the WWW. They make it possible for users to access GIS data and functionality through the Web and to integrate them with their own systems and applications without the need to develop on host specific GIS tools and data sets themselves.

2. Background

2.1 Types of GIS architecture
The development of GIS technology has evolved from traditional GISystems to client/server GISystems to distributed GIServices [8]. The mainframe GIS and desktop GIS are traditionally called GISystems. Traditional GISystems are closed, centralized systems that incorporate interfaces, programs, and data. Each system is platform dependent and application dependent. Every element is embedded inside traditional GISystems and cannot be separated from the rest of the architecture. Traditional GISystems works on stand alone system.

Client/server GISystems are based on generic client/server architecture in a wired network design. The client-side components are separated from server-side components and usually platform dependent. Client/server architecture allows distributed clients to access a server remotely by using distributed computing techniques such as Remote Procedure Calls (RPC) or database connectivity techniques such as Open Database Connectivity (ODBC). Each client component can access only one specified server at one time. Different geographic information servers come with different client/server connection frameworks which cannot be shared.

Distributed GIServices enable users to manipulate GIS data and maps interactively over the wired Internet or wireless telecommunication networks. It is not necessarily required the user to install GIS programs on the user’s desktop. Distributed GIServices can interact with heterogeneous systems and platforms without the constraints of traditional client/server relationships. There is no difference between a client and a server. Every GIS node embeds GIS programs and geodata. Each GIS node can become a client or a server based on the task at hand. A client is defined as the requester of a service in a network while a server provides a service. There are two categories of distributed GIS: Internet GIS and mobile GIS. The major difference between them is that Internet GIS works on the wired Internet networks and the client is usually a desktop computer, while mobile GIS works through the wireless telecommunication networks and the client may be a laptop computer, a Personal Digital Assistant (PDA), or a mobile phone.

2.2 Evolutions of distributed GIS
The evolution of distributed GIS is following the development of computer technologies and telecommunication networks. It started with static map publishing and evolved to static Web mapping, to interactive Web mapping and to the distributed GIServices [8]. Static Map Publishing distributes maps on the Web page as static map images in graphic formats like Portable Document Format (PDF), Graphic Interchange Format (GIF), or Joint Photographic Experts Group (JPEG). The ready-made maps on the Web are usually part of HyperText Mark up Language (HTML) document. Users cannot interact with the maps or change their display format in any way.

Static Web mapping involves the use of HTML forms and the Common Gateway Interface (CGI) to link the user input on the Web browser with GIS or mapping programs on the servers. Users make requests from the Web browser using customized HTML forms. Then the request is sent to the CGI through a HyperText Transfer Protocol (HTTP) server to invoke GIS or mapping engines. The GIS or mapping engines create the map based on the user’s request and generate an image map. The image is sent via HTTP back to the user on the Web browser. Users cannot define or draw anything on the image maps because the HTTP form is text based and allows limited user input.

Interactive Web mapping adds scripts like Dynamic HTML (DHTML) and/or client-side applications like plug-ins, ActiveX control, and Java applets to the Web client side. Some user queries can be processed on the client side without sending requests to the servers. This approach requires HTTP connections and the Web servers to mediate between software objects running on the client and the servers which store these objects. Interactive Web mapping does not meet the requirement of distributed GIServices completely. Client-side application as mentioned above are design essentially fro graphic display of maps rather than truly providing GIS operations and analysis. Interactive Web mapping give very limited functionality that does not offer much interactivity and flexibility for complicated GIS modeling and processing.

Distributed GIServices refers to a specific software framework. GIS components on the client side can directly communicate with other GIS components on the server without going through the CGI middleware and an HTTP server. Distributed GIServices rely on the communication between Common Object Request Broker Architecture (CORBA)/ Java ORB or Microsoft Simple Object Access Protocol (SOAP) on the client side.

According to ISO 191191, the term of “services” means a collection of operations, accessible through an interface that allows a user to invoke a behavior of value to the user [7]. Web services are interoperable, self-contained, self-describing, module components that can communicate with each other over the Web services platform [8].

Web services architecture have three roles – service providers, service requestor, and services brokers (Figure 1). It performs three essential kinds of operations – publish, find and bind. The service providers publish machine-readable information (metadata), receiving requests and binding a service to a service requestor. In the client/server model, the service requestor is a client, the service provider is a server, and the service broker is a middleware.

Figure 1 – Generic components of Web services

2.3 Interoperability and standards
Interoperability is a desirable part of Web GIServices. Interoperability refers to the ability of a system (or components of a system) to work with the other systems without special effort on the part of the user. The interoperability will support distributed computing and/or data exchange among different computer systems, databases, or networks. Standards is necessary for defining the common agreements that are needed to achieve interoperability between IT components.

The standard behind Web services is a collection of distributed-component technologies. It gives the ability of a system to provide geographic information portability and inter-application. The World Wide Web Consortium (W3C) is an industry consortium dedicated to building consensus around Web technologies [15]. W3C proposed the eXtensible Markup Language (XML) to describe the data contained in a document while HTML describes only how to present data contained in a document [18]. XML can contain commands and parameters to be passed to a remote application, or complex data sets returned from an earlier query. XML permits users to write their own definitions that any type of data can be described. The Open Geospatial Consortium (OGC) is a non-profit, international, voluntary consensus standard leading the development of standards for geospatial and location based services [6]. The specifications (developed and provided by OGC) are based on emerging standards in the ISO/TC 211 Geographic information/Geomatics work groups and work items. OGC adopted Geography Markup Language (GML) to encode for the modeling, transport and storage of geographic information including both the spatial and non-spatial properties of geographic features [2]. It allows the data to be controlled on the browser side by the user without additional components or viewers. GML uses XML to transport descriptions of features over the Internet.

Simple Object Access Protocol (SOAP) defines a protocol for information exchanges among programs in the heterogeneous Internet environment by using HTTP and XML [10]. It is application-independent. Web services that conform to the SOAP standard can be integrated with any other Web-based application. The W3C has adopted Web Services Description Language (WSDL) as a standard way of describing the Web services [17]. WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. WSDL is a template for how Web services should be described and bound by clients. The Universal Description, Discovery and Integration (UDDI) protocol is one of the major building blocks required for successful Web services [13]. UDDI creates a standard interoperable platform that enables companies and applications to quickly, easily, and dynamically find and use Web services over the Internet. UDDI is a searchable registry database that stores the metadata of system components (generated by WSDL) and allows other programs to search/access these components.

2.4 On-the-fly geoprocessing
On the Fly describes activities that develop or occur dynamically rather than as the result of something that is statically predefined [14]. The process will be done in real-time, based on dynamic factors such as the time of day, what pages the user has looked at previously, and specific user input [11]. There are several techniques for on-the-fly page development such as DHTML or client-side applications like plug-ins, ActiveX control, and Java applets. Today GIS users want to create user-defined maps rapidly without need of downloading data from Internet into local system. Real-time and on-the-fly geoprocessing will be served this requirement. The user can construct the GIServices programs on-the-fly by downloading the proper GIS components and data objects from the service provider. Systems described above cannot support on-the-fly geographic. The following user scenario will make obvious of on-the-fly geoprocessing.

Kiran, a general user, wants to plan three days trip in Bangkok. He wants to travel by buses for sight seeing and go by boats for shopping at the floating market. He needs to obtain map information such as Bangkok tourist map, Bangkok city roads map, Bangkok buses route, Bangkok water transportation route. He also needs hotel locations map for making decision for hotel reservation. Based on this scenario, there are three major actors. Kiran, who has no knowledge of GIS, wants to plan a trip. Suchada, a map designer, designs appropriate symbols and layouts for Bangkok tourist map, city roads map. She puts them into a GIS server for on-line access. Sanjay, the tourist agency, will provide the hotel reservation information and package tour.

The first step is that Kiran connects to GIS server through Web browser. He checks out theme of Bangkok maps – tourist map, city roads map and hotel locations map. Three maps were overlaid and displayed as the first result map on Web browser. He picks a few hotels that are on the bank of the river and click to follow links of hotel’s Web site. He makes on-line reservation and gets a confirmed message from Sanjay after compared prices and availability. Moreover, Kiran want to include the route of buses and boats in the final map. Unfortunately, Suchada does not define the Bangkok buses route and water transportation route. Kiran has to search for other GIS servers and download into local GISystem for overlaying. But he does not have GISystem, so that he has to print out on papers and overlay these maps by manual. Hence, on-the-fly geoprocessing can serve this requirement. Kiran holds first result map on the browser while requests for buses and boats route maps from other GISystems on the Internet. The next step is to overlay all maps through the Web browser. On-the-fly geoprocessing allow Kiran can get his own design map that Suchada does not create the predefine map.

3. Architecture models of distributed GIS
An architecture model provides the framework of what kind of system is to be built and the functions the system could have. An architecture model of distributed is classified to be three models: OGC’s generic Web mapping architecture, restricted client/server GIS framework, and open distributed GIS [8]. In this paper, we describe two reference models of the open architecture model – The Reference Model for Open Distributed Processing (RM-ODP) and ISO 19101; reference model of the 19100 series of International Geomatics standards

3.1 OGC’s generic Web mapping architecture
OGC has adopted ISO 19119 as the basis for an Abstract Specification of the OGC Web Services (OWS) model [7]. Each service is a collection of operations, accessible through an interface, with certain parameters through such interfaces. The service calculates a result, which is served to an application client. OWS model provides a generic framework to construct a distributed Web mapping that allows the user on the Web browser to search, retrieve, interact, and manipulate geospatial data stored in a distributed environment across the Internet. The user can do one of four things – search for data on the Internet through a catalog that contains metadata, invoke operators to conduct data analysis, retrieve and edit data and metadata from the data repositories, or construct object relationships. All Web mapping programs, that use Web Map Server (WMS) implementation specifications, can interoperate with all each other [16].

The strength of this model is the client-side components are usually platform independent, requiring only an Internet browser to run. This model allows distributed clients to access a centralized server remotely.

3.2 Restricted client/server GIS framework
A restricted client/server GIS framework is a system on its own. The client can only communicate with its own Web server, map server(s), and data server(s). All user requests from the client are handled by a single application server that manages one or more map servers and data servers. The system is composed of four main components – a client, a Web server with application server, a map server, and a data server [8]. A single-server system with only one map server and data server does not scale well and is weak in fault tolerance when a large amount of user requests. Each client component can access only one specified server at a time. The services may be limited by the numbers of clients and applications provided on the servers. A multiserver system with multi map servers and data servers has good scalability and fault tolerance. When the amount of user requests gets larger or the amount of data increases, additional map servers and/or data servers can be added without affecting the client side of the application. For the user at the client-side, nothing is different. The multiserver system should include catalog services, load balance services, and data repository. A catalog service is used to keep track of what functions each map server can provide, and a load balance service is used to assign tasks to specific map server based on the workload condition of each map server at a specific time. Data repository is a registration service that keeps track of the type of data and the locations of all data sets.

The strength of the multiserver system in the restricted client/server GIS framework is it allows distributed clients to access a centralized server remotely but the weakness is platform dependent and not interoperable.

3.3 Open distributed GIS
The OGC’s generic Web mapping architecture is proposed as the logic of the interoperability of the systems/networks/softwares, while the restricted client/server GIS framework has role as practical of the commercial GIS agent. Till recently, most of the commercial systems follow the restricted client/server GIS framework. The Open distributed is a combination system of OGC’s generic Web mapping architecture and A restricted client/server GIS framework.

An open or interoperable system is technically not one system; rather than it is a virtual system or a repository of distributed GIS providers that comply with the same standards. Each distributed GIS provider will have its own systems with its own Web server, map server, and data server. But all system will support the same protocol so that they can communicate with each other [8].

The strength of this model is that it distributed clients to access a centralized server remotely. Furthermore, it can handle complex requests and prioritize the sequence of requests from the client side. Each system can play both a server’s role and a client’s role, so it provides more flexible access and application on both the client side and server side. The client-side components are usually platform independent, requiring only an Internet browser to run.

Klopfer [5] gave two examples of the open distributed GIS: the Reference Model for Open Distributed Processing (RM-ODP), and ISO 19101- reference model of the 19100 series of International Geomatics standards. The RM-ODP is an international standard for open architecture, distributed processing systems. This architecture also provides a framework for assessing system conformance. The RM-ODP standards constitute the conceptual basis for the ISO 19100 series of Geomatics standards [9]. The RM-ODP standards can be classified in the four categories identified within the overall framework provided by the RM-ODP: 1) additional architectural frameworks, which complement the RM-ODP in specific areas such as naming, security and conformance assessment; 2) notation standards, which define notations for expressing specifications of different aspects of system integration and distribution, and rules for relating different specifications; 3) component standards, which define a single ODP function or closely interrelated set of ODP functions, possibly capable of implementation as a single hardware or software platform; 4) component composition standards, which define the coordinated use of a number of components to achieve some objective of the system as a whole, such as provision of a specific transparency.

There are many standards and models proposed by ISO/TC211. One of the most important components for the actual implementation in practice is the definition of the software architecture (ISO 19101 – reference model). The ISO 19101 defines conceptual modeling as the process of creating an abstract description of some portion of the real world and/or a set of related concepts [5]. The architectural reference model identifies four general types of interfaces in order to enable the interoperability of GIS in distributed-computing environments: Application Programming Interface (API), Human Technology Interface (HTI), Information Services Interface (ISI), and Communication Services Interface (CSI) [8].

4. A comparative assessment of GIServices architecture
In this section, we study some of the major GIServices architectures and attempt to bring out a comparative analysis of these. The systems that we study in this section are Go-Geo!, GeoBeans3D, and A distributed GIService model using CORBA.

Case 1: Go-Geo!

Figure 2 A development architecture of the Go-Geo! service [1]

Go-Geo! ) is an online resource discovery tool which allows for the identification and retrieval of records describing the content, quality, condition and other characteristics of geospatial data that exist within UK tertiary education and beyond [1]. It was discovered that publishing to UDDI registries currently appears to be an awkward process, and it was not possible to find a simple and free web interface dedicated to this task. An alternative method was proposed in the form of developing a programming interface such as the UDDI::Lite Perl module, in order to achieve this. The extended functionality of Go-Geo (Figure 2) are: 1) Publication of grid-enabled data services to the service registry; 2) Discovery of GI datasets using the grid-enabled data services, and 3) Access and integration of the grid-enabled data services.

The GI Access and Integration Services (GI-AIS) component receives requests from the search GI portlet (GI-P), then passes these requests via a GI interface (GI-IF) on to one or more GI services, and cause the results to be processed. Each GI-IF will provide an interface to the GI-AIS component corresponding to that supported by its OGC-compliant. The GI-IF provides authentication and authorization services. The GI-P uses WSDL and one of a number of predefined schemas. The GI-AIS component will be able to allow online, authorized access to GI datasets and allow multiple datasets to be integrated.

Case 2: GeoBeans3D

Figure 3 A Web application architectures of GeoBeans3D [19]

Geobeans3D is a 3D global visualization system on the networks. It fuses massive vector data, image and DEM data sets into a seamless 3D model database of the globe; Geobeans3D can also visualize the features such as ground cover and trees, buildings and other static objects [19]. Geobeans3D is designed to be a flexible Client/Server architecture (Figure 3). The major manipulations are implemented on the client side, rather than on the server side. The server receives the client requests and to find out the proper data sets with the use of the spatial index method. The server dispatches the data sets to the client. At the same time, other parameters are generated and initialized before the requests are completed. The client sends the requests to the server whenever certain resolution data sets of the region are needed or updated.

Geobeans3D uses multi-threading and dynamic object loading techniques based on data paging to accelerate real-time virtual terrain scene display. Rendering 3D scene of every frame is corresponding to a data page of the memory. Geobeans3D need to update data sets of the cache, and it consumes certain time to read data from the disks which cause system delay while dynamically rendering the scene. To provide smooth animation and to speed up user-interaction, a number of server threads run in the back end of the run-time system where they communicate with the external processes and fetch data from local disk. In addition, these threads perform intermediate tasks such as data transformations, data input and initialization, and data compression whenever necessary. The cached data is always updated if the scene or the viewpoint changes. The client creates 3D global models using Digital Elevation Model (DEM), 3D models and imagery acquired from the server. The 3D scenes that are to be visualized are rendered with priority-based out-of-core streaming. The scene rendering thread decides the grades of the corresponding. After the server submits the record sets to the cache and starts a transmission thread, the client receives the compressed data sets, first decompresses them and then visualizes them, in the meanwhile, the thread that receives the data shifts toward the background. When the client finishes handling one request, it deletes all the system resources. Data Manager Components is composed of a Thread Manager, Scene Display Thread, and Data Cache. Data Manager Components connect with DEM files and Images file. Furthermore, GIS database and 3D model database connect to Data Manager Components through the ActiveX Data Object (ADO) Connection.

Case 3: An GIService model using CORBA

Figure 4 A distributed GIService model using CORBA [4]

The Figure 4 shows the architecture of the generic open GIS based on object services and features provided by the Common Object Request Broker Architecture (CORBA). The integrator has a role similar to a mediator. It dispatches the user instructions to the subsystems and integrates their results. It is composed of a query manager (QM), an object manager (OM), and a service manager (SM). The QM is composed of a code generator and an optimizer. It dispatches the appropriate queries to the object manager and the service manager. The OM is in charge of fetching relevant objects from repositories, as well as defining and storing them locally. The SM is in charge of communicating with all services provided by participating systems. It is mainly composed of a scheduler and a dispatcher. It draws on the service catalog to further dispatch operation [4].

The CORBA Services aim at supporting the application developer with common tasks such as finding object references by name or by properties offer persistent storage for objects as well as transactional and messaging support Altogether services have so far been standardized by the Implicitly means that the inheritance is not explicitly indicated in the interface of a CORBA objects but automatically performed by the system OMG. A simple CORBA-GIS-facility providing at least the following functionality: 1) Measurable geo-data representation formats; 2) Geo-data visualization and user interaction support; 3) Map representation and query support, and 4) Complex data modeling functions. However, CORBA has limits lie in constraints imposed on the open GIS design by the particular nature of the geographic domain.

The integrator has a role similar to a mediator. It dispatches the user instructions to the subsystems and integrates their results. It is composed of a query manager (QM), an object manager (OM), and a service manager (SM). The OM is composed of a code generator and an optimizer. It dispatches the appropriate queries to the OM and the SM. The OM is in charge of fetching relevant objects from repositories, as well as defining and storing them locally. The SM is in charge of communicating with all services provided by participating systems. It is mainly composed of a scheduler and a dispatcher. It draws on the service catalog to further dispatch operation.

4. Conclusion
This paper presented a comparative assessment of GIServices architectures. We started with the narrative of the evolution of distributed GIS since static map publishing to static Web mapping, to interactive Web mapping, and to the distributed GIServices. Then we presented more background of the standards for interoperability before discussed about the strengths and weaknesses of the architecture models of distributed GIS.

An open distributed GIS architecture is an interoperable system for multiple clients and servers. A user from any client can discover, access, retrieve, and utilize data and GIS component services from any map server and data server across the Internet. The retrieved data and analysis tool component can be integrated and displayed at one client. We noted that many of major GIServices architectures have not given proper emphasis on real-time and on-the-fly geoprocessing. This paper is only a partial research of a comparative assessment of GIServices architectures. The future work is to arrive at a new architecture that can enhance real-time and on-the-fly characteristics.

References