International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol XXXV. Part B2. Istanbul 2004
computing (P2P) that permits personal computers or
workstations to communicate directly with one another,
without a server (McCarty B,1999). The difference between
P2P computing and the distributed architecture is that P2P can
allow only one-to-one or one-to-many communication. A fully
distributed GIService architecture has to permit many-to-many
communications among computers; and here lies a current
technical barrier to be overcome.
| Client/Server
Client/Server
y
Client/Server
Distributed GIS
Figure 2: Distributed architecture
2. RESOURCE DISTRIBUTION POSSIBILITIES
According to the ideal conceptual model that support "geodata
anywhere, geoprocessing anywhere", the geodata and
geoprocessing functions could be distributed in different sites
(Yuan S., 2000).The following gives the possibilities of
distribution (P) of the geodata and geoprocessing tools in one
location, no matter it is at a client site or at a server site. Let D
represent geodata, and F indicate geoprocessing tools
(Functions).
Using the following notations:
D: of geodata,
F: geoprocessing tools,
null: none of geodata or geoprocessing tools.
Then, we have:
D = {D, null} and F = {F, null}
p=D F={{(D,F){nulL F). (D, null } ‚€ null, null 33 561)
Which:
(null, null ) Only exist at the client side, which means that
neither geodata nor geoprocessing tools exist at the client side.
The client in the typical client/server GIS model fit this case.
(D , F ) Typically exist at the server side in an typical
client/server GIS architecture, which means that all geodata and
gcoprocessing functions are provided by the server. Since the
server has everything (see the (null, null) case). Standalone GIS
systems also fit this case.
(null, F ) The site has. all geoprocessing components but none
of geodata. The geodata are separated from the gcoprocessing
and distributed in other places.
(D , null) This may probably exist as a data center.
Geoprocessing may be provided by other sites.
3. EXISTING SOLUTIONS
Based on the mentioned possibilities in distribution of
resources and components, there are various ways which can be
710
considered. Some of them have been implemented in various
industries and businesses.
Due to previos section the (null;null) and (D.F) possibilities are
equivalent ,because (null,null) manner only exist on client side
and (D,F) manner only exist on server side. But the others two
manner may exist on client or server side.
Two network strategies can support dynamic configuration of
distributed GlServices (Tsou, M. and Buttenfield. B.P.,2003).
The first strategy is object migration. where data or programs
move from one node to another. The transferred data may or
may not be deleted on task completion. In the second strategy,
remote connection establishes a communication channel
between two nodes, allowing data and services to be shared
across the channel. Either can be applied to distribute geodata
objects or GIS software components. Although the network
technologies used in object migration and remote connection
are quite different, the goal is the same, that is, utilizing
available computing resources across networks. To distribute
geodata objects dynamically (Figure 3). the objects can be
shared or copied to a requesting node. To share objects, the
network strategy used is remote connection to establish a link
between distributed databases. The connection is established
using SQL through Application Programming Interfaces
(APIs), such as JDBC. ODBC or OLE DB. The second
approach (object migration) utilizes an FTP protocol to actually
move the data object and save it on the requesting node's local
disk. Data migration may require both automated and manual
procedures for download and format conversion. Similarly,
either network strategy can distribute GIS software components
dynamically (Figure 4). GIS operators may be invoked
remotely, using Remote Procedure Calls. Other protocols are
also possible, such as Internet Inter-ORB Protocol (1IOP) or
Simple Object Access Protocol (SOAP). Technology
frameworks that currently support this approach include
DCOM, CORBA and Java RMI. It works as follows. A GIS
application sends a request to local component services (that is,
a service directory local to the node). The local service will use
its client stub to build a connection with another node’s (server)
Skeleton. The nodes temporarily adopt client and server roles to
accomplish the connection. The server-side completes services
then launch the required GIS component. This scenario
assumes that the service is not locally available, and that the
service directory can point to another node where the service
actually resides.
Figure 3: Two types of network connection for GIS software
components
[nternationc
The second
modules (the
process uses
procedure d
downloaded
binds with tt
supported b:
applets in a |
been widely
In the first
network .V
Geodata are
issues is infl
is network le
downloading
network traf
and then dow
each manne
development
to produce s
before the ru
ActiveX con
client GIS.
ActiveX con
In the thick
processing w
Figure 4: Tv
By combinir
strategy 1s ac
have user int
the results.
In this mann
inevitable es
high memory
the interactio
Both thin an
drawbacks. b
advantage of
Combination
à new paradi
As it is ment
distributed €
problems suc
Such movab
agent. Agen
Science that r
