Logo GISdevelopment.net

GISdevelopment > Proceedings > GITA > 2000


GITA 2002 | GITA 2001 | GITA 2000 | GITA 1999 | GITA 1998 | GITA 1997 |  
Sessions

Data development and evolution

Engineering and design applications

Exploiting field and mobile technologies

Invited presentations

It's a brave new world

Leveraging web-based technologies

Mobilizing the enterprise

Operations support

People issues

System architecture

The best of the rest

Uniting the enterprise

User perspectives

Work management solutions



GITA 2000


Leveraging Web-Based Technologies
Printer Friendly Format

Page 1 of 3
| Next |


Development of a GIS Service Model in Support of online Geoprocessing

Shuxin Yuan and C. Vincent Tao
Geomatics Engineering, The University of Calgary
2500 University Drive, NW, Calgary, Alberta, Canada T2N 1N4

GIS is shifting its paradigm very fast from desktop-centric GIS to network-centric GIS. The worldwide adoption of network and application standards introduced and supported by the Internet initialized such a shift. An advantage of network-centric GIS is that it is able to provide GIS services in a networked environment, typically the Internet. In the past few years, the client/server model has been used in many on-line GIS service systems, in which a client submits a request to the server and the server processes the request and returns the result to the client. Data dissemination is the most common feature to these systems, geodata service systems. Geoprocessing functions in these systems are only limited to data display and query. In order to provide clients with more GIS functions, the emphasis on the development of geoprocessing service systems has been placed in our research.

The core technology of the GIS service systems is distributed GIS (D-GIS). With this technology, GIS components, both data components and functional objects, can be distributed across the network. GIS software is no longer a single proprietary system. It can be decomposed into many interoperable functional components using componentware technology. The distributed GIS model supports on-line geoprocessing services. It allows that a network client uses GIS data and functional resources distributed anywhere in the network. A simple use case of on-line geoprocessing is that the geodata sets are stored and managed on the client site. The client only needs to 'rend' some of GIS processing tools to handle the data, such as data conversion, map projection and data editing. In a more complicated use case, the geodata sets could come from different places, and can be processed by the geoprocessing tools offered through the Internet. Obviously, the traditional client/server model does not support these requirements. In this paper, a new approach to the support of on-line geoprocessing services is proposed. This new service model is designed based upon the distributed open object architecture. It allows the assembling of geoprocessing components distributed across the network and then transferring to the client site whenever the geoprocessing service is requested. This model not only improves the performance of client-server communication but also makes the entire geoprocessing functions accessible to the user over the Internet.

Data on either client site or server site can be integrated via a web browser. A prototype system that uses the proposed model has been developed using Java technologies. It is able to provide multiple users with various geoprocessing tools distributed in different places.

On-Line GIS services
Many on-line GIS service systems, primarily geodata service systems, have been developed in the past few years (Limp, 1999). Many systems, such as Autodesk Mapguide, ESRI Internet Map Server (IMS), Intergraph Geomedia Web, etc. are commercially available. However, there is a lack of the research and development of geoprocessing service systems (Open GIS, 1998).

On-line distributed geoprocessing depends largely upon distributed object technologies. Distributed object computing extends an object-oriented system by allowing objects to be distributed across a heterogeneous network, so that each of these distributed object components can inter-operate as a unified whole. There are several industry standards of distributed object computing, such as Microsoft's Distributed Component Object Model (DCOM), Object Management Group's (OMG) the Common Object Request Broker Architecture (CORBA) and Javasoft's Java Remote Method Invocation (Java RMI). Due to the Windows platform limitation of DCOM and the implementation complication of CORBA (Alberson, 1998), Java technologies are widely used in the Internet GIS applications. The Java family provides an ease-of-use solution to distributed computing. Java Applet provides interface and shared classes to the client through the Java-enabled browsers. Java Bean provides a way of producing interoperable components. Java RMI enables the remote object invocation. JDBC or JDBCODBC provides a universal means of connection between the internal objects and the external databases.

Java RMI is a pure Java distributed computing solution. In its architecture, code on client computer invokes a method of an object on the server. The client-server terminology applies to a single method call only. The machine that calls the remote method is the client and the computer that hosts the objects and processes the call is the server. The client and server are not fixed and they may change the roles in an application. In the Java RMI model, the geoprocessing functions may be distributed in any machine of the network and the resources of the network can be fully utilized.

As shown in Figure 1, Java objects are passed between the client and server in the form of marshaled Stub or Skeleton objects. The typical scenario of remote object passing is as follows: when the client code needs to invoke a remote method on a remote object, the parameter objects are encapsulated into a stub object. This object is then marshaled and passed to the server. On the server side, a skeleton object that makes sense out of the parameters in the marshaled stub object, and passes the parameters to the actual object to execute the remote method. After finishing the calculation, the returned object is then passed to the client.



Page 1 of 3
| Next |

Applications | Technology | Policy | History | News | Tenders | Events | Interviews | Career | Companies | Country Pages | Books | Publications | Education | Glossary | Tutorials | Downloads | Site Map | Subscribe | GIS@development Magazine | Updates | Guest Book