Session Management and Collaboration in LEVERAGE

David Fernández, Luis Bellido, Encarna Pastor - Universidad Politécnica de Madrid
Dpto. de Ingeniería de Sistemas Telemáticos (DIT). Spain
david@dit.upm.es, lbt@dit.upm.es, encarna@dit.upm.es

Slides of Presentation

Abstract

This paper presents a brief summary of the design and implementation of the synchronous collaborative part of the LEVERAGE system. We focus on two of the main modules which compose it: the Session Management Subsystem, which provides support for the creation of cooperative sessions, and the Collaborative Applications, used by participants in a session to share documents.

1. Introduction

LEVERAGE project aims to develop, implement and field trial a complete multimedia broadband network infrastructure to support collaborative, task-based foreign language learning between students remotely located. Effective collaboration is carried out by means of classical asynchronous tools, like electronic mail or shared workspaces, and also by more advanced synchronous applications, like videoconference or shared editors and blackboards.

The synchronous communication between the users of LEVERAGE system is organised around the classical concept of cooperative sessions. A cooperative session involves two or more participants (teachers and/or learners) which synchronously interact by means of a set of collaborative applications. To carry out their pedagogical task, the students regularly create and join to cooperative sessions to have virtual meetings between them.

As LEVERAGE is a language learning oriented environment, synchronous collaboration is heavily based on high quality videoconference applications. It is essential for a language student to have a good audio quality to reach a good understanding of other participants’ voice. But also, it is important to have a high quality video, to appreciate lip movement, as well as good audio/video synchronisation.

However, task-based learning involves also the interchange of data documents between participants. For example, the students will typically finish their tasks by making a presentation to a small audience using some slides. Or, they have to complete some exercises and show them to their supervisor in order to interactively correct them. Or, they need to co-operatively navigate through Internet to look for information about the subject of their task.

In order to fulfil all these requirements, a new complete cooperative environment was designed and implemented inside LEVERAGE project. Next sections describe some technical details about it.

2. Technical Issues

The scheme in Figure 1 presents the functional architecture of LEVERAGE system, including the synchronous and asynchronous functions, and some of the relations between them. Inside the synchronous part of the system, three main functions can be identified:

• Session Management, which is in charge of the establishment and management of cooperative sessions between the participants,
• Collaboration Support, which deals with real-time interaction through collaborative applications such as shared visualisation of documents, a shared whiteboard, a simple shared editor or a chat application, and
• Videoconference, that is, all the functions involved in real-time interaction by means of audio and video channels.

This paper focuses on the first two functions mentioned above, which have been the ones developed by DIT-UPM inside LEVERAGE project.

From the information point of view, the system has to maintain two basic types of information:

• Static information about the users (either students or advisors), groups, organisations, etc. This information is provided to the system at the beginning of a trial period and (basically) does not change during it. The part of the system in charge of them is called the Organisational Subsystem, which is in practice implemented by a database.
• Dynamic information about the current cooperative sessions. For each session, the system maintains data about the users participating in it, the tools or applications being used, the resources (for example, data channels) reserved, etc. The part of the system in charge of maintaining this information is called Session Management Subsystem, which is presented in the next section.

3. Session Management in LEVERAGE

The LEVERAGE Session Management Subsystem (SMS) allows the users to create, join, abandon or destroy collaborative sessions, as well as retrieving information about the sessions in course and the users involved in them. It is also in charge of organising the communication and providing the resources needed by synchronous applications.

From the user’s point of view, SMS is the entry point to the cooperative part of LEVERAGE system. It offers a simple and user-friendly interface, named the Session Desktop. Figure 2 shows a snapshot of Session Desktop main screen. The information is organised in a tree-like way: each session being a leaf of the tree which can be expanded to show the list of users and applications (see Figure 2). In the upper part, there is a toolbar that includes buttons to: Create a new session, Join an active session, Abandon a session, Add an application to a session, and Invite a new user to a session.

In case the user decides to create a new session, a new dialog box appears (Figure 3) that shows the users the different options available when creating a session: the list of users to invite; the applications that will initially be used; the session description; and the type of session (private or public). The color of the icons representing the users in the tree reflect their status: green means the user is connected; yellow means the server where the user resides is connected but the user is not; and red means that there is no access to the server where the user is registered. All the users invited to a session will receive an invitation to join the session and will be able to accept or refuse it. 

From a technical point of view, SMS is a distributed application made of several modules which run on client machines (PCs with Windows 95) and servers (UNIX). SMS main functions are the following:

• Creation, coordination and release of sessions,
• Launch applications and inform them about session events (for example, a new user joining or abandoning the session), and
• Maintain a database of dynamic session information.

• Session Manager (SM), which is the part of SMS that runs on a UNIX server. SM centralises all the information about sessions,
• Session Manager Agent (SMA), which manages the communications with the SM and launches and coordinates cooperative applications in client machines, and
• Session Desktop (SD), which, as mentioned, is the user interface of SMS.

From the pedagogical point of view the SMS should be able to support several simultaneous sessions with a small number of participants (up to 5) in a three sites distributed scenario, that is, with participants located in all of the sites involved in the project. For the first trials of the project, which took place in Cambridge, a centralised SMS was developed. But for the second and third trials, all the SMS was redesigned to cope with distributed scenarios following the architecture shown in Figure 5. 

The Distributed Session Manager (DSM) is based in a partial replication algorithm that allows the information of a cooperative session to be distributed over all the servers with users participating on that session. Among the main requirements that we imposed to DSM design, we can mention the following:

