Given by Krzysztof Walczak at NPAC Seminar on 27 August 97. Foils prepared 24 Nov 97
Outside Index
Summary of Material
Tango2 is a state of the art Web based Collaboration System |
This describes the principles and design of next version of Tango called Tango2 |
Tango2 is targeted at release April 98 |
Tango2 has a more sophisticated multi-room model than original Tango1 |
but still supports several different client application languages |
The basic principles are followed by discussion of Client Daemon and the Server |
Outside Index Summary of Material
Overview of the system |
NPAC, August 27, 1997 |
Krzysztof Walczak |
The same Team of developers is doing the same project once again |
We use better technologies which were not in place when Tango1 was developed |
Lack of scalability |
One-server system; no connections |
Plug-in (installation) required |
No synchronization methods |
No application initial state |
Fixed Control Application |
No user-defined spaces |
Difficult to use API |
Communication protocol not always reliable |
Multiple independent servers |
No plug-in |
Room paradigm |
Contents-server independence |
Improved protocol |
New communication mechanisms |
Access restrictions |
Compatible applications |
Communication between different applications |
No distinguished Control Application |
No Master |
Event and method-based APIs |
Servers are the basic collaboration element |
Servers are independent |
Servers are used for collaboration - not contents delivery |
No server-server communication |
One user can use only one server at a time |
daemon implemented as an applet |
VeriSign signing |
Signed daemons can communicate with other servers and standalone applications |
No installation required! |
We can control all software versions! |
Room is an abstract construct which can separate sets of Tango users |
Rooms are used also for environment customization |
Rooms are linked |
Rooms are gathered into communities |
Rooms and communities are files on an HTTP server |
Each Tango2 user must be in a room |
Server does not provide any contents - it maintains only a list of rooms |
All contents including room configuration, room description, community configuration, and user authentication is stored on HTTP server |
Tango |
Server |
HTTP |
Server |
RCF |
CCF |
CAF |
RDF |
N |
daemon |
SCF |
LACF |
N |
D |
D |
Tango |
Server 1 |
Tango |
Server 2 |
Control |
Application |
Appl 1 |
Appl 2 |
Appl 3 |
Appl 2 |
Server Configuration File - SCF |
Community Configuration File - CCF |
Room Configuration File - RCF |
Community Authorization File - CAF |
Room Description File - RDF |
Typically applications are closed when the user changes a room |
In some communities different rooms may use the same applications |
Restartable applications are applications which may remain when the user changes the room |
Session is the unit of collaboration |
Room is the unit of visibility |
Community is the unit of authorization |
Constraints: |
Rooms and sessions cannot be shared among servers |
Better, more reliable communication protocol |
Acknowledgement mechanisms |
Operation sequences |
Point to point communication possible |
Filtering of messages |
60 messages instead of 17 in Tango1 |
Hierarchical polling mechanism |
Server checks whether all daemons are alive |
daemons check whether all applications are alive |
Not responding applications or daemons are killed |
Tango2 supports message passing and shared variables for communication |
Shared variables is a new mechanism which enables:
|
Variables are identified by names |
Each variable has an owner. Owner can be:
|
Each variable has a scope. Scope can be:
|
Variables are locked in alphabetical order |
Lifetime of a shared variable depends on its owner and scope |
Lock is the part of the variable which is used for access synchronization to the variable |
Locks can be used as independent locking mechanism - the value is ignored |
Lock can have value of N, S, or X |
In case of S lock value a set of users is associated with the lock |
In case of X lock value one user is associated with it |
Value is the part of variable which is holds the contents |
Anything which is serializable can be a value |
Server does not interpret the values in any way |
Serialization used for transport |
Security issues |
Some of the applications have predefined sessions which they should join |
Predefined session is a parameter of application |
Start-up applications join predefined sessions |
Predefined sessions are identified by names |
JOIN (session) - owner controls the joining process for the session |
TERMINATE (session) - owner is asked for permission to terminate an application |
MASTER (session) - only messages from the owner are distributed |
ENTER (room) - owner decides if other users can enter the room |
Access restrictions defined for Community |
Configuration files stored on HTTP server |
User verification by Login Applet |
Possible access policies:
|
Special Login Applet for user authentication |
Application Type consists of:
|
Application with the same application group can be in the same session |
All applications in the same application group implement the same protocol |
Different applications can communicate by the use of variables |
Only room and server variables can be used for such communication |
Notification about update of a value is sent to all registered applications |
... |
TangoDeveloper1: |
I think Control Application has to do this ... |
TangoDeveloper2: |
I told you so many times: THERE IS NO CONTROL APPLICATION!!! |
On the other hand, Control Applications should be able to do it ... |
... |
There will be NO Control Application |
There will be many Control Applications |
All applications will be Control Applications (more or less control) |
Each application can be more or less „control" by registering with appropriate control-type |
Passive control types: USERS, SESSIONS, ROOM |
Active control types: SESSION_ACTIVE, ROOM_ACTIVE |
Other control types: ALL, NONE, RESTARTABLE |
The notion of „Master" is not supported anymore |
Applications can run in master-slave mode by the use of appropriate locks |
Much more sophisticated models are possible (e.g. player1, player2, observers...) |
APIs for Java, JavaScript, C, C++ |
Hierarchical API structure |
Java event-based API |
Java method-based API
|
daemon |
Java |
API |
Java |
Script |
Reflection |
API |
Method |
based |
C/C++ |
Seriali |
zation |
Event |
based |
Secure |
API |
Bean |
API |
Applet developer registers objects to be used |
Methods of the registered objects can be invoked locally and remotely |
Registered objects can be used as method parameters |
Tango |
Reflection |
API |
Tango |
Tango |
Reflection |
API |
OID |
OID |
o1 |
m1 |
o1 |
m1 |
... |
o1.m(o2) |
... |
o2 |
o2 |
Tango2 server provides the administrator interface |
Telnet-like interface to the server. Possible use as a base for Web-based applications |
Administrator interface enables:
|
Sockets |
Added value |
Fixed system |
Tango1 |
Tango2 |
Better |
System |
Prepared by |
Piotr Sokolowski |
Connecting to a Room |
Managing activities during the stay in the room |
Disconnecting from the room and connecting to a different room |
Reading & parsing of the room configuration file |
Reading & parsing of the community configuration file |
Performing authentication (if required) |
Connecting to server used by the room |
Starting default applications for the room |
Starting, terminating applications as requested by the server |
Providing communication between applications and the server |
Keeping an updated local copy of information about users, sessions, and locks for fast access |
Periodic polling if applications are still alive |
Informing interested applications about changes in locks and variables |
Providing information services for applications |
Verifying that the new room accepts the user |
Removing old applications |
Starting applications in the new room (Some applications which are running in the old room may be reused) |
Information about users and sessions |
Configuration information for each type of application - stored in the room configuration file. |
The daemon |
Applet Stub |
JS Stub |
External application Stub |
Applet |
Java Script |
C application |
Reflect API |
Live Connect |
Sockets |
To Server |
Configuration |
Data |
daemon Control |
Message Switching |
Variable and Lock Control |
Application Stubs |
Server Connection |
Application Stub |
Handler Manager |
Data |
Manager |
Application |
Manager |
Variable |
Manager |
daemon |
Control |
Server |
Connection |
Applet Stub |
External |
Application Stub |
Standalone Applet
|
Embedded Applet
|
Room configuration file stores various properties with string values |
Room configuration file is divided into sections |
Some sections are used by the daemon |
Other may store information used by applications (e.g. background color, images used by the application) |
NPAC 08/28/97 |
Room and Session access control |
Shared variables and locks management |
Message broadcast (to the session participants and room users) |
Time-out control |
Administration interface |
Java application (JDK 1.1.2) |
Multi-threaded application |
Communication with daemons - TCP stream connection |
Services run on two ports:
|
Tango2 server documentation: |
http://trurl/tango2/doc/serverdev/tango_server.html |