Check out the new USENIX Web site. next up previous
Next: Discussion Up: The Experiment Previous: TicTacToe - Two party

Multi-party meeting scheduler - Broadcast with synchronization

In this application, a user tries to schedule a meeting time with a group of participants. The application is written such that it first gathers previously scheduled appointments from the calendars of all participants, finds a conflict-free time, and lastly updates individual calendars to add the new meeting. The data flow pattern for this application is shown in Figure 2c. The individual calendars are stored on a set of servers (perhaps, the individuals belong to different administrative domains). The application uses a GUI component to interact with the user for initiating a meeting request, a Planner component to access individual calendars, and a Scheduler component to schedule a meeting time.

NetPebbles:
The NetPebbles script instantiates a GUI component at the requester's machine for reading details about the meeting request (meeting date, duration, subject, and list of participants). The script then migrates to the location where individual participant's calendars are stored. The Planner component is used to access scheduled appointments for the requested meeting date. After collecting information about all the appointments, the script uses the Scheduler component to determine the meeting time. After the meeting time has been finalized, the script visits each of the Planner components to update the participants calendars. The script completes execution by displaying a confirmation message at the requester's machine.
RMI:
In the RMI version, ``Impl'' servers are started for the Planner, Scheduler and GUI components. The client implements the application logic by sending messages to these ``Impl'' servers.
Aglets:
Although an Aglet version is not implemented at this time, the application logic is similar to NetPebbles. An agent performs similar tasks as the NetPebbles script.



Ajay Mohindra
Mon Mar 16 14:45:01 EST 1998