LabSpace: The National Electronic Laboratory Infrastructure

Principle Investigators:

Rick Stevens - MCS

R. Evard -MCS

T. Disz - MCS

E. May - HEP

N. Zaluzec - MSD

=================

Executive Summary

=================

National laboratories. Advanced scientific instruments and data analysis

resources. High performance computers. Scientists, technologists,

professors, and students. The vision suggested in the call for proposals
is

to combine all of these over the National Information Infrastructure in
such a

way that makes distributed collaboration as useful to scientific
experiments

as being in the same location.

Distributed collaboration over the Internet is critical to the

success of today\'s scientific ventures, which are far-reaching and
often

require specialists from around the world to synchronize. We suggest
that it

is possible to provide a solution so powerful that it changes the way
that

scientists and researchers think about work and working together.

In LabSpace, we propose the creation of a set of electronic
laboratories, or

elabs, which will be networked institutions housing interfaces to
scientific

equipment, meeting rooms, private offices, and interaction areas. The

scientist\'s interface to these locations will be a browsing environment
based

on the familiar World Wide Web programs, and will be layered on a suite
of

groupware tools such as audio and video clients, as well as control
mechanisms

for remote scientific instruments and state of the art network transport
and

security.

The members of the LabSpace project are uniquely positioned in the
diverse

areas of networking, high performance computing, collaborative
environments,

innovative interfaces, and distributed scientific research. We propose a

program, that, over a three year period, will create electronic
laboratories,

build the basic tools necessary for interaction, and study the effects
of

these environments for three testbeds: an analytical electron microscope

laboratory, the CERN high energy physics project, and the LabSpace
project itself,

which will be a distributed development effort.

The results of this project, a National Electronic Laboratory
Infrastructure,

will be available to other scientific institutions during the creation
and

after the conclusion of the effort. Electronic Laboratories will be
built that

will contain unique research opportunities, information repositories,

and powerful computing and analysis equipment. This intuitive
environment

will bring together scientists and researchers from around the world.

=======================================================

Motivation and Need for Distributed Collaborative Tools

=======================================================

Today\'s scientific world is populated with fabulous resources, ranging
from

collider detectors to super computers, from advanced photon sources to
virtual

reality labs. Yet the most important resources are the scientists and

technologists who design and use these tools. They travel all over the
world

for the opportunity to work together, moving to and from the places
where the

scientific instruments are located, all in the name of furthering
scientific

research.

Perhaps one of the most important potential tools that we have today is
the

global information network, the Internet. It has the capacity to bring

together all of these resources. We simply need to put all the
instruments on

the network and let everyone work together remotely. This will cut down
on

travel and increase the amount of time that the people, our most
valuable

resource, can work together on experiments and research.

Yet the critical question remains: what is the most effective way to

accomplish this? We believe that any solution must take into account the

aspects of real laboratories that make collaboration effective. Beyond
the

obvious rooms with scientific instruments and libraries of information,
labs

provide meeting places with white boards, computing and media
infrastructure,

and other interaction tools. Most importantly, they create an
environment

where people can interact with each other professionally and casually in
ways

that make collaboration truly effective. We believe that all of these

functions must be incorporated into any successful solution.

To this end, we propose the creation of a National Electronic Laboratory

Infrastructure. Sites who wish to host distributed collaborations will
create

a networked interface to their facilities that will house their
scientists,

their tools, and their visitors. People will visit these laboratories
and

work in these laboratories, potentially spending as much or more time in
the

elab than in the lab. The natural interface provided by such an
environment -

looking at an instrument, talking to a fellow scientist, sharing a
virtual

white board - will promote natural collaboration without impeding the
process

with excessively complex technology.

These elabs will be available to any scientist with an ordinary
workstation

and an Internet connection. As more sophisticated tools such as CAVEs or
high

performance data engines become available, they will be integrated
seamlessly

into the environment, taking advantage of technology shifts while still

promoting collaboration with conventional systems.

The benefits to the users are clear. They will be able to maintain
contact

with their fellow researchers regardless of their location. They will be
able

to set an experiment in motion within an elab, and return at a later
date to

check on the progress. They will have a permanent and natural interface
to

