In short, AMEETZER has the following novel features : 1. An Iterative Reservation withOut Commitment (IROC) scheduling protocol that achieves soundness and flexibility in utility-based scheduling [2,3] and negotiation [4] respectively among autonomous agents without forcing the user to commit a meeting [3] unless he or she is notified and wishes to do so.
2. A uniform fuzzy constraint satisfaction framework to represent and reason with both hard and soft meeting constraints, be it a user's preference (goal) or a situation to be prevented (constraint). Potentially this would enable constraint satisfaction in a richer inference framework [5] and in a massively parallel computational paradigm [6].
3. A two-layer (macro and micro) multi-agent architecture with inter- and intra-agent communications respectively to achieve high modularity and concurrency. Distributed networked AMEETZERs interact with each other with the support of the name service agent, Registry, and room management agent, Room Manager. Within an AMEETZER, Receptionist, Scheduler, Messenger and Dispatcher cooperate to fulfill a user's meeting scheduling requirements.

In this article, we focus on the software architecture. In particular, we see how to structure both multi-agent and agent architectures as Java processes and threads respectively. Consequently, we illustrate how to realize inter- and intra-agent communications using Java sockets and built-in synchronization mechanisms with object serialization, which is crucial to achieve high-level agent message passing. Last but not least, this article also touches on issues of registry implementation.

Software Architecture and Java Implementation
Macro-Architecture
As shown in Figure 1, AMEETZERs are designed as distributed personal software agents that interact with their users and collaborate with each other and the system agents across the network to schedule meetings automatically.

With distributed architecture, meeting requests that involve disjoint sets of attendees and resources can be scheduled concurrently, in contrast to a centralized approach where all meetings are scheduled by a central scheduling agent. Not only will the latter approach be subject to communication and processing bottlenecks, it will also face fault tolerance and complex schedule maintenance issues.

The IROC scheduling protocol is shown in Figure 2. It is carried out in three stages:

Stage 1: Calendar Query
The host AMEETZER requests the calendars within a specified range (i.e., meeting the time horizon as specified by the user) from the attendee AMEETZERs and Room Manager, instantiated with their preferences.

Stage 2: Iterative Reservation
With all retrieved calendars, the host AMEETZER infers the optimal meeting time using a uniform fuzzy inference framework. In the case where the scheduling problem is not over-constrained, a valid optimal meeting time, respecting various hard and soft constraints, will be found. The host AMEETZER then requests the attendee AMEETZERs and Room Manager to reserve the scheduled time. If an attendee's (or Room Manager's) calendar is still available (i.e., has not been reserved by other concurrently scheduled meetings), the corresponding time slot is marked and its status replied to the host AMEETZER. The host AMEETZER may have to iterate this reservation process for $K$ times, each with the $k^{th}$ optimal time, or until all reservations within a single iteration are successful, whichever is earlier.

Stage 3: User Confirmation
When the calendars of all attendees (including host) and Room Manager are reserved successfully with some (sub-)optimal time, the host AMEETZER initiates a user confirmation process. Each AMEETZER notifies its user about the scheduled meeting and seeks his or her acceptance, which is replied to the host AMEETZER.

Within the IROC scheduling protocol, there are four situations where a meeting scheduling can fail (indicated by asterisk ($*$) in Figure 2):
1. During Stage 1, some attendee(s) is not contactable.
2. After inference, no commonly free time slot is available.
3. After Stage 2, some reservation(s) is still not possible after $K$ attempts.
4. During Stage 3, some user(s) rejects the meeting.

Whenever one of the above situations arises, the host AMEETZER broadcasts a meeting cancellation message to the relevant AMEETZERs and Room Manager to cancel a meeting. The message passing for these meeting cancellations is not shown in Figure 2 for readability.

AMEETZERs and system agents (Registry, Room Manager) are implemented as Java processes running on different hosts.

Registry
As a user is allowed to run his or her AMEETZER on any host at any time, the only way to cope with dynamic user mobility is to have a name service agent to maintain and provide the most up-to-date host and port information to any AMEETZER when agent communication is required. Thus, a Registry is necessary. The Registry should also be responsible for registration and unregistration of an AMEETZER, to assign an available port number to an AMEETZER newly activated on a host and to be notified of a terminated AMEETZER respectively. We will discuss Registry's implementation in greater detail later.

