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.
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 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.
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.
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
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:
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.
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.
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.
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.
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();
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.
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.
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.
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.
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.
/services/SharedletManager
/services/SessionManager
/services/LauncherService
/services/CommunicationService
/services/LayoutService
/services/CapabilitiesManager
/sharedlets/<type>/sharedlet
/sharedlets/<type>/views
/session_param/