their scientific instruments and to information archives. The tools that
they

need to carry out such interactions will be united under a common
interface,

as natural and as as powerful as the WWW browser upon which it is based.
As

technical limitations are removed, the collaborations will be more
productive

than before, with less stress on the individuals involved. Researchers
will

meet people with similar interests while working in the elabs, and new

partnerships will be formed. The electronic networked space will make a
new

form of people networking possible, promoting and enhancing the state of

scientific research in this country. A paradigm shift will take place,
and we

will all enhance our research and collaborative efforts.

By the completion of this project, a

system will be in place that will allow all of the National Laboratories
to be

on-line, sharing their resources with scientists around the world.

Current systems show that this is indeed possible. Many previous
projects,

such as Xerox PARC\'s famed \"MediaSpace\", have investigated how people
work

together when given the opportunity to share an electronic place. The
results

of all these experiments have been encouraging and educational, yet
their user

population has been limited to those at the few sites participating in
the

experiment. In LabSpace, we propose to open up the electronic
laboratories to

any qualified personnel in any location. The scale of the project and
the

number of participants will necessarily be larger than previous
collaborative

projects.

Other large-scale projects do exist. The most notable of these is the

ground-breaking MBone effort, which utilizes the multicast capabilities
of

TCP/IP to create audio and video sessions shared by users world-wide.

However, these projects are focusing on the technical aspects of the
multicast

implementation and on specific tools to exploit the potential. These
tools

can be used for interaction between people, but they are unwieldy and
have

limited use. Their focus is not on the scientist and his environment,
but

rather on the features of the specific tool. These tools are essential,
and

have a place within LabSpace, but they don\'t solve the collaboration
problem.

LabSpace focuses on the user. It creates a natural interactive
environment

capable of supporting any tools needed for joint research. It defines an
open

architectural framework that encompasses existing standards such as the
MBone

technology and the World Wide Web information structure, combining these
in

unique ways that will enhance natural collaboration.

In many ways, LabSpace is based on examples of MOO-based networked
spaces that,

while primitive, have been shown to be quite useful for researchers
spread

across time and space. BioMOO \[ref\] is one example of these
environments,

which brings together biologists into a text-based space. LabSpace goes
beyond

currently available MOO \[ref\] technology, combining the concept of a
networked

space with graphical tools, high-end interfaces, and the best available

security mechanisms.

We propose to create a National Electronic Laboratory Infrastructure.

We will start the work with several testbeds:

\- TelePresence Microscopy - using ANL\'s analytical electron
microscopes

\- HEP - CERN stuff

\- mcs/neu - distributed development

\- transition to APS

\- project supports long term goals of these activities

The participants in LabSpace bring together a uniquely strong set of
abilities.

The high performance computing environment, strong software development

history, and visionary leadership of the Mathematics and Computer
Science

Division of Argonne National Laboratory will focus and organize the
project.

The Materials Science Division of ANL brings to the project world class

facilities and expertise on electron microscopy and microanalysis and
has

existing local, national and international user base whose collaborative

efforts span government labs, universities and industry as well as
strong

ties to the secondary education environment.

Northeastern University brings several years of virtual environment

development and design to the project. The Electronic Visualization

Laboratory of the University of Illinois at Champaign/Urbana are
acknowledged

leaders in the field of revolutionary interface design. Together, these

government and educational institutions have a unique set of skills and

resources that will combine to make LabSpace, and distributed
collaboration,

a success.

==================

Technical Approach

==================

The fundamental goal of LabSpace is to promote and enhance open-ended

networked collaboration among scientists and researchers.

LabSpace consists of:

\- A powerful and intuitive virtual environment that creates a permanent

electronic laboratory on the network, allowing one to interact with

other people and with objects in natural ways.

\- Navigation and browsing tools which help one to locate collaborative

resources on the Internet.

\- High-capacity data archiving mechanisms which record and index
significant

events in the history of a collaboration.

\- Interfaces to the advanced scientific instruments which are the

focus of much interaction.

\- Modules which take advantage of the capabilities of modern
workstations,

utilizing audio, video, or any other interaction tool necessary to

support collaboration.

