Developing a Distance Learning System using Java applets P. Cadolini, F. Davoli, G. Marescotti, P. Maryni
Department of Communications, Computer and System Sciences DIST-University of Genoa Via Opera Pia 13, 16145 Genova, Italy Abstract
An overview of an experimental environment able to support distance learning sessions is presented. In particular the system is capable of carrying out distance learning sessions between two workstations using Netscape graphic user interface and a number of Java applets for handling the control of the system.
Preferred address for correspondence: Prof. Franco Davoli DIST - University of Genoa Via Opera Pia 13 I{16145 Genova Italy tel.: +39 10 353 2732 fax: +39 10 353 2948 tlx: 272399 DIE GE I e-mail:
[email protected]
1 Introduction Tele-teaching (or Distance Learning) is a notable service for the future high speed telecommunication networks. If one wants to exploit the possibilities o ered by the technology, the whole scenario can become quite complex, since it heavily involves the use of di erent media such as video, voice, still images and animations that have to be coordinated in real time; it also has to o er full interactivity between lecturer and students in a user-friendly fashion. In this respect, distance learning can be considered an important multimedia service among the various ones which are receiving much attention to-date [1, 2, 3]. In order to support a service of this kind, the telecommunication infrastructure has to eciently cope with the transmission of di erent types of streams that have di erent requirements in terms of constraints and required bandwidth. High speed networks will certainly be able to provide all the bandwidth necessary to whatever requirement but, by carefully analyzing the nature of a tele-teaching session, it is possible to come out with a system able to give a more than sucient grade of service, even with the existing network structures. This leads to a potential increase in the use of remote-learning sessions and to the possibility of experiencing the real issues and requirements of such a service, today. The University of Genoa has been involved in Distance Learning since 1990, with a research activity sponsored by the Telecommunication Project 2
of the Italian National Research Council (C.N.R.) [4, 5]. This included the design and development of two specially equipped classrooms linked by a dedicated telecommunication channel. No packet switching was involved within such a project. This system is still currently utilized for university classes which are held on a regular schedule. During these years, however, several improvements in machine power and network performances have taken place. This has led us to study the possibility of carrying on distance learning sessions based on packet switching mode between workstations. This paper describes the system architecture we have been experiencing along with the problems we have faced. In particular, we have taken into account the utilization of Java tools, which seem to be the most promising ones for networked applications. The choice of Java was motivated by the widespread use of it especially within WWW browsers such has Netscape. This paper is organized as follows. The next Section explains what Java can do and what it cannot do. This is important because it helps to understand a number of design choices which originates from Java resctrictions. Section 3 describes the system architecture which is currently being implemented and Section 4 draws the conclusions.
3
2 Java Restrictions The Java language represents an enhancement to the plain HTML in that it allows some form of processing, by means of small procedures called applets. Java applets can be downloaded by a server and run on the local machine. A standard code, called byte-code, guarantees that applets can run on every machine which has a Java library: this makes them particularly interesting. Java is embedded in a number of WWW browsers, the most notable one of which is Netscape (another one is HotJava). For performance reasons, applets are better suited for intranet services (loosely speaking an intranet corresponds to a MAN) where there is high bandwidth availability. Nonetheless, they can also be used over the Internet. This fact has led to the presence of a number of restrictions which are there to guarantee a sucient degree of security. Restrictions are mainly focused on the possibility of writing on a local disk and on the ability to open connections (i.e., socket mechanism or the like). There are also restrictions in reading the characteristics of remote machines. Sometimes the restrictions on what Java can do depend on the browser being used. In the following paragraphs we will refer to our experience in using Java with Netscape. Netscape has been chosen because it has been ported on several operating systems. These restrictions had to be taken into account in designing our distance learning system, because a number of nice features could not be directly 4
implemented with Java. To start with, let us consider the transmission of live audio. A rst problem rises if some form of coding is employed because implementing a coder and a decoder, say for GSM audio, with Java is not trivial. Secondly, audio should be decoded and stored on a le because the Java library only allows to play either local or remote audio les. This turns out to be cumbersome and, depending on the local system, it might add unacceptable delay and lead to poor results. Problems are there also on the transmitting side because getting audio directly from a microphone is not always possible. Because of all the above facts, audio management needs to be handled outside Java. On the other hand, as regards audio controls (e.g., start, stop, volume), Java turns out to be a useful graphical tool, since connections with local processes are allowed. Live video also shows a number of problems. Java libraries seem to allow to drive a monitor directly, but coding and decoding mechanisms should be directly implemented in Java, which, most likely, would lead to very poor performances. For this reasons non-Java video handlers are needed both at the local and at the remote sites. Again, Java interface can be utilized for video control functions such as start, stop, etc. Analogous problems rise for handling a remote pointer which mirrors a local one, which is of paramount importance in distance learning activities. If one wants to implement it so that images can be loaded on both sites and pointed the same way, Java restrictions impose the presence of two simple 5
pointer position handlers (one per site) which interact together and with the local applets. Using whiteboard applications (e.g., plug-ins), would solve the problem, but it would also increase the complexity of operating the whole system. This is a drawback since the complexity has to be kept low: a teacher has to operate the system while carrying out the lecture. Next Section, taking into account all these facts, describes the architecture of the distance learning testbed being implemented at the Univeristy of Genoa.
3 The Distance Learning System The distance learning system operates between two workstations. One of them is on the letcurer's site (or master site), while the other one is on the remote site (or slave site). The master site is composed of several parts: an audio encoder, a video encoder, an audio decoder, a WWW browser which can run Java applets and a central transmission handler. The video encoder is software implemented and performs H.263 coding algorithm. This algorithm can give high compression rates and it has the advantage of requiring less e ort in the decoding phase than in the coding one (i.e., it is an asymmetric algorithm) and this allows to set up a remote site using a simpler equipment. The audio encoder performs the Group Special Mobile (GSM) encoding algorithm. GSM has been chosen because it represents a good compromise between compression rate and audio quality: good audio quality is 6
essential for distance learning sessions. The WWW browser (e.g., Netscape) is used as a graphical user interface for both sites. A set of Java applets control the image management. The lecturer can choose an image to be displayed on both sides at the same time and his/her pointer is mirrored by the remote one. Because of limitations in the Java libraries, the remote pointer handling has to be performed by an \ad-hoc" remote process which, in turn, interacts with the remote browser. Image transmission passes through the transmission handler which decides how much bandwidth can be allocated to it. Recent versions of Netscape allow to set up a whiteboard between the two sites. Figure 1 depicts the various components of the distance learning session. Notice that the dotted arrow which connects the transmission handler to the video encoder refers to a new policy being implemented by means of which the video encoder can be tuned to some extent (see Section 3.1).
3.1 The Central Transmission Handler The role of the central transmission handler is to receive audio, video and image streams and to decide how to share a given capacity C (tunable) among them. Figure 2 gives a schematic description of the Transmission Handler. Its purpose is not only to keep the sum of the three ows below C but, when possible, to mantain an output ow as close as possible to C. The 7
Images Images
Image & pointer Handler
Image handler
Image handler Audio decoder
Transmission Handler
~C
Audio encoder
bps Video decoder
Video encoder Audio encoder Audio decoder
Remote site Audio/Video Storage Device
Lecturer’s site
Figure 1: General architecture of the distance learning system. rationale in doing this is evident if we consider the presence of one or more ISDN Base Rate Interface (ISDN BRI) channels allocated for the distance learning session: we want to maximize the channel utilization. The role of the transmission handler is also important when the network is completely asynchronous (and best-e ort) because a quasi-constant source o ers a trac which is better controllable than a bursty one: it is better to give a quasiconstant medium quality (tunable with the parameter C), than one that varies a lot. The problem is how to share bandwidth among the three ows (also control messages ow through the transmission handler, but they are 8
control signals (pointer position, audio/video controls, others)
Image controller Audio controller Video controller
Rate controller
images
images
coded audio
coded audio
coded video
coded video
(from encoder or disk)
Figure 2: The Transmission Handler. always given the highest priority). We have chosen to always give priority to the audio stream. Good audio quality is a requirement which is common to almost all the distance learning sessions: a blur on video or on images is not as bothering as noise on audio. The residual capacity is shared between video and images. The policy in this case is to assign the bandwidth that is not used by audio (i.e., 13 Kbps) and video (in this case the bandwidth is estimated by measurements over a short time period) to image ow. An improvement to this policy, which supposes the video encoder to be tunable, is currently being implemented. This consists in giving a \weight" or \grade" to images and video. In this last case the transmission handler interacts with the video encoder. It adjusts the video quality according to both the allowable bandwidth and the \grades" which have been set. Notice that, in order to avoid variable video quality, video encoding rate is chosen at the set up phase and then it remains constant for all the session (unless some variations are imposed by setting di erent values of C or di erent 9
video/image sharing values). This is important in order to mantain a quasiconstant quality to the session.
3.2 Still image handling The management of still images is almost completely implemented with Java (apart from pointer handling). The teacher can choose an image from a list and this image is displayed on both the local and remote sites. A remote pointer that mirrors the local one is also allowable. Image and pointer handling is performed by Java applets. We need two more processes for setting up the connection through the network because Java applets are not allowed to do this (for security issues). All the images pertaining to a lecture are slowly transmitted while the lecturer is teaching. This is accomplished by using the residual capacity (i.e., the one not used by audio and video streams). So, when the lecturer chooses an image to be displayed, it is likely that that image is already stored on the remote disk. Therefore it can be displayed immediately. If the image is still not there, then it will be set at the top of the transmission list.
4 Conclusions A system which enables distance learning sessions between two worksations, in a packet switched mode, has been presented. This system, currently being implemented at the Unviersity of Genoa, will be the successor of the 10
currently used one which needs xed-bandwidth dedicated lines. Problems encountered with the utilization of Java applets have been described along with the solutions to cope with them.
References [1] Special Issue on Multimedia Communications. IEEE Journal on Selected Areas in Communications, 8, April 1990. [2] Special Issue on Multimedia Communications. IEEE Communications Magazine, 30(5), May 1992. [3] R. Mason and P. Bacsich, editors. ISDN applications in education and training. The Institution of Electrical Engineers, 1994. [4] V. Cappellini. Experimental realizations of bradband communication networks. Europ. Trans. Telecommun., 2:173{178, March 1991. [5] S.Coiro, A. Esposito, E. Ripani, and A. Roveri. The C.N.R. Telecommunication Project: an updated overview. In Europ. Trans. Telecommun., volume 3, pages 101{108, March 1992.
11
