Development of a GIS service model in support of on-line Geoprocessing

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.

The application logic is the key part of the system that models the data, links the data with the interface, and most importantly provides system functions to the client. In the client/server model, the presentation layer is on the client site. The application logic layer and the storage layer are kept in the server.

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, D_a : all of the necessary geodata, D_p : part of the necessary geodata, F_a :all of the necessary geoprocessing tools, F_p : 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, F_a ), (null, F_p ), ( D_a , null), and ( D_p , 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.