\- A scalable and flexible interface to the networks of today and
tomorrow.

The following sections discuss each of these in detail.

Persistent Electronic Laboratories

==================================

People, not scientific instruments, are the most important part of any

scientific project. If there weren\'t any people, there wouldn\'t be a

project in the first place, or there would be no one to understand it.

The same can be said of collaboration. The point of collaborating is

to get several people to work together. Therefore, in order to have a

successful distributed collaboration, the people and the

communications between them must be of highest priority.

The key to these experiments is to help the scientists involved work

together most effectively. They must be able to manipulate aspects of

the experiment, locate information that they need, and work together

using natural means of interaction. When working with a complex

laboratory machine, one wants dials and buttons, gauges and readouts.

When working with other people, one wants to turn to them and say

something, or to walk into a meeting room with a set of documents and

pass them around. One wants to sit around while the experiment runs,

monitoring progress while exchanging idle yet informative chatter.

Casual and natural activities like these are essential in making

distributed collaboration an effective reality.

An Interaction Metaphor

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

LabSpace creates persistent virtual locations on the network where

people can interact in natural ways. The spaces are organized around

centers of interest such as the National Collaboratories. They are

created in a flexible and extensible manner, allowing them to be

modified according to the project\'s needs. A researcher is able to

enter a location and interact with the people and objects located

within the space.

This paradigm provides endless opportunity for creating natural

environments which promote cooperation and interaction. Here are

a few examples:

\- A room which houses an analytical electron microscope. Located in the
room

are the interfaces to the microscope. When a scientist \"looks\"

at the microscope, the corresponding modules are initiated within

his session.

\- A meeting room adjoining the analytical microscope lab, which people
use

to gather and make plans, and to store working documents and to chart

project progress. The people in this room can interact with each other

because they share a multicast video and audio channel related to the

room. A white board on the wall is shared by room inhabitants as well.

In the first example, Jane and her colleagues were sharing a meeting

room.

\- A window between the meeting room and the control room, which, in

essence, shows a summary view of the experimental equipment being

used. It also indicates which control room personnel are active.

\- Another meeting room for a different group using the microscope. This

room is locked to non-participants because their experiment is
confidential.

\- A library that acts as an interface to archives of scientific
documents.

The librarian could be an intelligent agent, a simple index, or even

a real librarian. Other scientists using the library may well turn

out to be important resources as well.

\- Individual offices where people store their current work, and where

they go when they aren\'t actively involved in working with groups.

Their presense there may indicate that they are available for casual

conversation. Or they may shut their doors, indicating a desire

for privacy.

\- A viewing lounge that allows guests from the Internet to find out

about the experiments in progress without interfering with the work.

\- Collaboration \"complexes\" that join collaboratories and scientific

projects around the world into one virtual space.

Organizing resources and communication patterns into a spatial

paradigm creates an extremely powerful metaphor for interaction. A

place is an association between people working together and the

objects they\'re using. This knowledge can be used to coordinate the

technical modules which carry out the electronic communication,

minimizing the effort required by the scientist to initiate

connections and control. More importantly, it emphasizes the

relations between people and allows them to interact casually in a

social setting. By simplifying the user interface and making the

distributed communication more natural, virtual locations enhance

collaborative potential.

Several of these types of spaces are already in existence. AstroVR

\[ref\], a collaborative environment at CalTech \[?\], uses the MOO

server from Xerox PARC to create a virtual laboratory for astronomers.

BioMOO \[ref\] brings together biologists from around the world. The

InfoPark \[ref\] is a similar construction for systems administrators

from several different sites. Most of these environments are primarily

text-based, yet they are already significantly promoting collaboration.

The sociological aspects of these systems are currently being studied,

but informal feedback from the user communities is extremely positive.

The Elab Server

\-\-\-\-\-\-\-\-\-\-\-\-\-\--

A collaborative site or center runs a server, known in LabSpace as an

\"elab\", that acts as the interface for that site. It controls access

to the resources for which it is responsible and mediates connections

between researchers. It is extensible by a powerful programming

language, allowing spaces to be created and organized, as well as

allowing new interfaces and capabilities to be developed within the

