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 the following:

• 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.