on the way toward consistent large-scale object
orientation. But we are also in this transitory stage. The XX
framework itself belongs to proper object orientation, it can
address proper objects distributed over a network, but it is
also suited to control independent server modules
designed as ComponentWare.
2.3 Distributed Objects and Hybrid Components
XX consists of three application-independent components:
a GUI-component (UX), a graphics-component (GX) and a
communication- and system-controlling (supervisor)
component (SX). All these are written in C++. Existing
applications or modules (mainly in FORTRAN 77) act as
"server components” running within separate processes.
The connection between these server components and
UX/GX is established by so called agents. These are
application specific components written in C++.
The general structure of an application built around XX is
as follows:
| <--> UX,GX
Main <--> SX |
| <--> agents <--> server components
< C++ > <---- hybrid ---->
A user action (e.g. a mouse click at some button "ISO")
results in a message sent by UX to the ISO-specific agent
which delegates the necessary computation task to the
relevant server component(s). In a similar way, agents
communicate among themselves by sending/receiving
messages, thus composing the product (e.g. some view)
as requested by the user and as corresponding to the
current stage of processing.
Message-passing is controlled by the module SX, and it is
performed by means provided by it. Message passing is
asynchronous, so that intensive computation will not block
the user-interface.
Message passing is built upon an Object Request Broker
(ORB) which conforms to the CORBA 2.0 standard of the
Object Management Group (OMG), an orginazation who's
aims are the standardization and adoption of object
technology (all leading companies have joined this group).
Using an ORB allows for distribution of components on
different machines in heterogeneous environments. The
commercially available ORB libraries ORBIX and
ORBELINE have been tested to build two versions of SX.
SX supervises the integrity of the running system and
takes care of proper handling of any failures in it. One of
its means to do so is to continuously supervise the proper
closing of message loops.
2.4 Graphical User Interface
On the one hand, in the spirit of object orientation, users
should communicate with the objects visible to them
directly, and this communication should reflect the state of
the objects. On the other hand, however, "development,
and sometimes fashion, do not stand still, ..., further
changes are following in rapid sequence, considering, e.g.,
the exploding importance of multimedia technology. It is,
therefore, imperative to separate the GUI from the classes
to be controlled by it. There is an interface necessary,
somewhat similar to the resource file statements as
originally formulated by IBM for the PM. Interpreting such
statements, the [component UX] can compose the
graphical user interface to appear on the screen in using
the latest cross-platform development tools and libraries.
This way, the user interface can be kept to correspond,
though with severe compromise, to the fashion of the time"
[Mo92]. The most recent event to proove this point is the
appearence of WINDOWS 95 with a new GUI: such
changes should not enforce re-writing too much code in
large applications such as SCOP.
To create a solution for this dilemma took (and still takes),
indeed, a major sacrifice of capacity in research and in
programming by this institute. One is forced to be critical of
the current state of software technology not providing
proper solutions in this general-purpose realm. (A detailed
analysis of this dilemma, and an elegant concept for a
world-wide solution is given in [Co95]). Standards for GUI
interfacing are plainly missing.
Here, a very short outlay of our solution follows, useful to
any thoughtful user of SCOP (or of any other system)
under XX:
- The Main module, when started by the user (or by
some other application) starts the supervisor
component (SX) of the XX frame, and transmits to it
the description of the main GUI window of the
application.
- SX starts the user interface component UX, and
transfers to it the description of the main window.
- UX interprets (at run-time) the description of the main
window, displays it on the screen, and waits for user
action(s).
- According to the user actions, UX sends messages via
SX to the agents concerned (known to it from the
description it received from Main). If not yet running,
SX starts the corresponding agent(s), and passes the
message(s) to them.
- In many cases, agents are going to send to UX
descriptions for subLevels of user communication, e.g.
to collect parameter or other entries from the user;
these are then interpreted and displayed by it. - In other
cases, the agents will compose services of the hybrid
server modules to products as requested by the user.
For this, SX will start the corresponding server
component(s), send it(them) some control information
(e.g. directives to existing SCOP modules, performing
the task in the background, running in batch mode).
- Graphics produced will be sent by the agent(s) to the
GX component of XX (see below). Error messages,
summaries etc. will be displayed by means provided by
UX.
The rest can be guessed from the above, we hope.
Specifications for the user interface are written as uxDL
("user interface Definition Language) statements. uxDL i$
570
International Archives of Photogrammetry and Remote Sensing. Vol. XXXI, Part B4. Vienna 1996
spe
of
indi
fun
‘nul
etc.
adc
ton
uxL
anc
me:
in t
UX
kee
The
doir
plat
Dis|
as |
plat
app
The
stat
Stat
stat
stat
func
data
man
disp
obje
WIN
type
natu
will ¢
to be
othe
douk
the «
Switc
This
they
itself
creat
"runr
amoi
meni
the c
capa
choic
Shac
as ot
comp
state
(a wii
in mc
there
The «
