hared data has 
ed only by the 
data), but con- 
isumers of the 
stem are read 
not update the 
ite accesses to 
check-in and 
update (which 
) and checked 
hed. 
ree of concur- 
the same data 
em must also 
degree of con- 
must “feel” as 
| machine. On 
roll-back and 
nsaction fails, 
tem must only 
' means to re- 
-point). 
Delta-X must 
andle the stor- 
1st handle the 
1 internal data 
IS formats so 
arget systems. 
rsion of data 
al data inter- 
facilitate the 
-X to a target 
'onverted and 
to Delta-X. 
akes Delta-X 
. format only 
- to and from 
he data inter- 
at from a new 
ment conver- 
already sup- 
ifferent data 
utines). 
bove tasks is 
above tasks, 
s [4]. First, 
> in commer- 
  
  
  
  
  
  
     
  
Any ey C7 uy 
Delta-X ClientDelta-X Client 
    
  
  
  
  
  
  
   
   
[^ 
DD qe «uu a 
Delta-X Client Delta-X ClientDelta-X Client 
  
Figure 1: The Architecture of the Delta-X System 
cial DBMS systems. Second, Delta-X is a client- 
server transaction processing system - it handles 
message and data exchange between Delta-X data- 
base and/or other specialized servers and Delta-X 
clients. Third, Delta-X performs specialized servers 
functions, such as data conversions to and from the 
infernal data interchange format. Finally, Delta-X 
acts as a proxy client on behalf of GIS systems that 
produce or consume data - it is the source or destina- 
tion of data in Delta-X transactions. 
2.2.1 Delta-X Structure 
As can be seen in Figure 1, Delta-X is a loosely cou- 
pled network of Delta-X servers and Delta-X clients. 
Clients and servers attached to the same LAN form a 
cluster. Clusters are connected to each other via a 
WAN, which forms the backbone of the Delta-X 
system. Servers and/or clients can also be connected 
directly to the backbone WAN or, via a dial-up line, 
fo one of the cluster servers. The set of all clusters, 
clients and servers connected directly to the back- 
bone WAN, and clients remotely connected to clus- 
er servers forms the Delta-X federation. 
Communication between clients and servers in the 
federation is IP-based (both over the LAN and the 
backbone WAN). Any client can request a transac- 
tion from any server in the federation. 
A dedicated server in a cluster performs name and 
authentication services for all clients in the cluster. 
A server can also perform name and authentication 
services for clients remotely attached to the server. 
Any server on the cluster can cache data from 
remote servers. Although having a dedicated server 
for certain functions, a client can connect to and 
request data from any server in the federation. 
A complementary system, the MetaView spatial 
browser [2] stores the meta-data on the databases in 
the federation. However, MetaView's function is not 
limited to Delta-X. A special server, the DxMaster 
monitors and coordinates the activities of servers in 
the fedration. When a server wants to join or leave 
the federation, it contacts the DxMaster, which 
updates its configuration and broadcasts the configu- 
ration tables to the rest of the servers in the federa- 
tion. The DxMaster is duplicated for high 
availability. 
Delta-X takes the three-ball approach to transaction 
processing [3], where presentation services, transac- 
tion workflow, and applications are run in three sep- 
arate processes, usually depicted as balls. The 
presentation services are performed by Delta-X cli- 
ents. Transaction workflow is controlled by dedi- 
cated modules in Delta-X servers. Applications are 
the Delta-X data repositories (built on top of com- 
355