previous chapter table of contents next chapter

Remote Events

Unlike the large number of event classes in the AWT and Swing, for example, Jini uses events of one type, the RemoteEvent , or a small number of subclasses of RemoteEvent. The RemoteEvent class has these public methods (and some inherited methods ):

 package net.jini.core.event; public class RemoteEvent implements java.io.Serializable {     public long getID();     public long getSequenceNumber();     public java.rmi.MarshalledObject getRegistrationObject(); } 

Events in Beans and AWT convey complex object state information, and this is enough for the listeners to act with full knowledge of the changes that have caused the event to be generated. Jini events avoid this, and convey just enough information to allow state information to be found if needed. A remote event is serializable and is moved around the network to its listeners. The listeners then have to decide whether or not they need more detailed information than the simple information in each remote event. If they do need more information, they will have to contact the event source to get it.

AWT events, such as MouseEvent , contain an id field that is set to values such as MOUSE_PRESSED or MOUSE_RELEASED . These are not seen by the AWT programmer because the AWT event dispatch system uses the id field to choose appropriate methods, such as mousePressed() or mouseReleased() . Jini does not make these assumptions about event dispatch, and just gives you the identifier. Either the source or the listener (or both) will know what this value means. For example, a file classifier that can update its knowledge of MIME types could have message types ADD_TYPE and REMOVE_TYPE to reflect the sort of changes it is going through.

In a synchronous system with no losses, both sides of an interaction can keep consistent ideas of state and order of events. In a network system this is not so easy. Jini makes no assumptions about guarantees of delivery and does not even assume that events are delivered in order. The Jini event mechanism does not specify how events get from producer to listener ”it could be by RMI calls, but it may be through an unreliable third party. The event source supplies a sequence number that could be used to construct state and ordering information if needed, and this generalizes things such as time-stamps on mouse events. For example, a message with id of ADD_TYPE and sequence number of 10 could correspond to the state change "added MIME type text/xml for files with suffix .xml." Another event with id of REMOVE_TYPE and sequence number of 11 would be taken as a later event, even if it arrived earlier. The listener will receive the event with id and sequence number only. Either this will be meaningful to the listener, or it will need to contact the event source and ask for more information about that sequence number. The event source should be able to supply state information upon request, given the sequence number.

An idea borrowed from systems such as the Xt Intrinsics and Motif is called handback data. This is a piece of data that is given by the listener to the event source at the time it registers itself for events. The event source records this handback and then returns it to the listener with each event. This handback can be a reminder of listener state at the time of registration.

This can be a little difficult to understand at first. The listener is basically saying to the event source that it wants to be told whenever something interesting happens, but when that does happen, the listener may have forgotten why it was interested in the first place, or what it intended to do with the information. So the listener also the gives the event source some extra information that it wants returned as a "reminder."

For example, a Jini taxi-driver might register interest in taxi-booking events from the base station while passing through a geographical area. It registers itself as a listener for booking events, and as part of its registration, it could include its current location. Then, when it receives a booking event, it is told its old location, and it could check to see if it is still interested in events from that old location. A more novel possibility is that one object could register a different object for events, so your stockbroker could register you for events about stock movements, and when you receive an event, you would also get a reminder about who registered your interest (plus a request for commission ).


A Programmer[ap]s Guide to Jini Technology
A Programmer[ap]s Guide to Jini Technology
ISBN: 1893115801
Year: 2000
Pages: 189

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net