This document describes collaboration platform which will be used by members of the staff dealing with emergency situations.
The main goal of the project is to provide the user with means to share all the available data efficiently. To do this we have to introduce a way to connect all the participants and provide them with utilities to pass the data and collaborate.
The system will consist of a number of separate applications that will ... (enum)
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.