User
Guide
Overview
DistView
Tools
Related
Services
Installing and Running CBE
servers
Compiling the
package
Running Session Manager
Running DistView-Based Applets
Developer
Docs
Javadoc
Registry
Server
Sample
Clients
How
to ...
Known
Problems
DistView is a prototype multicast middleware
service for building collaborative applications. Written entirely in
the Java programming language, DistView
provides group communication services that meet the various shared state
management needs of collaborative environments. It provides a rich interface
for group and session management, the ability to ensure totally ordered
message delivery, a lock-based distributed synchronization mechanism, and
support for selective window sharing.
DistView is also used as data dissemination service, with delivery
semantics ranging from a push-based scheme, where the communication
system distributes large amounts of data of various types, obtained from
different publishers, to the existing subscribers, to a pull-based
approach where clients connect occasionally and transfer in asynchronous
mode data previously existing in the system.
Stateful group communication services. A server pool
maintains the shared information, both in memory and on stable storage.
Publishers submit data to the communication servers, subscribers receive
the data either in synchronous or asynchronous mode. Collaborative applications
are provided services such as: shared state maintainance, incremental state
update, persistence, group membership awareness.
The services are provided by the Corona stateful multicast server and they are designed to support both synchronous and asynchronous collaboration over the World Wide Web, where collaborating clients may be dynamically downloaded over the internet.
The DistView framework has been implemented and is currently extensively used in the context of the UARC project, an experimental testbed for wide-area scientific collaboratory work. This testbed is implemented as a large object-oriented distributed system on the Internet and provides a collaboratory environment in which a geographically dispersed community of scientists perform real-time experiments at remote facilities without having to leave their home institutions. Client applications supported by the Corona services provide the users with various facilities for remotely conducting their science. These include various shared data viewers for graphically displaying instrument data, a multi-party chat box for exchanging textual messages, and a notebook-like draw tool for saving and sharing notes, images and drawings.
Corona is the communication server used by DistView. It provides the following services:
- Group Communication: A group forms the basic unit of communication in Corona. A group is defined to be amembers. A group has a shared state and the members of the group operate on the shared state by accessing and modifying the shared objects in the shared state. Corona requires that a process has to be a member of a group in order to operate on the shared state of the group. The group members communicate with each other by exchanging messages among themselves. Corona supports both unicast and group multicast communication. Total ordering delivery semantics can be ensured by sequencing the messages in the server.
- Group Membership: Corona provides interfaces for creating, deleting, joining, leaving a group, etc. It also provides support for an important social aspect of collaboration, awareness- users collaborating over shared state want to be aware of each other and their activities. The system makes this information available to client applications, via queries to the server or notifications of membership changes.
- Shared State Management: The shared state of a group in DistView is maintained by the server, as opposed to other multicast systems, where the state of the group is maintained by the clients. In this sense, the server is stateful. A group may be characterized as either persistent or transient. A persistent group and its shared state exist even when the group has no members. A client joining a persistent group will receive the state of the group's shared data. A transient group ceases to exist when it has no members, and its shared state is lost. Persistency is achieved by logging the group state to the disk and it is an important feature in the context of asynchronous collaboration.
The updates applied to the shared state may be either incremental (e.g., the shared state of a ChatBox consists of the sequence of messages exchanged by the group members) or changes to the state of the shared objects representing the state (e.g., a Whiteboard).
Corona also provides support for state log reduction. Since the communication service is general-purpose, the interpretation of the semantics of shared data is the responsibility of collaborating processess. Therefore, the client application is responsible for providing the checkpointed state of the group for reducing the state log.
The ChatBox allows participants to exchange textual messages. It also
provides awareness information about the group membership. A message can
be either multicasted to all the members of the chat group or sent to a
particular member as a private message. All teh participants get the messages
in the same order, since the mesasges are serilaized by the communication
server.
The shared state of the ChatBox is defined to be the history of messages
group members have exchanged. The history is updated in real time as more
messages are exchanged, and when a new participant joins an on-going chat
session, he is given the history of exchanged messages (the user has the
choice of receiving all the messages or a specified number of the latest
messages). An update in the chat box, i.e. a new message, does not contain
the complete information about the current shared state of the application
and thus does not override the existing value of the shared state; the
update contains an incremental change. The user has the option of
receiving an audio notification when a new message arrives, for the case
that the ChatBox application is running in the background or the user is
doing some other work.
The WhiteBoard application is used to share images, drawings, and text
during a collaborative session. The contents of the canvas can be saved
to/loaded from the local hard disk or it can be exported as a collaborative
object in a room. In addition to providing drawing capabilites and support
for importing/exporting pictures, the WhiteBoard also provides telepointing
capabilities for interactive discussion (eventually in conjunction with
using the ChatBox) over the contents of the shared canvas.
The shared state of the WhiteBoard represents the state of the set
of objects on the canvas. The application is able to checkpoint
periodically its state, thus allowing the server
to trim the log of the state. At any point, the shared state of the WhiteBoard
is represented by the last checkpoint plus the sequence of the state update
messages since the checkpoint.
Mural is a set of shared data viewers for grapically displaying both real-time and archived intrument data. The data is provided by a separate service, the Salamander data dissemination service. A shared data viewer provides multiple scientists with a synchronized view of live instrument data, including the range of data being displayed and the physical appearance of the viewer. Mural is built on the concept of selective window sharing, allowing users to share not only the data displayed, but also the look and feel of the display window and the parameteres of the display (axis, scale, etc). When a scientist resizes his or her copy of the viewer, the viewers of the scientists' colleagues also change to the same size.
Session Manager provides an interface to support collaboration by enabling
user-extensibility and dynamic reconfiguration of shared workspaces,
based on the metaphor of rooms. Rooms serve as the high-level grouping
mechanism for group-aware applets and users as well as arbitrary
data objects. Users are provided with a list of the existing rooms and
they can enter the rooms in which they want to collaborate. In the room,
they bring up applets or URLs which let them work together with the people
in the room.
Rooms can be used not only for synchronous collaboration but
also for asynchronous collaboration because of the persistency of
their state across sessions. Room participants may have diffrent roles
in a room (such as administrator, member and observers).
Through the Session Manager, the following needs of collaborative environments are addressed:
- support for multiple tools in shared workspaces, both domain-specific (such as data viewers in UARC, connected to external services) and domain-independent (e.g., multi-user chat, shared whiteboard, etc.)
- support for both private and shared workspaces and the ability to dynamically move tools and data between the workspaces
- user-extensibility - users can create/delete rooms and add/remove collaborative tools and Uniform Resource Locators (URLs) to/from the rooms for collaboration purposes
- uniform access to collaboration environments over the Web from multiple platforms
- mechanisms for access control
- support for user roles, particularly observers, so that open access over the Web to a collaboratory is not intrusive to the scientific work
The Registry Server is a non-interactive server application that maintains account information for DistView users. Users are added by a distinct user called the admin user, which is created by when the service is first initialized. Associated with each user is a password that must be provided to gain access to the Session Manager. This password is stored as a hash value in the database and is, after creation, never available to the system.
The guest user is created at initialization of the registry server. This user is intended to be used as visitor account, with lesser access rights than other (password protected) users. Initially, this user is created without a password, but one can be assigned by the admin as desired. The number of simultainious guest users allowed in the system is a admin configurable parameter.
The registry server supplies the following features through a JAVA API:
- Electronic mail forwarding: through the API, applications are able to forward mail to specified users.
- Query the registry database: applications can view information associated with each user, or retrieve the all entries in the database. This information includes: username, electronic mail address, and password.
- Modify the registry database: methods for adding and altering fields of the user information in the database.
