Promondia:
A Java-Based Framework for
Real-Time Group Communication in
the Web
Ulrich Gall, Franz J. Hauck
December 1996 TR-I4-96-08
(revised April 1997)
Computer Science
Department
Operating Systems — IMMD IV
Friedrich-Alexander-University
Erlangen-Nürnberg, Germany
Technical Report
This paper has been published as Technical Paper in the Proceedings of
the 6th Int. World Wide Web Conference (April 7-11, 1997, Santa Clara,
Cal.). The Proceedings will appear as special issue of the Computer
Networks and ISDN journal published by Elsevier, Amsterdam, The
Netherlands.
1
Promondia:
A Java-Based Framework for
Real-Time Group Communication in the Web
Ulrich Gall, Franz J. Hauck
University of Erlangen-Nürnberg, Dept. of Computer Science IV
Martensstr. 1, D-91058 Erlangen, Germany
{gall, hauck}@informatik.uni-erlangen.de
3SOFT GmbH, Erlangen, Germany
Abstract: The World Wide Web has evolved from a distribu-
ted hypertext system to a platform-independent graphical
user interface that integrates many network services. So far,
its technology has restricted it mainly to applications for
information retrieval.
As networks become ubiquitious and more and more
users have a permanent connection, there is an increasing
demand for other network services, such as real-time data
feeds, group communication, and teleconferencing. So far,
these services have been provided by various proprietary
software systems, which were hard to set up and use, and
thus not very successful.
Integrating real-time group communication services into
the World Wide Web is a natural way to make them more
accessible and will take the Web a step further on its way to
becoming the universal network application.
In this paper, we describe functionalities required for
these services and present an implementation based on Sun
Microsystem’s Java programming language. We focus on
the high-level functionalities and abstractions, but also
describe an object-oriented programming model for group
communication systems.
Topics: Integration of real-time channels, innovative
applications, programmatic and specialized user interfaces
1 Overview
Most people agree that communicating is the most impor-
tant activity in today’s information society. We spend a very
significant portion of our time - work and leisure - commu-
nicating in groups with other people, either directly (face to
face), or remotely (via telephone, email, or videoconfer-
ences). Therefore, finding more efficient means for commu-
nication between people is a very important area of
research. We believe that the most significant problem that
keeps people from communicating with one another via
teleconferencing software systems is their limited accessi-
bility.
The World Wide Web has become the most convenient
way to access information in the Internet. The main reason
for this is that WWW browsers integrate different network
services into a common, easily accessible, platform-inde-
pendent user interface.
Developing group communication services that support
conferencing from within the WWW is an excellent way to
improve accessibility of such services. This should be done
in a way that does not require specific proprietary features
of WWW browsers; it should be built on general mecha-
nisms provided by all browsers.
So far, the WWW does not support most of the features
required for these kinds of applications. For example, there
is no mechanism for server-initiated activity. HTTP is not
intended for real-time data feeds - it is state- and connec-
tionless. Using CGI scripts and forms, the user interacts
with the Web server rather than the browser.
Active contents, such as Java Applets, solve these prob-
lems. They are a very general mechanism supported by
most browsers, yet they are powerful enough to develop
serious network-aware applications.
In this paper, we will describe some general design
issues for group communication systems for the WWW and
present an implementation of such a system. The paper is
organized as follows. Section 2 provides a short introduc-
tion to group communication. In Section 3, we discuss some
design issues for the system. We present our proof-of-con-
cept implementation, called Promondia, in Section 4 and
discuss related work in Section 5. Finally, Section 6 summa-
rizes our results.
2 Group Communication
Group communication is the exchange of information
between a group of participants in a session
1
. Participants
may have different roles in a session. Information is
1.In the Internet-Relay-Chat (IRC) [OiRe93] this is referred to as a
channel, in most Web-based Chat systems as a room
2
exchanged using certain media, chosen according to avail-
ability and suitability for the information to be transferred.
Different types of group communication sessions have
evolved in the past in order to reach common goals as effi-
ciently as possible. These goals include entertainment, deci-
sion making, learning, and plain information exchange
about a common interest.
For example, a common pattern is a panel discussion
involving a host, several speakers, and an audience (see
Figure 1). Typically, all these participants are in the same
room. Host and speakers communicate to the audience and
among one another using audio and gestures. The audience
provides feedback using facial expressions and gestures.
The host may let individuals ask questions. The goal is to
communicate information the audience is interested in.
This type of group communication is based mostly on the
availability of media, not on their suitability. New technol-
ogy provides the opportunity to choose more appropriate
media to reach a given goal more efficiently. Using this new
technology in the example above could mean that the audi-
ence, distributed all over the world, can provide detailed
feedback without disrupting the speakers. This feedback
can be summarized automatically, the host and the speakers
can see immediate statistics and react accordingly. Anony-
mous questions can be submitted to the host, who could
choose to forward them or discard them.
Group communication can roughly be divided into two
categories: synchronous and asynchronous (see Table 1).
Asynchronous communication can be viewed as synchro-
nous communication with one virtual participant (like a
VCR recording a TV show) that stores information and pro-
vides them when requested by another participant. Thus,
synchronous communication is the more general concept of
the two.
Asynchronous communication can easily be integrated
into the WWW using HTML forms or Java front ends and
CGI scripts or database servers. Many products and services
have been developed for this.
Uni-directional real-time data feeds can also be seen as a
special case of group communication with one or more par-
ticipants, which are simply data sources, and a large number
of passive recipients.
In this paper, we focus on real-time, synchronous group
communication and on how it can be integrated into the
World Wide Web.
3 Design Aspects for Group Communication
in the WWW
Most systems for group communication in use today do not
clearly separate all of the four components that make up
their characteristics: network topology, network services,
programming models for and implementations of session
types.
There should be a clear distinction between these com-
ponents. We will discuss the first three in this section and
the last one in Section 4.
3.1 Client/Server Approach
Certainly, it is helpful to make a clear distinction between a
server subsystem and clients when designing an architec-
ture for group collaboration in the WWW. The server sub-
system provides functionality common to all session types,
such as logging, access control, and directory services. For
each session, it also contains a session-server object that
coordinates the communication between the clients and
determines the contents distributed in that session. This ses-
sion-server object may be generic or session-type specific.
A client runs on the participant’s system and provides the
front end that presents the session to the participant. Differ-
ent types of clients reflect the different roles for each session
type; when a participant joins, the appropriate client is
instantiated.
Figure 1: Session of a Panel Discussion
Audience
Host
Speakers
Session
Panel Discussion
Synchronous Asynchronous
Time frame “Real-time”
(seconds)
Delayed (minutes
to indefinitely)
Transfer of
information
When available When requested
Analogy in
traditional
media
Telephony
(bidirectional),
life TV
(unidirectional)
Voice mail,
Bill boards
New
technologies
Videoconference,
telephony, shared
whiteboard
E-mail,
threaded discussion
systems
Products ShowMe (SUN
Microsystems),
ProShare
(Intel Inc.)
Lotus Notes
(Lotus) ,
Databases in
general
Table 1: Synchronous and Asynchronous Group
Communication
3
For sessions with a large number of participants (>1000), a
scalable architecture is required. This can be achieved using
a distributed server subsystem. A network of servers share a
common name space and host server proxies on behalf of
their clients. These proxies are also session-server objects.
They may be generic and simply forward information to and
from a central main server, or they may contain semantics
for the type of session they serve (e.g., they summarize the
local results of a voting session).
Since the the session-server objects may be loaded via
the net and instantiated dynamically, a security model is
required that restricts their access to local resources. There-
fore, Java’s coarse-grained security model is not suitable.
The more fine-grained security model described in [Rie96]
may be appropriate.
3.2 Underlying Network Services
The system should be based on a reliable network service to
set up the software components and to exchange session and
user management data. However, for the actual information
to be communicated, it should be possible to use other net-
work services based on the requirements of the particular
type of communication. In this case, the system network is
used to exchange the references required to use the other
network services.
Network services that could be used include TCP, UDP,
IP Multicast, and more specialized protocols such as RTP
[SCFV96] or TIBCO Inc.’s Rendezvous information bus
[TIBC96]. A very early version of our system [Bego96]
used IRC [OiRe93] as the messaging backbone. CORBA
Events services [OHE96] could be used for strongly typed,
language-independent event multicasting.
3.3 Programming Models for Implementing
Session Types
Many programming models for real-time collaboration
have been suggested. The simplest and most basic mecha-
nism is message passing between the objects associated
with the participants. A convenient API can offer asynchro-
nous multicast for remote method invocation on all or a sub-
set of participants [RoGr96]. This model is very suitable
and intuitive to use for volatile communication-oriented
tasks, such as chatting. It can be refined by distinguishing
certain characteristics for the messages (e.g., unreliable
delivery or unspecified delivery order).
To identify different types of messages, it has proven
practical to allow for more than one named communication
channel per session [ITU122]. Clients interested in a partic-
ular type of message can subscribe to its respective channel.
That way, the different clients reflecting the different roles
only receive the information they need.
To allow for a reply to the messages sent, delayed return
values for asynchronous method invocation can be imple-
mented by creating a handle to represent the reply expected
in the future. This reference can then be used to wait for the
reply or to forward it somewhere. An extension of Java pro-
viding this is E, described in [E96].
Other, more sophisticated models can be built on top of
this simple infrastructure.
Model-View-Controller-based (MVC) approaches with
a replicated model, one view and one controller per user are
very suitable for collaboratively creating or modifying data.
However, they tend to be inefficient if all changes to the
model are immediately sent to all views. However, Graham
et al. report on significant performance advantages using
optimized network communication [GUN96]. If a more
sophisticated strategy is used to transmit changes only when
needed, application specific semantics have to be consid-
ered. This can be quite difficult to implement.
Gutfreund et al. suggest a Linda-like simplified tuple
space model for coordinating distributed applications
[WWWi96, Gele89]. This is a very lightweight approach to
the MVC pattern that provides a generic server and requires
all semantics in the client objects. This can also be used for
simple message passing, since clients may register for
changes on tuples. Lotus have a similar approach, using
“things” as state-keeping objects that also provide notifica-
tion services [DPK+96].
For synchronisation and floor control, token-based
mechanisms can be used to ensure data integrity [Burr96] .
This is an easy way to use collaboration-unaware programs
collaboratively, but severely restricts interaction between
participants.
Finally, real-time multimedia streaming requires sophis-
ticated network protocols with different quality of service
characteristics. It should be possible to integrate these ser-
vices and have them controlled by the application.
All these different approaches are very suitable for cer-
tain tasks, whereas they are inconvenient or inefficient for
others. We believe that these models should complement
each other rather than compete. A framework for group
Figure 2: Servers with Different Session-Server Objects
A
B
A
B
A
Clients
Server
Session-Server Object
A
A
A
A
A
A
B
B
B