space. The elab is up at all times, creating a permanent location on

the network. Thus, the elab becomes a persistent presence on the

net for information storage and personnel interaction.

Initially, the LabSpace project will build elabs using a MOO server

from Xerox PARC, after having added extensions for powerful

interfaces. The MOO server already provides much of the power needed

for LabSpace, allowing us to create an elab environment very quickly.

We anticipate that the national elab infrastructure will grow too

large for MOO within several years, therefore we will develop an

alternate system that is designed for more scalable and distributed

operation, yet will provide compatible functionality to the user

community.

LabSpace will provide the following deliverables to create the elab
environment.

\- An extended MOO server.

\- An initial elab environment, customized to each individual test site

and final installation.

\- Tools and documentation for extending the elab space.

\- A fully distributed and scalable system for elab implementation,

expected to be operational several years into the project.

The User Interface

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

Each user wishing to interact with an elab runs a program called a

\"browser\" that communicates with the server. The program takes on the

role of the user\'s capability broker, describing to the server what

types of services the user can support. Examples of these include an

audio/video connection, multicast capacity, or more advanced

interfaces such as a CAVE. It also invokes the user\'s local programs

which implement these aspects of the interface, and it validates and

authenticates connections. In these ways, it is acting as the user\'s

\"broker\", which is described in more detail below.

A number of user interfaces are possible, ranging from a simple text

module (appropriate for low-speed connections) to a modified graphical

WWW browser, depending on the capabilities of the user\'s environment,

Initially, development will focus on the WWW browser. A user will

connect to an elab by navigating the Web with the browser. They\'ll

interact with it by pointing and clicking much like the expected WWW

interface. As other interfaces are needed, they\'ll be created by the

brower. Walking into a room where other people are located will cause

their images to be displayed on the screen, and any sounds heard in

the room (typically conversation) will be played by the audio client.

If audio and video interaction aren\'t possible or desirable, or if a

more technical interaction with the elab is necessary, a text client

will be invoked. The possibilities for the user interface are quite

extensive, enabling one to take advantage of both the information

organization capabilities of WWW and the interactive collaborative

potential of a persistent location.

The deliverables that we will build for the user interface include:

\- An X-Windows-based browser similar to Mosaic which can utilize

the World Wide Web as well an interact with the elab server.

\- An ASCII text version of the same.

\- A protocol specification for browser/elab communication.

\- User documentation for the browsers.

\- A \"tutorial\" elab that browsers can be configured to connect

with on their initial session. This elab will be designed to help

users learn the capabilities of their browser and local environment

through experimentation.

Information Location

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

As many people are discovering, the Internet is a big place that\'s

easy to get lost in. While most users will know exactly how to locate

the elabs that they commonly work with, some may not have this

information when they begin. We provide an information distribution

mechanism that helps users locate the resources that they need.

An elab server will run a service called a \"catalog\" (which may be a

part of the server or may be separate). The catalog is associated

with a session or with a site and understands the local capabilities

and resources. It responds to queries about resources in a number of

formats, including HTTP, enabling elabs to send information to standard

World Wide Web clients. This capability leverages the ubiquity and

flexibility of WWW, providing a powerful network navigation mechanism

familiar to most Internet users. The security layer built into

the elab and the browser (as described later) allows the information

to be selectively distributed.

With regards to information location, the LabSpace project will provide:

\- A catalog mechanism for the MOO server.

\- An HTML-based central directory service of every elab wishing to

register. The default browser will have this WWW hotpoint available

as a menu option.

The Module Layer

================

In LabSpace, a scientist uses the browser as the primary user interface,
as it

provides navigation and elab communication capabilities. However, the

interfaces that are tailored to specific applications are split among

\"modules\" which implement the details of that type of interaction.
These may

be general teleconferencing applications, such as a window containing
images

of one or more co-workers, or very specialized interfaces, such as an
electron

microscope controller. Many different modules will often be active at
one

time, so that, for example, one may discuss the view of the microscope
while

working with it. The set of tools in use by one person, regardless of
their

type or use, is called a \"session\".

The principle role of a module is to work with one or more data streams,

acting as the user interface for the data. The module for an audio
source

