Improving Computer Support for Cooperative Applications over Internet J.C. Burguillo, M.J. Fernandez, M. Llamas, and L. Anido Universidade de Vigo, Vigo 36200, Spain,
[email protected], WWW home page: http://www-gist.ait.uvigo.es/~jrial
Abstract. The development of environments for telecooperation over
Internet is an increasing necessity for speeding up learning, development and cooperation. In this paper, we introduce an architecture model and a protocol, designed to allow multiple on-line communication among several collaborating tools. An abstract event model, which supports remote operation, is also presented. In the practical eld we discuss the features of TeleMeeting, a system developed in Java, that supports the previous concepts and incorporates several tools to improve the "virtual meetings" over Internet.
1 Introduction During the last years, several concepts have become popular with Internet and WWW apparition: Teleworking, Telemedicine, Teleteaching, Telecooperation, etc. New technologies have contributed denitively to this process. In the present day networked scenario, computer support for cooperative work (CSCW) enables new possibilities for sharing information and tasks. However, although clearly powerful and useful, the approach followed by the WWW does not directly support additional collaborative forms of information sharing. Electronic mail, HTTP and FTP still remain the basic tools used for supporting collaboration in widely dispersed working groups. Several researchers have suggested that for changing this situation new tools should be developed to assist the complex task of building cooperative systems, together with common platforms to facilitate system deployment 1, 2]. Furthermore, decentralisation seems to be the trend in business and academia due to the problems that arise in the design of multiuser systems based on centralised and replicated architectures 3]. This only can be achieved if new, e ective methods for information sharing are made available. The aim of this paper is to discuss a new architectural solution, to support on-line collaborative work, together with the protocols needed to communicate di erent agents over the network. At the same time, we explore the possibilities of Java 4] to foster user-interaction and decentralised tool support. In the next sections, we present our proposed cooperative architecture, the TCOP protocol, and an abstract event model developed to support remote operations. In section 5 we discuss the TeleMeeting environment, which is an implementation of the previously described model. In section 6, we present an
alternative to this architecture model and nally, we outline our present and future working lines.
2 Cooperative Architecture The proposed architecture is based on a typical client-server model. Three main elements interact: { Client interface: it is a gateway module, running on the client machine that connects client tools with the server. This is not a compulsory module. It was designed to simplify the communication with the server and to speed up tool deployment. { Client tool: it is the collaborating application running on the local machine. If the client interface is not present, then this tool should implement the server communication protocol. { Server: it creates, maintains and manages all connections and information transfers among concurrent cooperative tools on remote clients. We took from IRC (Internet Relay Chat)5] the concept of room. In our model, a room is "a virtual channel where tools interchange any kind of information". In a given room, participants should connect using the same kind of application, for instance in a chat room every user should connect with the same kind of chat tool. Client tools behaviours depend on their role and state. We distinguish three roles (root, room operator and room client) and four states (standard, listening, lecturer and local). For the listening state, the client tool only receives information (passive) for the lecturer state, it can send information but can not receive it the standard state is the aggregation of the two previous ones and, for the local state, clients can not send nor receive information. Three kinds of room access were dened: free, password restricted and granted. For granted rooms, the room operator allows or denies access to individual client tools. This model helps programmers in two ways. First, it simplies the development and implementation of new on-line collaborative tools. Second, it makes information exchange among collaborative applications simpler. Furthermore, connecting a new kind of tool to the environment is a dynamic process without server reconguration.
3 Tele-cooperation Protocol (TCOP) TCOP (Tele-Cooperation Protocol) has been designed to support the dialog among server and client tools. The protocol has several commands to handle client requests: connect to a tool, send private messages, get unnished work initiated by other tools, change state, exit environment, etc. It also has several server-originated commands: return a port connection, allow connection for a new tool, send private messages, return participant IDs, etc.
4 Abstract Event Protocol (AEP) An interesting feature that should be o ered by collaborative systems is teleoperation. For instance, whenever the user performs any action (mouse dragging, key pressed, menu access, etc.) on the local tool it should be possible to sent it over the network to other clients, which will execute the action as it was generated locally. This feature o ers support for remote presentations, remote tutoring and remote operations in a master/slave mode from one to many or many to many. In a platform independent system, it may be desirable to code and sent events generated by particular programming languages following an abstract model. Then, tools written in di erent programming languages can use this scheme to map them to the corresponding local context. To get this feature we need to code events into an abstract representation. If the tool needs to broadcast a particular kind of event, it only needs to map it to the common representation and send it over the network. At the same time, they must be aware of events coming from other tools, to unmap and execute them as if they were local.
Fig. 1. Architecture layers In gure 1 we present the architecture model and related protocols. Any application may use its own protocol over TCOP. Optionally, tools may use the service o ered by AEP. This service is transparent for the server.
5 TeleMeeting Environment In this section, we discuss an implementation of the previous architecture and protocols. The TeleMeeting environment is composed by a server and several clients congured following the guidelines commented in previous sections. Client selection was based on the following criteria: they should be adequate to analyse system's performance and they should o er common, useful functionalities that are typically required in collaborative systems.
We chose Java as the implementation language. Java is platform independent and browsers can load dynamically Java applets in a safe manner. With Java, we only need a commercial browser with a Java Virtual Machine for accessing the system. Java also o ers more user interaction and less delay than Common Gateway Interface (CGI) based applications 6]. 5.1 Connection Procedures
The clients request the server to create new rooms, join to existing ones, manage the room or leave the system. The participants can access to the system in two ways: { Using a commercial Internet browser. { Via a custom-developed application which connects directly to the server.
The connection phase follows these steps: 1. The client interface sends a connection request with a description of the client tool. 2. The server checks the request. If the request is accepted, it returns a port for connection, 3. The tool connects to the server in that port and receives information about other clients and room state. 5.2 The Server Side
The server checks every room connection, accepting orders sent by tools. When the server receives information from a client, it checks the destination: the message could be related to room management, it can be a private message for another client tool, or it should be sent to every tool in the room. At the same time, several rooms can be active for di erent kinds of tools. The server can log client actions for a specic room. 5.3 TeleMeeting Clients
In the next paragraphs we present di erent client tools developed as Java applets. These applications are o ered as basic functionalities in the system and can be accessed with a standard browser. These tools have been selected to test the general approach outlined in previous sections. They cover di erent communication scenarios. We developed a chat client, a le transfer client, a shared whiteboard client and a telebrowsing client. All of them connect to the server following TCOP. The management tasks, done at the server side, are independent from the tools connected. Every client implements its own application protocol over TCOP. The shared whiteboard and the telebrowsing client are the most specic. We will comment them briey.
The whiteboard o ers a shared graphical editor to every participant in a meeting room. Every picture drawn locally will be seen by every client connected to the same room. This is done thanks to the abstract event model (AEP) that allows whiteboards to recognise remote events. With the telebrowsing tool, users can show presentations remotely. When a lecturer selects a new HTML page with this tool, every other users' browser fetch that HTML page automatically and present it to the user. This tool is very useful to complement other collaborative systems, for instance, multi-point presentations using videoconference.
6 Client-Subserver Architecture Model In this section we present an alternative architecture to take advantage of the proposed environment. Combining Java applets and applications we could develop a new model transparent to TeleMeeting. We will call subservers to native applications, which run as independent servers and use TeleMeeting to connect to their clients. The reader can view the model as a multiple CGI (Common Gateway Interface). It could be interesting to implement simulation environments, where several clients access to a central subserver. In this model, every client can query the subserver. Other clients are informed about the request and subserver's replies, so every tool can update its state. The model, presented in gure 2, has several advantages that we comment briey: 1. Local libraries in the remote machine can be accessed. 2. We obtain a distributed environment without overloading the TeleMeeting server. 3. It is an ideal model for one to many simulation environments. 4. Already developed software can be reused.
Fig. 2. Subserver architecture
7 Conclusions and Further Work In this paper we have presented an architecture model and the corresponding protocols designed to improve communication-related features in collaborative on-line applications. The model presented here and the underlying TCOP protocol, allow programmers to add new types of applications dynamically, without recompiling the system. As a practical implementation of the proposed model, we have introduced the TeleMeeting environment, which o ers a rich variety of cooperation possibilities. The environment was designed using Java. Several client tools have also been developed, demonstrating the possibilities of this language to implement environments as complex as the discussed before. At the same time, we tried to improve system features. One of our present working lines, almost nished, is aimed to enrich this model incorporating memory managers for rooms. The key idea is to share memory between client tools and improve the possibilities for communication in this distributed environment. The system described in this paper is part of a bigger one that also provides operating system capabilities. This new design incorporates security and encryption features and o -line communication among users that do not comply with the model described in this work.
8 Acknowledgements We would like to thank Alejandro Garca Gonzalez for his work during the implementation phase. We are also grateful to anonymous referees for their judicious comments. Finally, we appreciate the European Community Socrates ODL Project WeMeet 56420-CP-1-98-1-BE-ODL-ODL from which we extracted helpful ideas.
References
1. Patterson, J.: Comparing the programming demands of single-user and multi-user applications. Proceedings of UIST'91. ACM Press, November (1991) 87{94. 2. Dewan, P. and Choudhary, R.: A high-level and exible framework for implementing multi-user interfaces. ACM Transactions on Information Systems, 10(4) (1992) 345{ 380. 3. Greenberg, S., Roseman, M., Webster, D. and Bohnet, R.: Human and technical factors of distributed group drawing tools. Interacting with Computers, 4(3) (1992) 364{392. 4. Gosling, J., Joy, B. and Steele, G.: The Java Language Speci cation. Addison-Wesley ISBN 0-201-63451-1 5. RFC 1459: Internet Relay Chat. Available by anonymous ftp from ftp.rx.internic.net/rfc 6. Trevor, J., Bentley, R. and Wildgruber, G.: Exorcising daemons: A modular and lightweight approach to deploying applications on the Web. Computer Networks and ISDN Systems: Proceedings of the 5th International W3 Conference, North Holland, 28 (7-11) (1996) 1053{1062.
