| GISdevelopment.net ---> GITA 2000 ---> Leveraging Web-Based Technologies |
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
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.
Distributed Geoprocessing model design
Most information systems use the three-tier architecture in which a system is composed of three layers:
Since the data and functions can be distributed in different places, the location of application logic layer and storage layer should be flexible in a distributed model. The following gives the possible distributions(P) of the geodata and geoprocessing tools in one location, no matter it is on a client site or on a server site. Let D represent geodata, F geoprocessing tools (Functions). Using the following notions, Da : all of the necessary geodata, Dp : part of the necessary geodata, Fa :all of the necessary geoprocessing tools, Fp : part of the necessary geoprocessing tools, and null: none of the necessary geodata or geoprocessing tools, we have
The ( null , null ) only exists in client situation. A distributed geoprocessing model should be able to deal with the above 9 possibilities. The presentation layer as well as the application logic layer are kept on the client site. This is conformable to the Java RMI requirement. As in case (null, Fa ), (null, Fp ), ( Da , null), and ( Dp , null), the geodata (storage layer) and the geoprocessing tools (application logic layer) are not always located in the same location.
Distributed GIS Data Model
Figure 2: Conceptual data model of a distributed GIS
The application logic layer is the most important part of a GIS. It is responsible for administrating and offering geoprocessing tools. To enable the object communication between client and server, a common data model must be established first. This model provides the client and server with the basic understanding of the geodata during the communication, as the geo-objects are passed as parameters. This model defines object geometry (Point, Polyline, Polygon, etc.), geodetic reference system object (Datum, Ellipsoid, Projection, etc.), Metadata entity (Accuracy, etc.), and so on. Figure 2 illustrates a conceptual data model.
Unlike a desktop GIS data model, the remote objects are included in the data model in order to support remote communications. Remote objects that link to the internal objects (such as Map or Layer) provide remote methods to clients. The dotted lines that link to the remote object in Figure 2 are only examples of the relationships between remote objects and internal objects. In fact, any internal object may connect to the remote objects if the remote methods are required.
Distributed Geoprocessing Using Java Applet and Java RMI
The primary objective of the distributed geoprocessing model is to make use of the network resources, including data resources and geoprocessing resources. Java applet is a good choice for providing clients with the presentation layer as well as some domain classes. Since the applet must be embedded in a web page, a web server is involved in the model. Other servers may contain different geoprocessing tools that are offered to the client via Java Remote Method Invocation (RMI) or the Java Applet. These tools shall be registered in a registration server of geoprocessing components. The geoprocessing server may also make a remote call to other geoprocessing servers. In this way, even a single function can be distributed over the network. Figure 3 describes a structure of the distributed geoprocessing model.
Geoprocessing Component Registration Server
In Figure 3, the triangular relationship among the clients, the geoprocessing servers and the component registration servers form the framework of the model. In this triangle, the geoprocessing tools are registered into the registration server through Java servlet, the registration server provides the registration information to applet client through RMI, and the applet client makes remote call to the geoprocessing servers. The component registration is a key part of the model that allows the client to have flexible choices of the available geoprocessing functions. Without this registration, the remote method invocation will be static and fixed by the programming in advance. This flexibility of the model is supported by the geoprocessing meta-component (component registration). Some possible candidate meta-component elements may contain information about functionality description, version, location (IP, URL), port number, remote geodata connection (database URL), provider’s information, component credit, etc. Java servlet is the solution to fulfill this function. It deals with the registration process and adds the information into the registration database.
Prototype System Implementation
Data Model
In the past several decades, many GIS data models have been employed. The most popular one was the geometry-centric geo-relational GIS model in which the geometry features (points, lines, and polygons) are stored in files with the attributes in a relational database. Most recently, an object data model is introduced to GIS by allowing the geometry and attributes to be integrated into geographic objects. Figure 2 shows the implementation data model used in the prototype system. The OpenGIS Implementation Specifications (Open GIS, 1999) has been used as a reference for the design of this model. In the model, a map-layer-geometry structure is adopted. The attributes that are stored in a relational database are connected to the system by a JDBC-OBBC driver. When a query is submitted, the geometry and the corresponding attributes are bound into a GeoRecord object that aggregates into a collection object, GeoRecordSet. Figure 4 depicts this structure of the implementation data model.
Distributed Geoprocessing Services
In the system, the client program is deployed through downloading of the Java Applet automatic classes. The applet is connected with servers using Java RMI. Any objects and methods can be implemented as remote objects. The following is a list of several typical on-line services that can be offered via the Internet:
The concept of the GIS services changes the way GIS users use GIS, the way GIS vendors sell GIS and the way GIS information providers supply spatial information. A distributed geoprocessing model must be developed in a way that it allows the flexibility and openness of distributed services in comparison to the traditional client/server models. The Open GIS compliant data model design and the APIs development as well as the component registration are some of key issues towards the implementation of the system.
Technical challenges also include distributed transaction techniques, distributed spatial algorithms and the rapid system response. In order to maintain the consistency of the data, transaction control has been important especially in the case of that multiple clients are working on the same geodata set. Another issue is the optimized design of the distribution of objects to minimize the response time of the remote object invocation. Efficient distributed algorithms are required in this case. However, the research on the distributed spatial algorithms is very limited, and more attention should be paid in this area.
References
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.
Distributed Geoprocessing model design
Most information systems use the three-tier architecture in which a system is composed of three layers:
- Presentation Layer: the front-end of the system that contains the interface for the client.
- Application Logic Layer: the middle tier of the system that contains the domain processing objects. In a GIS it is the geoprocessing components.
- Storage Layer: the back-end of the system that stores the data set in the database.
Since the data and functions can be distributed in different places, the location of application logic layer and storage layer should be flexible in a distributed model. The following gives the possible distributions(P) of the geodata and geoprocessing tools in one location, no matter it is on a client site or on a server site. Let D represent geodata, F geoprocessing tools (Functions). Using the following notions, Da : all of the necessary geodata, Dp : part of the necessary geodata, Fa :all of the necessary geoprocessing tools, Fp : part of the necessary geoprocessing tools, and null: none of the necessary geodata or geoprocessing tools, we have
The ( null , null ) only exists in client situation. A distributed geoprocessing model should be able to deal with the above 9 possibilities. The presentation layer as well as the application logic layer are kept on the client site. This is conformable to the Java RMI requirement. As in case (null, Fa ), (null, Fp ), ( Da , null), and ( Dp , null), the geodata (storage layer) and the geoprocessing tools (application logic layer) are not always located in the same location.
Distributed GIS Data Model
Figure 2: Conceptual data model of a distributed GIS
The application logic layer is the most important part of a GIS. It is responsible for administrating and offering geoprocessing tools. To enable the object communication between client and server, a common data model must be established first. This model provides the client and server with the basic understanding of the geodata during the communication, as the geo-objects are passed as parameters. This model defines object geometry (Point, Polyline, Polygon, etc.), geodetic reference system object (Datum, Ellipsoid, Projection, etc.), Metadata entity (Accuracy, etc.), and so on. Figure 2 illustrates a conceptual data model.
Unlike a desktop GIS data model, the remote objects are included in the data model in order to support remote communications. Remote objects that link to the internal objects (such as Map or Layer) provide remote methods to clients. The dotted lines that link to the remote object in Figure 2 are only examples of the relationships between remote objects and internal objects. In fact, any internal object may connect to the remote objects if the remote methods are required.
Distributed Geoprocessing Using Java Applet and Java RMI
The primary objective of the distributed geoprocessing model is to make use of the network resources, including data resources and geoprocessing resources. Java applet is a good choice for providing clients with the presentation layer as well as some domain classes. Since the applet must be embedded in a web page, a web server is involved in the model. Other servers may contain different geoprocessing tools that are offered to the client via Java Remote Method Invocation (RMI) or the Java Applet. These tools shall be registered in a registration server of geoprocessing components. The geoprocessing server may also make a remote call to other geoprocessing servers. In this way, even a single function can be distributed over the network. Figure 3 describes a structure of the distributed geoprocessing model.
Geoprocessing Component Registration Server
In Figure 3, the triangular relationship among the clients, the geoprocessing servers and the component registration servers form the framework of the model. In this triangle, the geoprocessing tools are registered into the registration server through Java servlet, the registration server provides the registration information to applet client through RMI, and the applet client makes remote call to the geoprocessing servers. The component registration is a key part of the model that allows the client to have flexible choices of the available geoprocessing functions. Without this registration, the remote method invocation will be static and fixed by the programming in advance. This flexibility of the model is supported by the geoprocessing meta-component (component registration). Some possible candidate meta-component elements may contain information about functionality description, version, location (IP, URL), port number, remote geodata connection (database URL), provider’s information, component credit, etc. Java servlet is the solution to fulfill this function. It deals with the registration process and adds the information into the registration database.
Prototype System Implementation
Data Model
In the past several decades, many GIS data models have been employed. The most popular one was the geometry-centric geo-relational GIS model in which the geometry features (points, lines, and polygons) are stored in files with the attributes in a relational database. Most recently, an object data model is introduced to GIS by allowing the geometry and attributes to be integrated into geographic objects. Figure 2 shows the implementation data model used in the prototype system. The OpenGIS Implementation Specifications (Open GIS, 1999) has been used as a reference for the design of this model. In the model, a map-layer-geometry structure is adopted. The attributes that are stored in a relational database are connected to the system by a JDBC-OBBC driver. When a query is submitted, the geometry and the corresponding attributes are bound into a GeoRecord object that aggregates into a collection object, GeoRecordSet. Figure 4 depicts this structure of the implementation data model.
Distributed Geoprocessing Services
In the system, the client program is deployed through downloading of the Java Applet automatic classes. The applet is connected with servers using Java RMI. Any objects and methods can be implemented as remote objects. The following is a list of several typical on-line services that can be offered via the Internet:
- GIS data access services: geodata access from different sites.
- Data transformation services: projection transformation, coordinate transformation, data format transformation, etc.
- Geospatial information extraction services: specific features extraction from images or maps.
- Feature generalization services: features generalization from large-] and small-scale maps
- Feature manipulation services: map editing, feature cleaning, feature digitizing, topology building, geocoding, etc.
- Geospatial analysis services: network analysis, buffering, etc.
- Geospatial modeling services: TIN modeling, 3D terrain modeling, etc.
- Map annotation and symbolization services.
- Geodata access service: both remote and local data access
By default, an applet is not allowed to access local files due to the java strict security management. However an entrusted applet is allowed to do so. An applet can access the remote geodata via Java Remote Method Invocation. Figure 5 is a screenshot of this applet in the process. The system supports the integration of data layers coming from both local and remote sites.
- Data transformation services: Coordinate System
Coordinate transformation implemented in the prototype system supports the transformation between the geographic coordinate system and the projected UTM coordinate system, including the change of unit (linear and angular), datum (NAD27, NAD83), map projection, etc. This service supported by the Geospatial Reference System Module is useful especially in case of geodata integration.
The concept of the GIS services changes the way GIS users use GIS, the way GIS vendors sell GIS and the way GIS information providers supply spatial information. A distributed geoprocessing model must be developed in a way that it allows the flexibility and openness of distributed services in comparison to the traditional client/server models. The Open GIS compliant data model design and the APIs development as well as the component registration are some of key issues towards the implementation of the system.
Technical challenges also include distributed transaction techniques, distributed spatial algorithms and the rapid system response. In order to maintain the consistency of the data, transaction control has been important especially in the case of that multiple clients are working on the same geodata set. Another issue is the optimized design of the distribution of objects to minimize the response time of the remote object invocation. Efficient distributed algorithms are required in this case. However, the research on the distributed spatial algorithms is very limited, and more attention should be paid in this area.
References
- Abel, D., 1998, "Towards integrated geographical information processing", International Journal of Geographical Information System, Vol. 12, No. 4, 1998, pp353-371
- Albertson, T., 1998, "Best practices in distributed object application development: RMI, CORBA and DCOM", Developer.Com Journal, February 1998
- ESRI, 1997, "The future of GIS on the Internet", an ESRI White paper, http://www.esri.com/library/whitepapers/pdfs/futuregis_int.pdf
- Gebhardt, J. and Henderson, L., 1999, "WebCGM – Industry strength vector graphics for the web", CGM Open Consortium, Inc, http://www.cgmopen.org/webcgmintro/paper.htm
- Limp, W.F., 1999, "Don't hit wrap speed with Wrong Equipment!", GeoWorld, November 1999, Vol 12, No.11, pp44-48
- Open GIS Consortium technical committee, 1998, "The OpenGIS Guide", Draft, Fourth edition, http://www.opengis.org/techno/guide.htm
- Open GIS Consortium, 1999, "OpenGIS Simple Features Specification for OLE/COM ", The OpenGIS Implementation Specifications, Version 1.1, http://www.opengis.org/techno/specs.htm
- Zhang, L., Li, B. and Lin, H., 1998, "A Model of GIS Virtual Machine", Geographic Information Sciences, Vol 4. No.1-2, December 1998, pp23-28