data stream may be a program that drives audio speakers. A data stream

consisting of a series of white board modifications will probably be
sent to a

module that implements a white board, or may be sent to an archiving
mechanism

to be recalled later. Modules may be as simple as a clock or as complex
as

the interface to a collider detector. Several of these modules have
special

roles that help the session become a unit that works together rather
than

simply a set of tools vying for screen space.

The most important of the modules is called the \"broker\". It acts much
like

the mixing board in a sound studio. It mediates connections between
modules,

allows or disallows remote connections, and understands the capabilities
of

the user\'s collaborative environment. It works closely with the browser
(and

may in fact be part of the same program) to make remote communication as

smooth and simple as possible.

All of the other modules can be thought of as \"generators\" and/or
\"receptors\",

which, respectively, are programs which create data streams or handle
data

streams. A video camera is a generator, while a window displaying the
output

of that camera is a receptor. Many programs, such as a white board
interface,

are both. Specialized receptors and generators can act as filters, which

convert one form of data stream to another, or archivers, which store
data

streams for later access.

A collaboration between two parties is thus a conversation between two

sessions. A generator on one end arranges with its broker to negotiate
with

the broker on the other side. Once the two brokers have verified that
this

connection is authorized to take place, the remote broker passes the

connection on to the remote receptor, which proceeds to communicate
directly

with the generator. The data is passed in whatever format and by
whatever

mechanism is appropriate to those modules.

The specification of the protocol for communicating with the broker will
be

one product of the LabSpace research project. The individual modules\'

protocols will not be specified, but will be left open-ended, so that
modules

of arbitrary types may be added whenever appropriate. In this way, the

LabSpace architecture is open-ended, allowing tools of any type to be
developed

that still work within the framework.

The rest of this section describes the broker, data streams, and the
other

modules in detail.

The Broker

\-\-\-\-\-\-\-\--

The broker is the most important process at the module level of a
LabSpace

session. It acts as the central authority for connections, routing the
right

kinds of data to the right module. Each user will have a broker, as will
each

elab. The broker\'s roles include:

\- Connection Authentication. The broker validates remote connections

according to the security requirements for the session or for the

module(s) that will receive the incoming stream. A number of

different permission levels are available, ranging from authentication

based on public key encryption to allowing any connections at all.

By imbedding the authentication information in the broker, we

simplify the modules and make the user interface more uniform.

In most cases, the broker will work with the remote elab to establish

mutual trust, but in some cases the broker may need to override the

elab in order to ensure local security.

\- Module Management. The broker is aware of the capabilities of the

user\'s environment. For example, it knows if the user has an active

video camera, what data formats any of the available archivers can

handle, and whether or not the user has a three-dimensional

environment like a CAVE. It uses this knowledge to manipulate and

mediate data streams, routing them to the correct module, possibly

through appropriate filters. If the user in question doesn\'t have

a local CAVE handy, the broker may still be able to invoke a filter

that converts the CAVE data stream to a usable format - perhaps

an object model viewable on a workstation, or even simply the sound

stream from the CAVE.

\- Module Invocation. In the case when a data stream is sent from a

remote site and has been authenticated, but a local module is not

already running, the broker can start a module that handles the data

stream. This can be useful when one already has established an

authenticated session with a remote site which starts a new type of

interaction. The broker also uses the ability to invoke modules

when it needs to put filters in place.

\- Connection Establishment. The broker initiates connections with
remote

sites, working directly with the remote broker. The two brokers

mutually authenticate, exchange information about the data type(s)

of the proposed connection, invoke appropriate local filters, and then

pass the connection information (addresses, ports, keys, etc.) to the

module. Isolating this functionality in the broker allows the modules

to concentrate on their role of data manipulation, and localizes

connection establishment information to one location in the session.

\- Session state. In order to route data streams to the appropriate

module, the broker maintains a loosely bound state of its session.

It knows which modules are running, with whom they ar communicating,

and what their capabilities are.

There must be exactly one broker per session, where a session is

defined as a set of associated modules, most likely under the control

of one user. These need not all be executing on the same computer,

nor even at the same site.

The modules trust the broker to provide them with correct connection