• No limit on the number of sites or interconnection topology. Although the maximum scenario of LEVERAGE trials is made of three sites in a triangle topology, the DSM can be used with a much higher number of servers and arbitrary topologies.

• Transparency for the clients. The distribution of DSM was completely transparent from the client point of view. Users or even client applications do not know the number or location of servers.
• Dynamic connection or disconnection of sites. As the network communications were not permanent, it was important to cope with the connection or disconnection of new servers without disturbing local sessions.

 
4. Collaboration in LEVERAGE

In this section, we present the most relevant features of the LEVERAGE dataconferencing cooperative applications, which allow users to share documents during cooperative sessions.

The functionality offered by these applications has been defined following the paradigm of a Virtual Meeting Room. They are supposed to be jointly used with good quality videoconferencing or, at least, audioconferencing facilities. As the main coordination between participants in a session will be held on video and audio channels, as it is done in face to face situations, the cooperative applications do not need to impose strict modes of operation that the users are not accustomed to use.

Cooperative applications try to resemble in some way the behaviour and facilities we use in face to face meetings. For example, they allow:

• to show documents which can be seen by all the participants during the session, as if a document were shown on a slide projector,
• to mark the document, as if the speaker was using a pen to point to some part of a slide,
• to make annotations on the document, as if the speaker were writing on the slides, or
• to have several speakers marking the document at the same time.

• Shared Window, to let users show documents to other participants,
• Telepointer, to let users mark the document being shown on the shared window,
• Shared Blackboard, to let users make simple public annotations to the shared window document,
• Text Sharing, to allow users to see and edit simple texts in a cooperative way, and
• Text Conferencing, to allow users to chat using keyboard typed messages.

• Weboard, which is shared web browser with telepointer and blackboard functionality. It supports HTML and PowerPoint document formats.
• SIESTA, which is a SImple Editor for Sharing Text in Ascii which includes the text sharing and tepointer functionality.
• LECHE, which is a simple chat tool.

Shared Window functionality lets users show documents to other session participants during a cooperative session. Basically, it is organised around a window whose content is synchronised in all participants’ screens. That is, at a given time, every participant views the same document or part of a document on it.

In Weboard application the shared window is a web browser which can access any document on LEVERAGE servers or in the Internet. The content, position and size or even the scroll position of Weboard’s main window is the same in every participant screen. Weboard is based on Netscape 3.0, with some plug-ins to show other document formats apart from HTML.

To load a document in the shared window, the user follows the same steps than when accessing a URL in a Web browser. Weboard is able to share standard HTML documents (without frames) and also Microsoft’s PowerPoint presentations, by means of a Netscape plug-in that interprets that document format.

The protocol followed to control the shared window is based on a token named Shared Window Turn (SWT). Only the participant who owns the SWT can load documents on the shared window. User input to other participants’ browsers is blocked. To control the window, other participants must request the SWT. This request is transmitted to the participant with the SWT, who is asked if s/he wants to release it to another participant. S/he can confirm or refuse the petition. By default, the participant who created the session owns the SWT at the beginning of the session.

The user interface of Weboard is presented in Figure 6. It basically consists of:

• a Netscape window, which is the shared window in which users load documents, and
• an external Tools window with menus and buttons to control Weboard, for example, to request the SWT, to start telepointers, to change to annotation mode, etc.

At any time, the user who is controlling Weboard can change to annotation mode. Once in annotation mode, the shared window is frozen and a new toolbox appears with utilities to draw over the document using typical tools like: pens, markers, squares, circles, etc.

Figure 7 shows the architecture of Weboard application. Weboard accesses Session Manager through the SMA API as every other application. It controls Netscape window by means of a standard API offered by severals browsers in the market. Finally, it access some external libraries were functionalities like data channels, telepointers, or blakboard are located. 

4.2 SIESTA

Basically, SIESTA let users share text files in a very simple way. As it is shown in Figure 8, SIESTA user interface has two parts: a Shared Text Window, that shows the same text in every participants’ screen; and a Tool bar, with some menus and buttons to control it.

SIESTA is a simple text editor, similar to Microsoft Windows Notepad, which is controlled by only one user at a time. The user controlling the editor (the master) can create a new text file, load a text from a disk file, modify the existing text, or save it in a disk file. Other participants can ask for the right to control the editor by clicking on a button and the master will be asked if s/he wants to release the turn, just in the same way as it is done in Weboard application. 

4.3 LECHE

Chat functionality was implemented by means of a new application that was added to LEVERAGE system for the second trials. As can be appreciated in Figure 9, it is a typical text conferencing application, like the ones used in Internet, and, although it was designed mainly to be use in case of audio problems (during testing phases or even during trials), the students made a heavy use of it. They found it very useful in a language learning environment to write words they do not understand or do not know how to write.

Due to the flexibility and functionality of the API offered by the SMA to develop new applications, LECHE was developed in less than two hours.

5. Implementation Details

SMS modules running on UNIX server have been implemented in C++ using GNU’s g++ compiler. SMS modules running on clients and cooperative applications have been written in object oriented Pascal using Borland’s Delphi development environment. SMA-API has been implemented using Microsoft’s OLE Automation inter-process communication standard. Communication between SMA and SM is based on a classical message based protocol.

To give an idea of the complexity of the LEVERAGE modules described in this paper, Table 1 shows the number of lines of code of each module. 

Papers from the 1st LEVERAGE Conference

LEVERAGE home page