Room Manager
This is an agent to manage the calendars of meeting places. The calendar of a meeting place will be treated uniformly as that of an attendee though specific constraints such as room size and location can be incorporated. Thus, this single agent provides centralized control over calendars of all possible meeting rooms as contrast to one AMEETZER per attendee. This conceptual framework can be generalized for any kind of Resource Manager.

Other Agents
Depending on the application domain, more service agents (e.g., Refreshment Catering Agent) can be added to the AMEETZER system to enrich the services provided by the whole system.

Micro-Archiecture
To further increase the concurrency of the system, we propose multiagent (or multi-subagent) architecture within each AMEETZER, as shown in Figure 3.

Each AMEETZER is decomposed into four subagents -- Receptionist, Scheduler, Messenger and Dispatcher. Personal user data comprise a Calendar to record scheduled meetings and a set of Preferences to capture user's constraints on meetings to be scheduled. The functions of the subagents are :
1. Receptionist - interacts with the user to manage his or her Calendar and Preferences, accepts his or her requests (e.g., call-for-meeting), presents scheduling results for confirmation and reminds him or her about forthcoming meetings.
2. Scheduler - implements the IROC scheduling protocol and the fuzzy constraint satisfaction framework.
3. Messenger - forwards outgoing messages to other AMEETZERs, using the name service of Registry when necessary.
4. Dispatcher - distributes incoming messages to the right subagent.

In implementation, an Ameetzer class (main program) contains the start-up and clean-up codes for AMEETZER (Listing 1). Upon activation by the user,

marten% java Ameetzer

where is the path where the configuration file resides, Ameetzer carries out the following initialization steps,

The four subagents inherit common variables and methods from the Subagent class (Listing 2). Each subagent (thread) executes in a perpetual loop to provide appropriate services based on the message retrieved from its own mailbox. Listing 3 shows skeletonal codes of the Dispatcher subagent.

Agent Communication
Recently, KQML [8] has gained popularity as an agent communication language without alternative with similar elaboration. We adopted a subset of KQML's performatives and adapted its communication format and content language for meeting scheduling domain and purpose. In AMEETZER, an Agent Communication Message, shown in Listing 4, has the following constituents :
1. Intention - agent's intention of sending the message. It implements the performatives in KQML. We feel that intention is a more appropriate term as an agent message only conveys a sender agent's intended request for the receiver agent which may or may not fulfil the request in general.
2. Sender - the agent (could be human agent) who sends the message.
3. Receivers - a list of agents to receive the message.
4. Content - message content, implemented as an array of Java Objects.

Subagents within an AMEETZER communicate with each other by message passing in mailboxes which support synchronization mechanism via semphores. The MessageQueue and Semaphore classes are given in Listings 5 and 6. The codes for the Queue object can be found in [7].

For communication among agents running on different hosts, a communication channel that encapsulates generic message sending and receiving behaviors built upon Java sockets and Java Object Serialization has been proposed [7]. Object serialization is necessary to support agent communication messages whose contents are of generic Object type. An item in the message content can range from a Date object (e.g. meeting date and time) to a multi-dimensional array of floating points (e.g. preference values).

To send a message to another AMEETZER, a Receptionist or Scheduler subagent sends a "forward" message to the Messenger subagent. Listing 7 shows an example where the Scheduler subagent of a meeting host's AMEETZER intends to retrieve the relevant parts of calendars from the attendee AMEETZERs.

The Messenger subagent will then "unwrap" this message when it is retrieved from its mailbox, look up the hostnames and port numbers of the respective recipient AMEETZERs and send out the message (i.e., fw_msg.content[0]) via the send() method of the Channel object [7] which receives incoming messages intended for the AMEETZER in Dispatcher subagent's mailbox (i.e., Dispatcher subagent's mailbox accepts external messages). The Messenger subagent may consult the Registry for the latest whereabouts of a recipient AMEETZER when necessary via another Channel object created by itself.