information, thus the modules and the broker must have a secure

communication mechanism.

The broker acts as a coordinating mechanism for a session, which

helps to unite the potentially large number of modules into one

perceived entity. This is important for both the user and the

programmer interfaces.

The LabSpace project will provide:

\- A protocol definition for broker-to-broker communication.

\- A protocol definition for broker-to-local-module communication.

\- A broker implementation for both user sessions and elabs.

\- A security mechanism based on public key encryption and site

identification.

The LabSpace project will develop specifications for these protocols

as well as a sample implementation of a broker.

Data Streams

\-\-\-\-\-\-\-\-\-\-\--

Modules in LabSpace view the world in terms of data streams. A data

stream is any source of data that originates from a module and is

targeted for another (or many other) modules. Examples of data

streams include the output of an audio microphone, the data needed to

drive an interface to an electron microscope, and the sequence of

commands generated by a shared editor.

Data streams must be able to be combined, creating in essence a new

type of stream. This allows one to associate related data, such

as the audio and video produced by a telecommunications package. A

more complicated multiprotocol data stream might combine the head

tracking information from a head mounted display, the hand location

and position of a dataglove, and the sound from a microphone into

a complete model of someone doing working with virtual reality

equipment.

LabSpace does not attempt to define all types of data streams. It

leaves the details of the data streams up to the modules that will be

producing or using that data. However, LabSpace must be able to

define the protocols in ways that allow it to to combine streams,

archive them in useful ways, and to sequence them as they were

originally produced.

LabSpace will provide:

\- Details of the data streams for the modules that we implement.

\- A mechanism for combining and separating data streams.

Receptors

\-\-\-\-\-\-\-\--

Modules which can receive data streams are called receptors (noting

that many will also generate data as well). Examples

of receptors include:

\- video displays

\- virtual white boards

\- CAVE projectors

\- shared editors

\- displays for specialized tools, such as the image generated by

a radio telescope

Receptors need not be limited to simply receiving and displaying data,

however, any module with this capacity is a receptor.

The receptors that will be built by the LabSpace project include:

\- Video displays.

\- An audio interface.

\- A virtual white board client.

\- A shared editor for programmers.

\- A CAVE module for CAVEs and workstations.

\- A shared document viewer that supports version control.

\- A user directory service.

\- An interactive text module.

\- Interfaces to the scientific instruments at use in our test bed
sites.

The exact nature of these tools will be determined after careful

consultation with the user base. At the very least, they will consist

of remote monitoring and control modules for the instruments and

analysis tools suitable to the application.

\- Documentation for the above.

This list of modules may be updated somewhat over the duration of the

project as certain features and aspects of wide-spread distributed

collaboration become better understood. Where it makes sense, such as

with the audio, video, and white board interfaces, the modules will be

able to use existing MBone protocols in order to ensure compatibility.

Generators

\-\-\-\-\-\-\-\-\--

Generators are modules which create a data stream. A few sample

generators include:

\- microphones

\- video cameras

\- super computers generating visualization data

\- the input to a shared editor

\- an analytical electron microscope

The LabSpace project will provide generators that correspond to each of

the receptors listed above.

Filters

\-\-\-\-\-\--

Modules which act as receptors for a data stream, transform it in some

way, and then pass the data on are known as \"filters\". They can be

used to turn one form of data into another, combine several data

streams into one, extract one type of data from a complex data stream,

or take one stream and send it to many places, to name a few
possibilities.

The broker can invoke filters in order to transform data into

a format that the local modules can understand, or the user may start

one in order to explicitly manipulate the data as desired.

The filters delivered by the LabSpace project will depend enormously

on the needs and specific hardware requirements of the testbed
communities.

Playback Engines

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

A special type of receptor that has been designated to store data

streams is known as an \"playback engine\". These engines form a

critical part of the elab environment.

Playback engines have many intriguing possibilities:

\- They may be used to index and search the data they store. (This is

known to be a very difficult problem with some types of data).

\- They can be used to maintain the state of various modules, such as

virtual white boards, such that the next time the module is

initiated, it can have the same state as it did the last time it

was used.

\- They may develop into permanent repositories for important

