Sharedlet Development Guide

 

 

 

 

 

 

 

 

 

 

 


Sharedlet Architecture Overview

 

Introduction

 

A sharedlet by definition is a collaborative application that works within Anabas’s collaboration framework.  This type of collaborative application by definition has one or more participants in a distributed geography working on a common set of data.  This architecture allows developers to quickly develop vertical collaborative application and deploy in Anabas’s collaboration environment with little effort.

 

Anabas’s framework will provide many of the common features needed by any collaborative application allowing developer to focus on developing the internal logic.  Among many of the features the framework provide includes a robust and scalable communication infrastructure & API, moderation libraries, client/server & peer to peer support, and application management.

Sharedlet Basics

The Basic Logic

A sharedlet is made up of the following components:

 

com.anabas.sharedlet.Sharedlet Implementation
This is a wrapper class for a sharedlet and can contain some common client side logic for the sharedlet.  This implementation is optional.  If the sharedlet developer does not implement it, a default wrapper implementation will be provided by the framework.

 

com.anabas.sharedlet.Sharedlet View Implementation(s)
One more views makes up the sharedlet.  A view is a unique user visible perspective on the application.  For example, in a soccer game, there could be a referee view, a player view, and a goalie view.  Each client typically will display one or more of these views to the user.

 

com.anabas.sharedlet.SharedletSessionLogic Implementation(s)  
These components make up the centralized logic for a sharedlet.  For example, in a soccer game example, the game state would be stored in a session logic object.  This state would record the position of every participant, the location of the ball, and the score of the game.

 

Some sharedlets may not have this implementation.

 

SharedletView

SharedletView is a UI for the sharedlet.  A sharedlet can have one or more UI’s that represent different aspect of the sharedlet.  A control panel could be one view and a visualization canvas could be another view.

 

Each view can have one or more renderings as specified by the SharedletView.getRenderer(String format) method.  The format is the MIME Type format of the rendering.  For example, text/html is one type of rendering.  “application/java” is another type of rendering.

SharedletSessionLogic

 

The Info Description Classes

 

A sharedlet is like a collection of distributed Java Beans.  Each Sharedlet,SharedletView, and SharedletSessionLogic must have  a corresponding info class with the same name but ending in “Info”.  For example, TestSessionLogic and TestSessionLogicInfo.

 

Each info structure contains informational elements and deployment description and will be used by the framework to instantiate and configure the instance.

 

The Packaging

Once the implementations are finished, they are packaged as a jar file with a MANIFEST file containing one entry for each sharedlet as follows:

 

Name: <SharedletInfo class name>

Sharedlet: true

Implementing Sharedlet, SharedletView, and SharedletSessionLogic

 

The service framework provides several services that allow each individual pieces of the sharedlet to find and communicate with each other.  These basic services include:

 

Communication Service

It is the interface to the communication framework for the sharedlet built on top of an event bus architecture.  This architecture allows sharedlets to create streams and create publisher/subscribers on these streams.

 

Naming and Directory Service (aka GXO)

This is akin to directory based JNDI and allow sharedlets to locate services, other sharedlets, its SharedletViews (which may be instantiated separately).

 

Various services, objects, and parameters are located under fixed directories locations for the developer to access.

 

In fact, the framework provides a JNDI like interface for the sharedlet developer to access in the com.anabas.naming package.

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.

 

Sharedlet Deployed in the Applet Framework

 

For sharedlets to work within an applet framework, it must obey several restrictions:

·        Do not use ClassLoader.getResource() method.  Instead us ClassLoader.getResourceAsStream().
If the resource is an image, com.anabas.util.StreamUtil allows you to convert from an InputStream into a byte[] array and then construct the Image.
This is because Netscape VM’s do not support this method.

·        You will need to generate a proper Manifest file with SHA-1 and MD5 hash values for the sharedlet jar file.  Otherwise, you will be severely restricted in terms of sandbox security.

 

 

Sharedlet Naming Hierarchy Reference

 

/services/SharedletManager

/services/SessionManager

/services/LauncherService

/services/CommunicationService

/services/LayoutService

/services/CapabilitiesManager

 

/sharedlets/<type>/sharedlet

/sharedlets/<type>/views

 

/session_param/