AMEETZER in action
We have tested AMEETZER's effectiveness under different scenarios. Scheduling a meeting that involves fourteen attendees (i.e., from call-for-meeting request to result reporting) requires not more than twenty seconds. Listing 7 depicts the text output of an operational AMEETZER and Figures 4-8 show some of the sample screen shots of AMEETZER during operation.

Registry
To track the whereabouts of AMEETZERs for peer-to-peer agent communications and to resolve communication port allocation conflict for AMEETZERs running on the same host, the Registry provides name service and registration function to the AMEETZERs using Channel object [7] via its well-known port (Listing 9).

When an AMEETZER comes alive, it needs to contact Registry to request a pair of port numbers (to be used by two Channel objects) for future agent communication (with other AMEETZERs) and name service (with Registry). However, to carry out this registration request an AMEETZER needs a prior communication port. This chicken-and-egg problem is resolved by using an initial well-known port (i.e. AMZ_INIT_PORT in Listing 9).

Upon receiving a "register" request from an AMEETZER, the Registry creates a new entry in its look-up tables (i.e., uid_host_map, ses_port_map) and replies with a pair of allocated port numbers if the requester is the only AMEETZER for its user. Otherwise, a sorry message will be replied, which will cause the AMEETZER to notify its user of pre-existing AMEETZER (at any time, only one AMEETZER is allowed per user). In the rare case of more than one AMEETZER attempting to register simultaneously, only the first AMEETZER will be granted and the rest will catch a Socket exception and request its user to start AMEETZER again later before exiting itself.

When the request is "unregister", the Registry simply removes the requester's entry in look-up tables and frees the port numbers held by it.

Last but not least, the Registry responds to an "ask-all" query request by looking up its tables and replying with a corresponding list of hostnames and port numbers for the given list of user names. Null values are replied for users who have no active AMEETZER running.

Conclusion and Future Outlook
In this article, we have described the design and implementation of a Java-based multi-agent meeting organizer, AMEETZER. We are collaborating with Tsukuba Research Center, RWCP, Japan to enhance AMEETZER's user interface with speech and gesture recognition technologies. Users will use voice and gestures to interact with their AMEETZER, which will respond with a synthesized voice which supplements the existing visual output. System integration can be achieved in a seemless and loose manner via socket communication. Briefly, the Channel object [7] in AMEETZER is modified to receive keywords produced after speech and gesture recognition and to send speech synthesized text to the new interface module (currently implemented in C).

We are also looking into transforming the standalone AMEETZERs for the World Wide Web platform. With Internet, we can extend the Registry to support inter-organization meetings and meetings among home users. A mobile computing and communication platform is another possible area for investigation.

References
1. Maes, P. (1994). "Agents that reduce work and information overload." Communications of the ACM, 37(7): 30-40, July 1994.
2. Ephrati, E., Zlotkin, G., & Rosenschein, J.S. (1994). "A non-manipulable meeting scheduling system." In Proc. of the 13th International DAI Workshop, Seattle, Washington, July 1994, pp. 105-125.
3. Yamaki, H., Kajihara, M., Nishimura, T., & Ishida, T. (1995). "Socia: an agent-based meeting support system." Technical Report ILTR-95-01. Dept. of Information Science, Kyoto University.
4. Sen, S. (1996). "An automated distributed meeting scheduler." To appear in IEEE Expert.
5. Lim, J.H. (1995). "Fuzzy constraint logic programming: a proposal." In Proc. of FUZZ-IEEE/IFES'95, Yokohama, Japan, Mar. 20-24, 1995, pp. 2305-2310.
6. Lim, J.H. (1991). "A constraint satisfaction neural network applied to timetable scheduling." In Proc. of Neuro-Nimes'91, Nimes, France, Nov. 4-8, 1991, pp. 761-764.
7. Lai, S.L. & Lim, J.H. (1996). "Channel: a communication component." Java Developer's Journal, Volume 1, Issue 3, December 1996, pp. 16-.
8. Finin, T. et al. (1993). Draft specification of the KQML agent communication language. http://www.cs.umbc.edu/kqml/.