data, recallable and accessible according to the modules needs and

capabilities.

\- As in the example above, they can act as virtual VCRs, essentially

recording a collaborative session, portions of which could be

replayed at a later time.

Playback engines will need to have significant processing ability and

off-line storage capability, and will most likely require high-end

scalable I/O computers supporting the archiving and recall capability.

The LabSpace project will provide:

\- A playback interface for elabs.

\- A playback engine implementation that takes advantage of super
computers.

\- A simpler playback engine suitable for use on smaller computers.

\- A method of storing data that allows one to locate and search
relevant

archives.

Module Layer Summary

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

At the module layer, LabSpace carefully distinguishes roles of the
modules,

separating concerns as much as possible. The broker takes on the role of
the

session organizer, mediating connections and keeping track of the
capabilities

of the various modules.

This organization allows one to develop both high- and low-end
applications

that can interoperate, and focuses the modules on their role - handling
the

communication data that is critical to a succesfull collaborative
experience.

The Communication Layer

=======================

LabSpace expects, naturally, to utilize a network of some type. Most, if
not

all, of the people sharing the collaborative environment will be doing
so over

digital networks. An important goal of LabSpace is to operate
independently of

the particular network type that is used, yet to take advantage of
features

provided by the network when they are available.

For example, not all network transport systems provide multicast
support, but

it is essential to some forms of large-scale communication. Therefore,

multicast capability is supported within LabSpace, but is not required.

At the network interface, LabSpace supports these ideals:

\- Unicast, multicast, and broadcast will be available if they are

supported by the network.

\- Secure communication based on public key encryption will be
supported,

as will other degrees of security, including host-based and

domain-based restrictions as well as completely insecure communication.

\- The details of the network implementation will be hidden in order

to make code as portable as possible, but important information, such

as potential bandwidth difficulties, will be available to the client.

LabSpace\'s design is not tied to a specific network implementation. It
will

work using TCP/IP or HIPPI, over wireless networks or through fiber
optic

cables.

The initial implementation of LabSpace will be built on TCP/IP, but a
library

will be provided that abstracts away the details of the networking

implementation, allowing for portability of programs that use this
library.

In order to accommodate existing code, the use of this library will not
be

required. Should a client wish to directly manipulate the network in
order to

exploit multicast, it is free to do so. However, the library will
provide

network independence that the client may not otherwise achieve.

Scalability Issues

==================

This model is expected to scale quite well to approximately one hundred
users.

When the population involved in a collaboration grows beyond that, the
elab

server and the user\'s broker may become bottlenecks, although not for
every

application. For example, if the interaction is broadcast or multicast
over

an insecure channel, any number of people will be able to tune in and

participate (much like MBone videos). Should the channel need to be
limited

to a thousand specific people, they could all be given a particular
access key

that the elab broker would require to authenticate the session, but even
the

state traffic in the elab server is likely to be excessive.

We feel that a hundred users will be quite satisfactory for the first
years of

the project. However, as mentioned above, one goal of the project is to

develop a more distributed, peer-to-peer elab architecture that will
scale

arbitrarily.

We do not expect broker traffic to be a significant problem, as the
broker is

primarily involved with control information, not actual data. If broker

traffic is too heavy and creates a bottleneck, however, methods of
delegating

responsibilities will be explored, including using several brokers as
proxy

agents, and dividing responsibilities across multiple processes or
machines.

In general, the scalability of the collaboration is more likely to be
limited

by human constraints rather than technical restrictions. A thousand
people

watching a presentation is not difficult to manage, but a thousand
people

having a conversation is not going to be a success (unless you consider
total

anarchy a success), regardless of how well the tools are built.

Technical Summary

=================

LabSpace defines an open architecture for flexible and scalable
collaboration.

It consists of several levels of abstraction, each designed to simplify

creation and take advantage of existing standards. The network layer is
the

foundation for the communication mechanisms. The module layer brings
together

a myriad of useful tools. On top of these is the laboratory layer,
which,

combined with the playback engine, creates a shared, permanent space
with a

sense of history. The result is a powerful and intuitive architecture
focused

on the user and the user\'s needs for distributed collaboration.