4. Architecture

4.1. Overview

We propose the following architecture. On each host there will be a demon running. On one of the hosts there will be a specialized server running. The server will maintain connections with demons on other participating hosts. The scheme of this architecture is presented in Figure 1.

Figure 1. Overview of system architecture

Interserver communication aspects

On the logical level the architecture of the system is fully distributed. On each host there is a separate demon running. This demon is responsible for maintaining connections to all local applications and lunching local applications when necessary. These demons can establish Virtual Connections to other demons running on other hosts. Virtual Connections are established for particular application. These connection are used to exchange information between collaborating applications. See Figure 4a.

Figure 4a. Fully distributed configuration (logical level)

On the implementation level, howerer, the structure is slightly different. The requirement to record all system events in the database, causes that all event have to be sent to the demon connected to the database. In order to avoid message duplication, and simplify the session management, this server will be resending the messages to all session participants. The host running central server will also provide access to the database and services for user authentication and event logging. Such architecture will also enable controlling the whole system by events comming from the database. See Figure 4b.

Figure 4b. Central server configuration (implementation level)

In the first version of the system incoming messages will be sent to each application in particular session separately. In the future we plan to use multicast technique to increase server performance.

Another important element in the design is the host running HTTP server. Its task will be to serve applets (see point 4.2) and provide applications with data (for example, for GIS application).

Interapplication communication

The demon-application interface will be provided on local sockets and procedure calling basis. It will be responsibility of each application to read and process each message properly. We assume that each application will be started with a number of port assigned to it, passed as a starting parameter. It will be responsibility of the demon to provide valid port number and send messages to the application. Server must also be prepared for the case that application finishes abnormally (e.g. crashes). In this case connection must be closed properly and other applications notified.

4.2. Architecture details

Communication model

System components

Local Demons (Demons)

Local Demon is relatively simple piece of software. It is implemented as a plug-in in netscape browser. Its main task are maintaining two way communication between user applications, applets and Central Server, and lunching local applications.

Central Server

Central Server is the main communication element. All Local Demons communicate the Central Server. This server maintains the whole system state (Participants, Applications, Sessions). Its main tasks are routing of messages among applications participating each session and recording all events in the database. Central Server is written in Java and runs as an application. It uses JDBC standard to connect Oracle database system.

Local Applications

Local Applications running on a host will be connected to the Demon running on this host. Local Application can be written in any programing language. All Local Applications communicate with Local Demon by the use of sockets. The Demon is responsible for starting applications, routing messages to and from applications. This architecture will provide a seamless transmission of messages among applications. The application specific protocols are not interpreted by the communication system.

Java Applets

Java Applets are downloaded through the network from an HTTP server. They are executed inside Netscape browser. Communication between Java Applets and Central Server is maintained by the Local Demons. Java Applets communicate Local Demon by calling its functions (

Control Application

Control Application is a specialized application which serves as an interface to a user. Control Application is used to launch applications locally or remotely, create and connect existing sessions. This applications allows logging into the system. Structure of the Control Application depends on the user privilages giving a user only these features he/she is allowed to use.

Control Application communicates with the Local Demon. Through the Local Demon all the communicates to and from Control Application are sent.

Control Application is written as an Java applet. A small part of it is lanuched on the beginning giving a user a possibility to login to the system. Then the rest is downloaded from the http server.

4.3. Communication between applications

There are two modes of communication between applications:

1. Partner mode

In partner mode applications can communicate with each other symmetrically. All users can perform the same kind of actions. Applications using this pattern are Chat, Videoconferencing. However a logic master exists for each session. This master can decide, for example, if another user can join this session.

2. Master-slave mode

In master-slave mode there is one distinguished "master" application which performs activities. The other applications of the same type connected with "master" serve as slaves and display the activities perform by "master". There should be a possibility to change the master dynamically during the session if user privileges allow it. Applications using master-slave pattern are Visible Human, GIS and Search System.

4.4. Network services

The system will provide services of user authentication and event logging. These tasks will be done by Central Server which will maintain connection to the database.

Figure 3. Network services

Database will contain all user information. User privileges will be a part of this information. Depending on privileges granted, users may be or may not be able to initiate various actions (launching new applications, sending messages). See paragraph 4.6 for details.

There will be possibility to recreate the sequence of events in the system basing on information gathered and stored in the database. See paragraph 4.7 for details.

4.5. Session management

A Session is a group of application instances currently working together in collaborative mode. All applications belonging to the same session exchage information and share behavior. How particular application operates in collaborative mode depend on this application. See Chapter 3 for details.

Each application belongs to a session, even if it is not currently used for collaboration. In such case the session consists of this one application only.

In all Sessions there is one distunguished user which is considered to be a Master. Master of the Session has special privilages of controling the behavior of applications and/or contoling access of other users to this session. The privilages depend on the application type.

There are three possible actions which may change state of a session:

Creating a session

Session is created when a Participant launches a local application. On the beginning the session contains only this one application instance. The Participant becomes automatically the Master of this session. Other Participants may then connect to this session.

Joining an existing session

There are two possible ways of joining an existing session:

Leaving a session

When a Participant leaves a session there are three possible cases which need consideration:

4.6. User authentication and security policy

Each user of the system will have to identify himself to start working with the system. Identification will be based on the password associated with each user name. After verification each user will be granted rights specific for him. There will be the following types of rights:

The rigths to perform each of the actions mentioned above depends only on the User and type of application.

4.7. Event logging in the system

Each event sent by each application in each session will be recorded in the database. It will be possible to use information stored in the database to restore system activity in the given period of time or between given users or applications.

4.8. Events in the system

We assume that the following events will be used by the application being curretnly part of the system:

Chat : text strings, control information
Visible Human : coordinates, URLs, control information
GIS : camera positions, URLs, control information
Videoconferencing : connection events, control information
Search System : search criteria, results (HTML), control information