paradigm of Delta-X is also that of a federated data- 
base. That means, servers in a federation form a 
community which another servers can join, or which 
the servers in the community can leave. When a 
server joins a federation, it makes all or some of its 
data available to other servers and clients in the fed- 
eration. In turn, it also gains the right to access data 
on other servers. Access to data on servers within 
the federation by clients is subject to authentication 
procedures. 
This paper examines architectural and implementa- 
tion issues related to Delta-X, focusing on the design 
of the Delta-X server and on the design of the Delta- 
X client for remote operations and for controlling 
remote transactions. The paper is organized as fol- 
lows. Section 2.0 describes the basic architecture of 
Delta-X and gives the rationale for its design deci- 
sions. Section 3 describes the Delta-X server and its 
services. Section 4 describes the Delta-X clients and 
their services. Section 5 compares Delta-X to other 
client/server distributed data management and 
movement architectures. Future work is described in 
Section 6. We conclude with Section 7. 
2.0 The Architecture of Delta-X 
2.1 Requirements and Functional 
Specification 
Delta-X is intended for two types of applications: 
First, it can be used in large geographically distrib- 
uted organizations in which different departments 
share data with each other and which use a multitude 
of mutually incompatible software packages and/or 
machines. An example of such organization is a 
government with its multiple levels (federal, provin- 
cial, and municipal). 
Second, Delta-X can be used in organizations which 
sell data and their customers.(e.g. DigiMap) A data 
producer organization can consolidate their data 
management and storage and reach the widest possi- 
ble customer base (which uses a variety of different 
GIS systems running on different machines). Such 
organization can distribute the Delta-X software 
among its customers, and store the software on one 
or more Delta-X servers. A data consumer organiza- 
tion on the other hand, can obtain data from any data 
producer in a format that can be used by the soft- 
ware deployed in the organization. 
In both types of applications, each shared data has 
one owner and data is typically updated only by the 
owner (which is the producer of the data), but con- 
currently read-accessed by many consumers of the 
data. Most transactions in the system are read 
accesses to the shared data which do not update the 
data or the state of the system. For write accesses to 
data, the system must support data check-in and 
check-out - data is checked out for an update (which 
can take several weeks to complete) and checked 
back in after the update has been finished. 
The system must support a high degree of concur- 
rency, as many transactions accessing the same data 
can be active concurrently. The system must also 
give the end-user the highest possible degree of con- 
trol over a transaction - a transaction must “feel” as 
if it would execute on the end-user's machine. On 
the other hand, the requirements for roll-back and 
recovery are not so stringent - if a transaction fails, 
the end-user will restart it, and the system must only 
recover used-up disk space. Recovery means to re- 
start a transaction (from a given check-point). 
To satisfy the above requirements, Delta-X must 
handle three main tasks. First it must handle the stor- 
age of the shared data. Second, it must handle the 
conversion of shared data, stored in an internal data 
interchange format, into all desired GIS formats so 
that the data can be used by different target systems. 
Delta-X also must handle the conversion of data 
from target systems into the internal data inter- 
change format. Third, Delta-X must facilitate the 
transfer of converted data from Delta-X to a target 
system and the transfer of data to be converted and 
stored in Delta-X from a target system to Delta-X. 
A universal data interchange format makes Delta-X 
easily extensible: each new GIS data format only 
requires two new conversion routines - to and from 
the data interchange format. Without the data inter- 
change format, adding a new data format from a new 
GIS to Delta-X would require to implement conver- 
sion routines to and from all formats already sup- 
ported by Delta-X (Supporting n different data 
formats would require n? conversion routines). 
2.2 The Architecture 
The architecture that handles all the above tasks is 
shown in Figure 1. Delta-X handles the above tasks, 
performing multiple client-server roles [4]. First, 
Delta-X servers control the data storage in commer- 
354 
  
Delta 
  
7, 
Delta-X CI 
Figure 1: | 
cial DBMS 
server trans. 
message anc 
base and/or 
clients. Thir: 
functions, su 
internal dat: 
acts as a pro 
produce or c 
tion of data i 
2.2.1 Delt: 
As can be se 
pled networl 
Clients and s 
cluster. Clus 
WAN, whic 
system. Serv 
directly to tk 
to one of th« 
clients and : 
bone WAN, 
er servers 
Communica 
federation is 
backbone W 
tion from an