A Comparative Assessment of Giservices ArchitecturesAn 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! (http://www.gogeo.ac.uk) 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
|