The widespread adoption of the Internet in everyday life is connecting everybody, and the convergence with mobile networks provides a means for connecting people everywhere, anytime. This is obviously changing the way people work: people want to access company information remotely and collaborate with colleagues from wherever, whenever necessary. The Web provides ideal tools to fulfill these needs: Web browsers are available everywhere, even on mobile devices, and they can integrate different services and applications into a common, easily accessible, platform-independent user interface.
The Web has already gained a primary role in supporting remote collaboration for some years [4]. Nevertheless, the communication mechanisms it offers are not sufficient to support interactive, real-time collaboration. The communication need that stimulated the development of the Web was about consulting structured documents, not about supporting an interactive discussion among a virtual team. C/Webtop is a collaborative platform that exploits multiplatform technologies to run seamlessly on any device, whether mobile or not, and it takes advantage of any fixed or mobile network supporting TCP/IP.
The ultimate purpose of C/Webtop is to provide users with a means for collaborating fruitfully while on the move. Just to mention two future application scenarios where C/Webtop will be used:
- In the construction industry, masons working on in-progress buildings can access an architect directly for discussing the work; and
- For outdoor work; such as on docks, sailors can have a direct link with a central office and between themselves.
C/Webtop has been developed over the last three years and its current implementation is the basis for the European-scale project IST-2000-30045 COLLABORATOR.
C/Webtop supports a variety of different devices, such as laptops, PDAs, and smart phones with sufficient display capabilities. C/Webtop provides a set of interactive services to support some common activities of the virtual team. For example, it integrates an audio/video conferencing system, a shared sketchpad, a shared text editor and a shared Web browser.
C/Webtop is adaptive, in the sense it tunes its user interface to adapt to specific user preferences and to fit the capabilities of different devices. It also shapes the user interface to the available bandwidth through a dynamic adjustment of the audio/video quality and of the resolution and color depth of images. Users working with different devices receive different displays according to the capabilities of the device and available bandwidth.
C/Webtop is Web-oriented, relying on the technologies driving the development of the Web today, like Java and the IP multicast protocol. Nevertheless, it enhances the classic Web collaboration mechanism to support interactive and real-time collaboration.
Collaboration Model
Collaborative platforms are generally characterized in terms of a set of concepts they support. The most basic of them is the concept of a collaborative session. A collaborative session is an activity of a group of people, the virtual team, that exchanges information among members. Collaborative sessions can be roughly classified on the basis of the dynamism of the information exchange [6] in two categories: synchronous and asynchronous. A high level of interaction among the team characterizes synchronous sessions: all users share a single view of the discussion and information is exchanged as soon as it becomes available. Conversely, in asynchronous sessions, information is transferred only on demand, resulting in a lower degree of interaction among the team. C/Webtop supports synchronous sessions and promotes the dynamism of the discussion, allowing users to exchange information freely by means of a textual chat and an audio/video conference, where available.
Any collaborative platform like C/Webtop needs to provide consistency-guarantee mechanisms [5] to manage the shared information correctly. Collaborative platforms supporting synchronous sessions typically guarantee consistency employing a floor-control policy. Such a policy ensures that when a user is free to modify the shared information, no other user has the same right. This modification right is usually described by saying that only one user at a time can have the modification token. Many floor-control policies are available in the literature and they can be roughly classified as implicit and explicit on the basis of how the collaborative platform assigns the modification token. In implicit policies, the token is assigned without the users being aware of this; in explicit policies the collaborative platform explicitly assigns the token to users.
C/Webtop implements an explicit policy that enables only one user at a time to control the state of the collaborative session: when he or she finishes her work, the modification token passes automatically to another user. This mechanism implies that users can gain the token only after receiving it by someone else. At any time during the collaborative session, a user can ask to receive the token. Such a request is queued and when the token is released, the platform assigns the control of the shared workspace to the user with the oldest request.
The virtual team can also decide to exploit this floor-control policy for controlling the audio/video conference. If this possibility is actually adopted, the team sees and hears only the user that currently holds the token.
C/Webtop supports virtual teams involving users that join and leave a running session dynamically. This requires supporting the so-called unanticipated sharing [2], and C/Webtop allows latecomers to enter a running session synchronously: the latecomer is immediately accommodated in the virtual team and is provided the current view of the shared information. At any time during the session, a user can leave the team simply by closing an application; the remaining users are immediately informed of this event.
Architecture
The architectures of collaborative platforms can be roughly classified into centralized and replicated [12]. In a centralized architecture, the shared application is maintained in a single physical location, and users are supplied with the output of this single application. In a replicated architecture, each user owns an instance of the application and the platform provides the mechanisms for synchronizing the various instances in order for all users to have a coherent view.
Replicated architectures have been considered the best choice for a long time, but they are not feasible for the application scenarios that C/Webtop addresses. Replicated architectures are based on the possibility of installing an instance of the shared application on each device taking part in a session. We cannot rely on installing a real-world, off-the-shelf application on a portable device with small processing power and memory. This is the reason why C/Webtop relies on a centralized architecture.
C/Webtop is not limited to share only a single application, and the virtual team is provided with a shared desktop capable of running many applications concurrently. In order to start a collaborative session, the team manager launches C/Webtop on the server host providing a list of applications to launch. The user also fixes the authorization policies and the permissions for each user. Then, users can open their client, take the floor, and begin working in the shared workspace.
Figure 1 shows the C/Webtop architecture. Users interact with the shared applications through their terminals. The client application, running on each terminal, receives the output of the shared applications (solid lines in Figure 1) and captures all the input, that is, it captures all mouse and keyboard events. These events are then redirected to the server through dedicated channels. Input events are regenerated locally by the server and passed to the shared applications (dashed lines in Figure 1). Only the events that the user holding the modification floor generates are passed to the shared applications, while the others are ignored. The result of this mechanism is that only the user holding the floor is allowed to work actively on the shared workspace. Whenever a new user joins the running session, C/Webtop synchronizes the state of the session by asking all shared applications to redraw their user interfaces.
C/Webtop is not limited to share only a single application, and the virtual team is provided with a shared desktop capable of running many applications concurrently.
In parallel to the channels transporting input events and user-interface output, C/Webtop provides a pair of IP multicast channels for streaming audio and video. These channels rely on well-known multimedia protocols; C/Webtop audio/video conferences are compatible with Mbone tools.
The J/Webtop Subsystem
J/Webtop is the subsystem of C/Webtop in charge of sharing Java applications. J/Webtop relies on a collaborative version of Swing (part of the Java foundation classes) that we plugged into the Java virtual machine running on the server host. As far as Swing 1.x is concerned, our approach simply requires implementing a substitute of the Abstract window toolkit (AWT) library capable of supporting remote users; this version of Swing completely relies on AWT for its input/output operations. Implementing a remote AWT is straightforward because AWT is designed to be easily substitutable.
AWT relies completely on a single object called toolkit that acts as an abstract factory for all objects managing graphic components. The toolkit is in charge of creating the peer objects that AWT components use for performing input/output operations. Implementing an alternative toolkit allows control of the whole AWT and, therefore, all of Swing 1.x.
The introduction of Java 2D as a native part of Java 2 makes the remotization of Swing 2.x much more complex. We succeeded in supporting Java 2 applications within J/Webtop only partially.
The remote toolkit manages the connections between the shared applications and the client application and is responsible for maintaining the state of the collaborative session. The client application captures mouse and keyboard events generated by the user and sends them to the remote toolkit through a dedicated channel. Only the events received from the user holding the modification token are posted to the application, while the others are ignored. Consequently, the application produces only the output generated by the user currently owning the modification token.
The remote AWT intercepts all the graphic primitives the application calls to display its user interface. Such calls are then sent to all client applications belonging to the running session. In order to boost performances, such calls are sent through a reliable multicast protocol. Figure 2 shows a snapshot of a C/Webtop client sharing a Java application through J/Webtop.
The W/Webtop Subsystem
W/Webtop is the subsystem of C/Webtop in charge of sharing native Windows applications. W/Webtop differs from all other application-sharing systems available for Windows because it provides a shared desktop that does not interfere with the console user’s desktop. All other application-sharing systems can share only the applications the console user is currently using, thus giving the console user a privileged role on the team. W/Webtop is not forced to share the applications the console user is interacting with because it exploits the so-called window stations Windows NT, 2000, and XP provide. A window station is a secure system object containing a clipboard and a set of desktops. At boot-time, Windows creates an interactive window station that will contain the desktop of the console user. W/Webtop creates a noninteractive window station to hold the shared desktop and all the shared applications. Desktops in different window stations cannot interfere, and the console user is not aware W/Webtop is running.
The broadcasting mechanism W/Webtop exploits differs from that of J/Webtop. C/Webtop clients are Java applets; this eases the broadcasting of the user interface of Java applications. We can broadcast the calls to the graphic primitives, such as DrawLine, and have them replicated on the clients (shown in Figure 3a). This is not the case for Windows applications because we cannot rely on having the GDI library, the Windows graphic engine, on portable devices. In order to share Windows applications, W/Webtop forces the shared applications to draw their user interfaces on a bitmap that is then broadcast to the clients (shown in Figure 3b). This mechanism relies on redirecting all GDI functions toward such a bitmap. In order to reduce the network load, the color depth of this bitmap is reduced to 8 bits per pixel and some of the compression techniques used in VNC [10] are also implemented. The client application is the same as J/Webtop and it uses the same mechanism to send input events to the shared applications.
The Multimedia Subsystem
C/Webtop supports audio and video conferencing in order to increase the level of the virtual team’s interaction. This multimedia support is optional: if the client device has enough memory and processing power, users can participate in the audio or video conference. Otherwise, users can still collaborate with the virtual team through the textual chat. The multimedia support does not depend on the shared applications, and it can involve only a subset of the virtual team. A user can start and stop the audio or the video conference whenever he or she wants: the platform provides the mechanisms to synchronize them with all the other services of the shared desktop. This allows, for example, sending only the voice of the user that currently has the modification token to the rest of the team.
The video conference application is based on the video conferencing (VIC) tool developed by the Lawrence Berkeley Laboratory [9]. We modified VIC in order to integrate it with the platform: a Java AWT canvas controls VIC so client applets can display the video conference easily. The client interface adds this AWT canvas and launches VIC passing the multicast address of the conference. The images of the users of the videoconference are displayed in a pixel format of 50×40, and only one of them is displayed in a 175×140 pixel format. Whenever a user receives the modification token, the image is automatically maximized, thus highlighting who is controlling the shared applications. Then, each user can choose which image to maximize by clicking on the corresponding thumbnail.
The audio conference application is developed using the Java Media Framework. Every user sends a multicast audio stream at 8Kbps and receives a corresponding stream from all other users.
Comparison with Similar Systems
There are a number of collaborative platforms designed to work on the Web as the interest in both the Internet and in groupware has grown. Some of them provide special-purpose, shared applications intended to support virtual teams in particular domains. For example, in the case of the MASH [8] and MERCI [3] projects, they provide a shared whiteboard, a shared text editor, and a videoconference system.
Another category of a collaborative platform that supports the so-called collaboration transparency is the possibility of sharing off-the-shelf applications. We are more interested in these platforms as C/Webtop falls in this category.
As previously discussed, collaboration-transparent platforms can be designed around a replicated or a centralized architecture. If we want to accommodate mobile users, we need to use a centralized architecture, because, generally speaking, we cannot install any real-world, off-the-shelf application on a portable device.
The principal method employed in the literature to implement centralized architectures is display broadcasting. This method is based on the assumption that users access the platform through a client application capable of showing the user interface of the centralized application. These platforms are generally classified into heavyweight and lightweight clients on the basis of the information the centralized application transmits to the client application.
In the heavyweight-client approach, the bandwidth usage is optimized by transmitting only the calls to graphic primitives to the client application, just like J/Webtop. Such an approach is platform-independent only when we consider the sharing of Java applications.
If we want to accommodate mobile users, we need to use a centralized architecture, because, generally speaking, we cannot install any real-world, off-the-shelf application on a portable device.
The lightweight-client approach trades platform independence with network load because it broadcasts a bitmap of the user interface of the centralized application, just like W/Webtop.
The heavyweight-client approach is mainly used in collaborative platforms based on the X-Windows system, such as Hewlet-Packard SharedX [7] and Old Dominion University XTV [1], where the client is supplied with a description of the user-interface event that occurred on the centralized application. On the contrary, the lightweight-client approach, also known as “thin clients,” is used when the client capabilities required are the only possibility of displaying the bitmap of the actual output of the centralized application. Such a method is used by Microsoft NetMeeting and by the collaborative version of VNC [10] and TridiaVNC [11]. This approach is the basis of the ITU T.128 protocol.
If we take into account the possibility of accessing the platform from portable devices, we can compare our work only with TridiaVNC and jVNC. Such products are designed to work with thin clients running on portable devices, and they offer some of the features provided by C/Webtop. Nevertheless, they are not an integrated solution implementing a virtual meeting room because:
- They do not provide any support for multimedia communication;
- They do not integrate any tool to manage virtual meetings; and
- They offer a weak synchronization mechanism to prevent multiple modifications on the shared documents.
Basically, TridiaVNC and jVNC can be considered enabling technologies for the implementation of more sophisticated collaborative platforms.
Conclusion
Connectivity is one of the main keywords of the current era. The widespread adoption of the Internet as a new media for interpersonal communication suggests extending its potential to mobile networks. C/Webtop follows this trend, taking the technology of collaborative platforms to mobile networks. It allows users to work seamlessly with shared off-the-shelf applications from devices connected to the fixed network or to a mobile network. The platform automatically adapts the information supplied to the user on the basis of the capabilities of the device and on the available bandwidth.
In its current implementation, C/Webtop is composed of three subsystems. J/Webtop is the subsystem responsible for sharing Java applications. It exploits primitive broadcasting to optimize network usage, thus accommodating users connected through low- bandwidth links. W/Webtop is the subsystem that shares native Microsoft Windows applications. It uses bitmap broadcasting and is much more bandwidth-demanding than J/Webtop. It is essential to allow sharing common applications, such as applications for office automation or software development. Finally, the multimedia subsystem provides an audio/video conference application that supports direct communication among the virtual team.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment