mercial DBMS systems) and data conversion appli-
cations.
2.2.2 Delta-X Operation
Clients' data - typically maps - can come in different
source formats, such as CARIS or ARC/INFO, and
from different source systems, such as UNIX work-
stations or PCs. A client stores data which it wants
to share with other clients on one of the servers in
the federation, where it can be accessed by other cli-
ents. A server is essentially a database server which
is also capable of converting data from client into an
internal Delta-X format and vice versa, and store the
converted data in its database. When another client
wishes to import this data, the Delta-X server trans-
lates the data into the target client’s format and
transfers the data to the target client. The target for-
mat can be any common GIS format and the target
machine can be either a UNIX workstation or a PC.
A server handles requests both from clients and
from other servers in the federation. A transaction
starts on one server. However, it may migrate to
another server to complete a conversion from one
data format into another, or to finish a data transfer.
When a GIS wants to import or export data to Delta-
X, it relinquishes control to the Delta-X client. The
Delta-X client initiates the data transfer/conversion
transaction. During data import operations, the GIS
will use the data imported in the transaction after a
transaction has been completed.
2.2.3 Delta-X Clients and Servers
Delta-X has a client component and a server compo-
nent. On a client, Delta-X provides a GUI that
enables GIS users to start and control transfer/con-
version transactions and communicates with the
server. On a server, Delta-X provides the client-
server and server-server communication software, a
module that transfers data, a network management
agent, an interface to a database, and a set of data
conversion routines. The server's network manage-
ment module facilitates setting of server's opera-
tional parameters, authentication keys, the
registration and de-registration of a server in the
Delta-X federation. It also raises alarms to network
management when the server malfunctions. À server
can leave the federation only if there are no transac-
tions in progress on the server.
356
Data on the server can be stored in any commercial
database model - relational or object-oriented. The
exact internal format of data stored in Delta-X sery-
ers is database-specific, but all database servers
share the same data model and logical schema, and
they can store the same types of data. The internal
database schema used at a particular server is trans-
parent to all other servers in the federation. A sepa.
rate database interface module adapts each internal
database schema to a uniform data interface used
within Delta-X. Conversion routines are GIS-spe-
cific. Note that the conversion routines and the data-
base schema are the only entities in Delta-X that are
specific to geomatic data and GIS systems.
Note that the clear separation of data storage func-
tions (the Delta-X server) from data processing
functions (GIS) in a network not only facilitates data
sharing and creation of logically organized applica-
tion-specific data repositories, but it also enables us
to take advantage of the latest development in both
of the DBMS and GIS worlds. For example, the
RDBMS currently used in the Delta-X prototype can
be replaced with an OODBMS without any impact
on the clients and other servers. In fact, different
Delta-X servers using different database manage-
ment systems can seamlessly co-exist in a Delta-X
federation and exchange data with each other. Simi-
larly, Delta-X can support a new type of GIS without
the need to change the internal data interchange for-
mat and schema. These features allow different
organizations with different data processing systems
and/or architectures to join the same Delta-X federa-
tion and share data with each other.
2.3 The Communication Framework of
Delta-X
The mode of communication between a Delta-X cli-
ent and a Delta-X server or between Delta-X servers
is asynchronous. Delta-X supports conversational
transactions, which proceed as follows. A client
connects to a server, requests a transaction, and then
disconnects from the server. When the server fin-
ishes the requested transaction, or when it has to
report the transaction’s status, the server connects to
the client and delivers requested data or reports the
status.
The main reason for introducing the asynchronous
communication paradigm into Delta-X is the long
duration of the conversion/transfer transactions. À
typical transaction can take many hours to complete
and it woulc
tion betwee
network re:
transaction.
The async
server and
First, the se
transactions
out of comi
nous comm
itates nestin
For exampl
a certain se
once in a v
report On |
transaction
to perform |
also connec
status repor
does not ha
server and :
However, tl
that the tra
where to se
Delt
|< El
| Spe
Figure 2:
