Collaborative%20Applets

1
Collaborative Applets

• Gordon Erlebacher
• School of Computational Science Information
  Technology
• FSU

2
Caveats

• I am describing my work since July 16, so many
  concepts are still rough
• Many of my explanations are simplified
• Not all my descriptions will be technically
  accurate, but they reflect my best understanding
  at this time

3
Problem

• Multiple users wish to share a java applet
• One user drives the applet the publisher
• Other users see what the first user does the
  subscribers
• Users should be able to collaborate
• Exchange information
• See what each other is doing
• Take control of full or partial applet

4
Approaches

• Rewrite AWT to handle remote communication
• Capture system events and transfer them to
  subscribers (lots of info)
• Capture higher level events (ActionEvents, etc.)
• Send bitmaps (shared displays)
• Reduced user interactivity

5
Collaborative Applets/Applications

• NAWT (Rewrote AWT)
• CollAWT (Rewrote AWT)
• RAWT (Remote AWT from IBM)
• Client-server
• JETS
• Users must use JET API in their applets
• Jasmine (2001)
• Applets run in outside framework. No changes to
  applet required (source not available)
• System seems to do what I require

6
Collaborative Frameworks

• Too many to mention
• Tango (Fox)
• Habenera
• Etc.

7
Imposed Restrictions

• Do not wish to rewrite AWT and Swing classes
• Users should not have to modify existing applets
  (source may not be available)
• Any modification to existing applets should be
  minimal
• Changes to applets should be sufficiently robust
  to allow for automation

8
User Interface Components

• AWT (depends strongly on underlying windowing
  system)
• Components, containers, panels, Frames, Buttons,
  Textfields, Scrollbars, etc.
• Swing (lightweight components)
• Written in Java
• More portable across systems
• Slower than AWT

9
Publish/Subscribe
Publisher
JMS Server
Subscriber 1
Subscriber n
10
Applets
isPublisher (0 or 1) passed to applet through
ltappletgt tag
Publisher Applet
Narada Server
Subscriber Applet 1
Subscriber Applet n
11
Simple examples AWT

• GraphLayout
• Publisherhttp//amur.ucs.indiana.edu/erlebach/app
  lets/graphLayout/publish.html
• Subscriber http//amur.ucs.indiana.edu/erlebach/a
  pplets/graphLayout/publish.html
• Molecule
• Publisher
• http//amur.ucs.indiana.edu/erlebach/applets/mole
  cule/publish.html
• Subscriber
• http//amur.ucs.indiana.edu/erlebach/applets/mole
  cule/subscribe.html

12
Event models in Java

• Events have a source
• Events have one or more destinations listeners
• Listeners (event destinations) are set by the
  event sources
• E.g. a user-defined button states that a panel
  in another window is listening to the action of
  this button.

13
Event Models

• Top level button receives an event
• The event is not transmitted to panel below the
  button (Java 1.x, x gt 0)
• Event time, (x,y), action, command (text field),
  etc.
• Event serializable

14
Life of an Event

• System level events (mouse clicks, mouse press,
  mouse drag, keyboard)
• Very simple x,y, button state, key combination
• Events occur over a widget
• Widget translates even into EventObject or one of
  its subclasses
• ActionEvent, MouseEvent, ItemEvent, etc.
• These events have increased information
• Time of occurrence, number of clicks, command
  associated with event (disable, press, highlight,
  etc.)

15
AWT Event Model
AWTEvent Peer Events
System Event (mouse click)
System Queue
Native Button
Java Button
Java Button peer object
Listener 1
Listener n
16
Lightweight Component Event Model
System Event (mouse click)
System queue is not used to process peer events
System queue used to send mouse clicks, paint
events, etc. Lightweight components paint
themselves
Lightweight Button
AWTEvent Peer Events
Listener 1
Listener n
17
Approaches

• Use Robots
• Allows application to post a system event
• System event is identical to event generated by a
  mouse click or a key stroke
• Java components respond accordingly
• Disadvantages of robots
• Too many events generated
• Cannot take advantage of event merging (managed
  by Java System Queue)

18
Approaches

• Better Approach
• Send serialized EventObjects (root of event
  hierarchy) across the network
• Recipient will transmit these events to their
  destinations
• Post these events to the system event queue
• Problem event sources are not updated
• E.g. text fields, selection items, etc.
• Solution (not satisfactory)
• Update sources based on event and event content
• Takes valuable computer time

19
Other issues

• EventObject contains source of event
• Event source is transient identical objects on
  different platforms cannot be checked for
  equality
• Solution
• Create hash tables to each object associate an
  index
• To each index, associate an object
• Assumption collaborating applets are identical
• Send object ID along with event

20
How to transfer objects(HashMap)
Object
Object ID (1,2,,n)
Object ID (1,2,,n)
Object

• Hash tables on all applets have the same number
  of components
• Assumes that components are not created
  dynamically
• I currently assume that all components have been
  created by the end of the init() method

21
Publish/Subscribe

• Use Narada Developed by Shrideep Pallickara
• Narada implements the JMS (Java Messaging
  Service) interface
• One applet is the publisher
• Other applets are the subscribers

22
Approach

• Publisher sends message to server
• Serialized event metadata (object id)
• Alternatively byte data
• Subscriber receives package from server
• Unserializes the event, sets the event source
  (AWTEvent) based on the object reference obtained
  from the hash table (the id is known)
• Post the message to the system queue
• Listeners receive the message and act upon it (in
  exactly the same way as the publisher)
• Low level routine (jms.processEvents) checks the
  source of the event and updates it accordingly
  (buttons, text fields, etc.)

23
JMS Messages

• Byte Messages
• Arbitrary combination of bytes, ints, longs, etc.
• BytesMessage msg session.createBytesMessage()m
  sg.writeInt(10)msg.writeFloat(14.7)
• Object Messages
• Send the serialized object
• ObjectMessage msg session.createObjectMessage()
  msg.writeObject(new ActionEvent())
• Meta Data
• Attach string metadata
• msg.setStringProperty(eventValue, (new
  Integer(value)).toString())

24
Object Messages
Event e Object o e.getSource() int id
hash(o) Message m m.setObject(o)
m.setStringProperty(id, String(id)
Narada
Message m Event e (Event) m.getObject()
objID m.getStringProerty(id) Object obj
hash(objID) e.setSource(obj) SystemEventQueue.po
st(e)
Pseudocode
25
Byte Messages
Event e int id hash(o) Message m
m.writeInt(id)
Narada
Message m id m.readInt() Object obj
hash(objID) Event e new xxxEvent()
SystemEventQueue.post(e)
Pseudocode
26
Event Serialization

• Most classes are serializable
• Only non-transient fields are serialized
• Events
• Object source (not serialized)
• Time stamp
• Modifiers (shift, meta key, etc.)
• ID (MOUSE_CLICK, MOUSE_PRESS, etc.)
• Etc.

27
Performance

• Object Messages
• Cost of serialization (publisher) and
  deserialization (subscriber)
• Conversions between strings and ints
• Simple format built into java Objects
• Byte Messages
• Fast, no conversions
• Subscriber and publisher must agree on user
  format
• Portability is reduced in exchanged for
  efficiency
• Still not as fast as raw sockets

28
Swing Hierarchy (subset)
Container
JComponent
doClick()
AbstractButton
JButton
JToggleButton
JList
JPanel
JCheckBox
JSlider
JRadioButton
JScrollPane
JTabbedPane
29
Swing Applets (byte messages)

• ActionEvent
• AbstractButton (objID)
• ListSelectionEvent
• JList (objID, selectedIndex)
• ChangeEvent
• JTabbedPane (objID, selectedIndex)
• JSlider (objID, value)
• MouseEvent, MouseMotionEvent (objID,x,y,modifier
  s,eventID)
• JPanel

30
Listeners

• AbstractButton
• ActionListener
• JList
• ListSelectionListener
• JSlider
• ChangeListener
• JTabbedPane
• ChangeListener
• JPanel
• MouseListener, MouseMotionListener

31
Message Arrival

• javax.jms.MessageListener interface
• Implement onMessage()
• Check message object source in following order
• Abstract button
• JList
• JSlider
• JTabbedPane
• JPanel (for mouse events)

32
Changes to existing Applet

• jmsApplet jms
• naradaInitialize()
• public void naradaInitialize() try jms
  new jmsApplet("amur.ucs.indiana.edu", 3045,
  isPublisher, this)
• catch (Exception e)
• e.printStackTrace()

33
Demonstration

• Publisher
• http//amur.ucs.indiana.edu/erlebach/applets/webma
  p1/publish.html
• Subscriber
• http//amur.ucs.indiana.edu/erlebach/applets/webma
  p1/subscribe.html

34
Extensions

• Allow each button to be a publisher or a
  subscriber
• Integrate the system within a larger framework
  (OKC, Anabas, Globus)
• Implement floor control (allow anybody to become
  a subscriber)
• Floor control override by the moderator
• Use JXTA for collaborative applet resource
  discovery
• Allow non-collaborative applets to be
  automatically integrated within the framework

35
TODO

• How to reduce number of messages sent (mouse
  moves and drags)
• How to update source widgets in a more generic
  fashion
• How to deal with swing
• What should be strategy for topic naming
• Applet resource discovery mechanism

36
TODO

• Benchmark the system
• Use robot extension of AWT to generate synthetic
  events at controlled intervals on the publisher
  and measure response time of subscribers
• Identify performance bottlenecks
• Narada (JMS)
• Serialization (Object Messages)
• Byte encoding (Byte Messages)

37
Acknowledgments

• I would like to thank
• Bryan Carpenter, Marlon Pierce, Shrideep
  Pallickara
• for enlightning discussions on various Java
  and web technologies and for increasing my
  proficiency with the Java Language