Given by Tom Jurga at Defense of 5 CIS Master's Theses on Dec 15 1997. Foils prepared April 13 98
Outside Index
Summary of Material
Session Management in TANGO System - about 30 minutes
|
Other Session Management mechanisms - about 10 minutes |
Questions - 10 minutes |
Outside Index Summary of Material
Tomasz Jurga |
NPAC |
Syracuse University |
Master Thesis |
Session Management in TANGO System - about 30 minutes
|
Other Session Management mechanisms - about 10 minutes |
Questions - 10 minutes |
Web Collaboratory System
|
Session
|
Session Management
|
What is it?
|
Local Daemons
|
Central Server
|
Local Applications
|
Java Applets
|
Control Application
|
Web Technologies used
|
TANGO system is arbitrarily extensible via set of APIs
|
A session is a group of application instances currently working together in a collaborative mode |
All applications belonging to the same session exchange information and share behavior |
How a particular application operates in the collaborative mode depends on the characteristics of this application type |
The modes of participation in a session:
|
Master can be transferred to another participant |
Ownership can not be transferred |
User A involved in two Chat sessions:
|
Master/slave logic:
|
Sess 1 |
Sess 2 |
A |
B |
C |
D |
Displaying the accurate and consistent information about all established sessions on the Graphical User Interface panel on all machines |
Generating a Session Management action, which may change the state of a session |
7 Session Management actions in TANGO |
"core" actions:
|
"floor control" actions
|
Enables exchange of messages between the applications. |
There is a following procedure of sending a message:
|
The Central Server forwards the message to the addressee, i.e. to another Local Daemon, or to a group of Local Daemons |
The communication protocol consists of several messages. They can be divided into two groups:
|
Graphical User Interface to the TANGO system |
Session Management tool providing the necessary functionality to control the behavior of other applications integrated with the system |
Source of different information (e.g. user name, host name) for other TANGO applications |
Place in TANGO
|
Log in/out |
Internal TANGO Mail |
Session Management actions
|
Control Application displays the following lists:
|
Several Java applets located on one Web page |
Communication among applets by use of interfaces |
The design influenced by:
|
Very simple and unattractive graphical design |
Unintuitive Session Management mechanism - generating any action requires 2 or 3 mouse clicks |
No support and no guidance from Control Application for Session Management |
Most new users totally confused when using this application |
More time for the design and implementation |
Improvement goals:
|
Improved Session Management mechanism
|
Improved GUI - Symantec package used |
Full compatibility between the 1st and the 2nd versions of Control Application |
TANGO - no flexible customizability mechanism |
TANGOsim - example of how much effort was necessary to customize CA for 4 Command and Control Applications |
TANGO 2 - fully customizable by:
|
JCT - The Java Collaborator Toolset of Old Dominion University |
AWT of the JDK is replaced by a custom collaboratory toolkit to provide event and data sharing |
Advantage: simplicity of application porting. |
Too restrictive approach: JCT is shared X written in Java |
One session per application type allowed |
Habanero collaboratory modules are Java applications: no software downloadability, but independent from unstable Web browsers and their performance limitations |
Habanero session model resembles TANGO 2 room paradigm:
|
The system built with use of Java and supports peer-to-peer (no floor control) communication among processes spread across a network |
Applications (dapplets) can exist without being linked to any session |
Creating a session means establishing a temporary network of dapplets of any type |
A dapplet can participate in many different sessions |
Due to a loose integration between a dapplet and a session, this scheme of communication is very generic and flexible |
The InVerse communications infrastructure receives data from applications and disseminates it over the network to the InVerse server and/or to appropriate destination client hosts. |
Scalable infrastructure: may adapt itself to the available network bandwidth, observed network latency, availability of IP multicast routing, and installed security firewalls around user hosts. |
A user can define a group of receivers (Individual, Private, Public etc) for a particular piece of data coming from his/her application. |
Reliable or unreliable sending of data |
Data Security - the system allows applications to establish secure communication sessions, data may be encrypted before sending |
Session Management tools less powerful (no remote operations) |
Session model:
|
Session Management Actions:
|
Opening / Closing of an application remotely |
Floor Control mechanism |
Sending the update information about the state of sessions to the users |
Customizability of Session Management tools |
Saving the state / the definition of a session |