at the user’s 
he MetaView 
tes the proper 
a resides. The 
uring its start- 
-rver and que- 
elta-X federa- 
data is present 
the server and, 
| pre-view the 
lient's display 
al characteris- 
ta) as well as 
ssociated with 
ifies the trans- 
of the desired 
| data (i.e. the 
^ names), the 
| ARC/INFO), 
vert and trans- 
machine does 
> on which the 
e.g. it can be 
, but the user 
ation machine 
is transaction, 
- messages for 
vill notify the 
leted and the 
the specified 
machine. The 
xample ARC/ 
the GIS. 
ort data to the 
the MetaView 
1e data should 
| update rights 
the transaction 
mat, and loca- 
mes), the des- 
ansaction. The 
r this transac- 
1e transaction. 
iser when the 
sired data has 
  
  
To Delta-X 
Server 
4 
  
Delta-X Client 
  
Data Transfer and 
  
  
Administration 
  
  
  
  
|. Conversion GUI | GUI. 
Network 4 
Delta-X Data Communication Database 
Display zm Registration 
  
  
  
  
  
  
  
  
  
Transaction 
Control > 
  
  
  
> Transaction 
Management 
Delta-X 
Administration 
  
  
  
  
  
  
  
Transaction 
Status Display 
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
Figure 4: The Delta-X Client 
5.0 Comparison with Related Systems 
Compared with on-line transaction processing SyS- 
tems (TPS), which typically process thousands of 
simple requests, each of which updates the shared 
data and the state of the TPS, and which have strin- 
gent requirements for atomicity, consistency, isola- 
tion and durability (ACID), the architecture of 
Delta-X is designed with slightly different criteria in 
mind. 
In particular, Delta-X transactions are long-lived - 
they can take about an hour to complete on a power- 
ful workstation. Therefore, mechanisms must be put 
in place for the user to inquire about the status of the 
transaction and to control the flow of the transaction. 
Moreover, if possible, Delta-X must allow concur- 
rent accesses to data for as many transactions as pos- 
sible so that reasonable throughput and response 
time of the system is guaranteed. This requirement 
can be easily met, as most accesses to Delta-X data 
are read-only. 
Second, Delta-X supports versioning of data - each 
update creates a new version of the data. Thus, data 
consistency problems are avoided. 
Finally, the main performance criteria for Delta-X is 
the throughput of the system alone, as opposed to 
both throughput and response time in a typical TPS. 
However, Delta-X avoids waiting and queueing for 
data wherever possible, so that the response time for 
a transaction is given by the duration of the transac- 
tion, not by the time the transaction has to wait for 
data (which could be several hour in the worst case). 
On the other hand, requirements for system avail- 
ability, user authentication, atomicity of operations 
(mostly updates of the MetaView browser database) 
are similar for transaction processing systems and 
Delta-X. 
6.0 Future Work 
The prototype Delta-X implementation will be grad- 
ually extended in the following areas: 
1. The support for high security will be added to 
make Delta-X C2-compliant. 
2. Delta-X servers will be made fault-tolerant and 
highly available by adding hot stand-by servers 
and/or introducing data replication across the 
servers in the federation. 
361