VERSION: 1.02 KW
This document is a description of the collaboration platform which will be used as a communication backbone in the Collaboraative Interaction & Visulalization project pending in NPAC. The main goal of the whole project is to develop a prototype of the Command & Control Center. Such system is must satisfy multiple requirements and implement various functions. It is also possible that various elements of the whole system will run on different platforms.
The communication platform must provide means to efficiently share data, interaction among applications running on the same or different hosts, and constant monitoring and recording of system events in a database.
The system will consist of a number of separate applications that will fulfil various tasks in the system. The structure of the system does not depend on the applications connected to it. The system implements a generic set of communiction mechanisms. These mechanism allows applications to comunicate one to each other. Application independency guarantees that the communiction system will be able to serve any applications that will be developed in the future and added to the system.
One of the main assumptions while developing the system is that applications may be written in any programming language and may run on any hardware or software platform. Keeping this in mind we use only the most generic system communication mechanism.
The system to be provided has to facilitate all these task and provide efficient
way for the emergency staff to manage its responsibilities.
This document describes the server system which will be used to integrate existing and future applications into one collaborative framework. Its tasks should be the following
The whole system will consist of the following applications:
....
Chat and bulletin board applications will be applications used to share
the text-based data.
Participants using chat will be connected on-line, which means that each
message send by one user will be seen immediately by all other users connected.
In bulletin-board message there is no need to maintain direct connection
between users. When sender sends a message it is kept in the system and
may be read by the receiver in the future.
There is also possibility to introduce other applications using the same
communication pattern. For instance whiteboard application may behave in
the same way as chat, but instead of text messages with geometric shapes
will be transmitted.
Visible Human application is used in telemedicine. Its task is to provide
people with images of human body. It may be used in examining and describing
casualties from the place of hypothetical crisis place. In collaborative
mode one person point at various parts of human body and the other participants
may see the same places.
Geographic Information System is a tool used to display and examine real terrain with use of computer. Users of GIS may walk virtually and examine areas of interest. When application is used in collaborative mode one user performs actions and others may see its results.
.... KW
This system will be used to provide participants with real time video and
audio communication.
The search system will be used to provide participants with access to the
news. Data source for the system will be information provided by media.
Participants will have possibility to search information by keywords, dates
and so on. In collaborative mode one person will have possibility to show
found information to other users.
Possible solutions
Because of the variety of applications which will make use of the system
it is necessary to find the common way for them to communicate. Various
technologies may be considered, e.g. common file access, interprocess communication
and sockets. Finally we have chosen socket because of its flexibility and
good performance.
We assume that it will be possible to incorporate into the system all applications
which can make use of sockets. Local socket channels will be used to pass
messages between various client applications and the system.
Applet
Central server
Control application
Demon
Event
Participant
Virtual connection
We propose the following architecture. Each host participating in the system
will have a demon running. The server will maintain connections with other
participating hosts and provide applications with services such as message
passing. The scheme of this architecture is presented in figure 1.
Figure 1 Overview of system architecture
Applications running on the host will be connected to the demon residing
on the local machine.
4.2. Java applets
Figure 2 Interapplet communication
Special case are Java applets which are downloadable through the network
and cannot open socket connection to the host they are on. We propose that
applets make connection to the demon residing on the machine they are originated
from instead of getting connection on the local machine. One of machines
in the system will have HTTP server installed which will serve HTML documents
with embedded applets. Running applets will be connected to the demon on
this machine. The details are showed in picture 2.
Because all applets will be connected to one demon, it will not be necessary
to pass the information through the Central server. However it must be notified
about all events to store them in the database.
From the application point of view the network of demons will be seen as
a single entity. Message passing between demons will be transparent to the
applications.
The system will provide services of user authentication and event logging.
This task will be done by central server which will keep connection to the
database.
Figure 3 Network services
System will maintain user information with privileges. Depending on privileges
granted, users may do various actions (launching new applications, sending
messages). See point 3.8 for details.
There will be possibility to recreate the sequence of events in the system
basing on logged information gathered before. See point 3.9 for details.
Two ways if interserver communication have been considered. One is fully
distributed architecture in which each of demons maintains state independently
and communicates with others when necessary. (See figure 4a).
The other design employs central server which is used to create virtual
connections between demons and provide message passing services. (See figure
4b).
We chose the second design because of its clearer design. The central server
will need much simpler protocol and should make the system more robust.
In the first version of the system incoming message will be sent to each
member of the virtual connection separately. In the future we plan to use
multicast technique to optimize server performance.
The host running central server will also provide access to the database
and services for user authentication and event logging.
Another important point in the design is the host running HTTP server. Its
task will be to serve applets (see point 3.2) and provide applications with
data (for instance worlds for GIS application). Because all applets will
be connected to demon on this host, its design will have to be different
(no need to communicate through central server). See 3.2 for details.
Figure 4a Mesh configuration
Figure 4b Central server configuration
The demon-application interface will be provided based on a local socket.
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 the responsibility
of demon to provide valid number of port and provide 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.
There will be two ways of participating in collaborative work:
remote launching of application on other participant machine
joining already running application
This actions will be performed with use of the Control Application accessible
for all users. Both ways will be associated with privileges to use them
in case of each application.
We can identify 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, Video conference
1. 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.
We assume that if application which is currently master of the session gets
disconnected all slave applications also terminate.
The following events may be identified for the application currently being
part of the system:
Chat text, pictures
Visible Human coordinates, parts of the image
GIS control events
Video conference connection event
Search system criteria, results (HTML)
Control application user login, application run
Each user of the system will have to identify himself to start working.
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 rights:
launching application in single user mode - in this mode user can use application
without any collaboration with other participants. It is possible however
for other participant with sufficient rights to launch another application
of the same type and connect to the user to monitor his activities.
joining the session - this property allows to connect local version of the
application to already running application(s) of the same type on remote
hosts. By using this user becomes part of the session.
launching the application on another computer - this property allows to
launch application on remote computer. The remote application joins the
session with the local version automatically. The local application runs
in master mode.
using application in master mode - when applications run in master-slave
pattern (see 3.6) this property allows to dynamically change the master
of the session.
The right to launch application locally depend on the user and type of application.
The three other rights (joining the session, launching application on another
computer, user application in master mode) are granted on the base of three
parameters (user, remote user, type of application).
Each event send between two application will be recorded in the database.
There will be also possibility to store the activities of application working
in single user mode.
There 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.
Virtual connections will be managed by central server. The information about
virtual connection will contain the following data:
virtual connection id
type of application
list of connected hosts
master (if in master-slave mode)
All this information will be stored in the database. The proposed table
scheme is the following:
id master application
id client
1. user types username and password to Control Application
2. demon send the information to Central Server
3. data is verified in the database
4. Central server returns user rights to Control Application
5. Central server returns existing connections that user has rights to connect
to
user chooses application in Control Application
information from Control Application goes to the demon
demon sends the information to the Central server, information is written
to the database, virtual connection is established
demon launches proper application with number of port
1. user chooses the session from Control Application
2. information is sent to Central server through the demon
3. Database checks if master for this session exists, if yes he is notified
4. If master agrees for joining another virtual connection is created and
written in the database
5. Demon on initiator machine is notified
6. Demon launches the application and starts delivering messages to it
7. user chooses remote launching option in Control Application
8. remote user is notified with a message that application is about to start,
he must confirm it
9. new virtual connection is created and application is started
10. initiator becomes a master of this session if application runs in master-slave
mode
11. user chooses change to master for a given session in Control Application
12. all other participants are notified
13. information about master in the database is updated
14. user start new flow of data
The implementation of the demons will be done in Java language. This language
is chosen because of its good networking capabilities and possibility of
running on various platforms without need of changing the code.
Database access will be implemented with use of JDBC standard and WebLogic driver for Oracle RDBMS.