---------- Forwarded message ----------
Date: Fri, 26 Jan 2001 16:59:35 -0500
From: Geoffrey Fox <fox@csit.fsu.edu>
To: Sung-Hoon Ko <shko@csit.fsu.edu>, Ahmet Uyar <auyar@csit.fsu.edu>
Cc: John Yin <johnyin@anabas.com>
Subject: Anabas Stuff

Here is Anabas Infrastructure in a jar file
There is also Overview of Sharedlets and
Shared Display format

As this is proprietary, pease keep track of where it is!
Please contact John Yin if problems

John: I chopped my team into groups and Sung-Hoon (who did JMS work)
and Ahmet (who has been working on HearMe) will be leading "infrastructure"

Advanced Sharedlet

Sharedlet Do’s and Don’ts

Communication

It is recommended that each sharedlet, when creating streams to communicate between views and session logic, to use as the stream name a derivative of its MIME Type. For example: x-sharedlet-whiteboard/private.

This way, communication stream conflict will not occur.

In future versions, when security is implemented, this convention will be forced so it is a good idea to implement it this way now.

Event Driven

The recording/playback service provided by the framework will recording all events sent to the sharedlet and play it back at a later time. In order to better support recording/playback, a sharedlet’s communication mechanism should have the following characteristics:

(1) Sharedlet UI changes should be triggered based on received events.

(2) If the sharedlet contains non-deterministic elements, the result of the non-deterministic action should be broadcast as an event and the state updated accordingingly.

Capability, Roles and Moderatable Element

Overview

The sharedlet framework provides functionality to easily enable moderation in the collaborative environment. Each sharedlet can be defined to have the following:

· Capabilities
Each capability is a raw feature that the sharedlet will ever want to access control. In the whiteboard sharedlet example, the ability “draw” and write “text” are two capabilities

· Roles
A role is a list of capabilities that are enabled. This definition is used to define the initial environment for a user when the user’s virtual classroom or collaborative application launches. This parameter is normally set by the management framework via some parameter to the sharedlet framework.

A role also has a view definition associated to restrict what SharedletView’s are available to what role.

· Moderatable Elements

A moderatable element is a convenient group of a set of capabilities that a moderator or host can change during the meeting or collaborative session. This list of elements allow the framework to present a user understandable set of moderation capabilities.

All of these elements are defined by the sharedlet developer in the SharedletInfo class via the following methods which return vectors:

getModeratableElements();

getRoleInfos();

getCapabilities();

CapabilitiesManager

All moderation information are managed by the CapabilitesManager service within the sharedlet framework. The capabilities manager setups initial capabilities from the role definition for the invocation and provide API’s that allow sharedlets to toggle moderatable elements on other user’s instance of capabilities managers.

A sharedlet that supports moderation should check with the CapabilitieManager’s isCapable() method to see what is enabled and not enabled. It should also register as CapabilityListeners so that capabilities change notifications can be delivered to the sharedlet.

The capability manager itself has 3 possible “roles” or modes: Host, Moderator, Slave.

In Host mode, all of the capability manager’s APIs are available for use. This mode is equivalent to “super user” access in terms of moderation.

In the Moderator mode, the setRemoteMode() API is not available. This will not allow someone whose capability manager is in Moderator mode to change someone’s status thus limiting the proliferation of “super user” access.

In the Slave mode, only checking local capabilities are available.

Quick Example

The whiteboard sharedlet defines the following:

class WhiteboardSharedletInfo extends SharedletRCUtil implements SharedletInfo {

public WhiteboardSharedletInfo() {

// Define the list of all capabilities this whiteboard supports

setCapabilities(“draw,text,annotate”);

// Define the presenter role

setRole(“Presenter”,”draw,text,annotate”,”Control Panel,Whiteboard Canvas”);

// Define the co-presenter role

setRole(“Co-Presenter”,”annotate”,”Control Panel,Whiteboard Canvas”);

// Define the participant role

setRole(“Participant”,””,”Whiteboard Canvas”);

// Define a single moderatable element that a moderator or host can change.

setModeratableElement(“Present”,”draw,text,annotate”);

}

}

Note: WhiteboardSharedletInfo extends com.anabas.sharedlet.SharedletRCUtil which provides some bookkeeping functionality to make the definition of capabilities, roles, and moderation easier.

The actual moderation menu items and UI will be presented to the user via the virtual auditorium sharedlet that comes with the framework.

Sharedlet Session Logic

Each sharedlet may also implement session logic to hold its centralized logic. The session logic will instantiated and initialized via the init(Context ctx) method before the meeting starts and any of the SharedletViews are initialized.

This is used to implement client/server model for sharedlets. Typically, there will be a session logic container (application server) residing on the server side that will instantiate the logic, manage its context, and provide scalability and fault recovery.

Communication between the session logic residing on the server and views residing on a client can be done by getting a handle to the same stream via the stream name. The stream naming convention (of basing names on the sharedlet MIME type) will aid in this connection.

The right model for developing a client/server based sharedlet is to create a channel for every session logic and add the session logic as the only subscriber. Each client side sharedlet component (i.e. sharedlet view), will attach as publishers to this “private” session logic channel (in effect making it a queue). This mechanism allows client to make requests or stream data to the server.

There should also be a public channel for delivering public messages. All client side requests will be broadcast on this “private” channel. The session logic the process the request and broadcast the results to the public channel.

Example

Sharedlet Framework Inner Workings

The following description of how a sharedlet initializes and run should help a sharedlet developer to understand the environment in which it run.s

The management system will initialize the sharedlet framework as follows:

(1) Initialize the Sharedlet Session Logic server

(2) Launch the client side sharedlet framework UI with:

a. A defined set of sharedlets to run

b. 1 role for each sharedlet to run

c. The unique meeting context so the framework can set the correct context.

d. The location of the event bus server

(3) The sharedlet framework UI setups the sharedlet environment by:

a. Setting up the sharedlet context using the meeting id

b. Bind the appropriate session parameters in the context under session_param/

c. Create and intialize the sharedlet services under services/

d. The sharedlet manager service will instantiate the appropriate sharedlet info files

e. The layout service will instantiate the views and the sharedlet themselves and render the UI

This type of framework allow easy customization for vertical markets by customizing the feature set (via what sharedlet to run) in initialization. Eventually, when SharedletInfo is completely replaced by XML based configuration file, the deployment and running behavior of sharedlets can be customized to a vertical market as well.

Attachment: EventBusProtocol.doc (62k) -- View Attachment