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
Applications running on a particular host will be connected to the demon residing on this host. This architecture will provide a seamless transmission of messages among applications. The application specific protocols do not influent the communication system.
The protocol used in communication between applications and the demon is described in details in chapter 7.1. The demon algorithm is given in 7.5.
Figure 2. Interapplet communication
A special case are Java applets which are downloadable through the network from an HTTP server and cannot open socket connection to the host they are running on. These applets make connections to the demon residing on the machine they originate from, instead of getting connection on the local machine. One of hosts 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 communication architecture is presented in Figure 2.
All Java applets will be connected to a separate demon. Messages sent by them will not go through the Central Server. However it must be notified about all events, to be able to store them in the database.
From the application point of view the whole structure composed of demons and Central Server will be seen as a single entity (behaving like one demon). 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 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 do various actions (launching new applications, sending messages). See paragraph 4.8 for details.
There will be possibility to recreate the sequence of events in the system basing on logged information gathered before. See paragraph 4.9 for details.
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 event 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 member of the virtual connection 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). 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 4.2 for details.
The demon-application interface will be provided based on local sockets. 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.
Session is a group of application instances currently woring in collaborative mode. See Chapter 3 for details.
There are three possible actions which may change the state of the session:
Session is created when an 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.
There are two possible ways of joining an existing session:
When a Participant leaves a session there are three possible cases which need consideration:
We can identify two modes of communication between applications:
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
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.
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 : camera positions, URL-s, control events
Videoconferencing : connection event
Search System : criteria, results (HTML)
Control Application : user login, run application
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.
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.