Table 20.4 Resource availability
memory; initially the availability of the resources is the same at every
The server preferences are recomputed periodically on the basis of avail-
ability, while the client preferences are defined in Table 20.3
Architecture and planning
The main constraint in the development of this application is provided by
the physical architecture, which is presented in Figure 20.1. The negotiation
takes place on the negotiation server that mediates between the student
preferences and the service provider's constraints. The service provider
component manages resource availability and constraints. Students access
the booking system through a standard web server.
The service provider and the student web server do not interact directly;
they go through the mediation agent that is in charge of guaranteeing fair-
ness. The connections between the nodes are normal network links, there-
fore the nodes can communicate using any protocol ranging from plain
sockets to rmi.
An important constraint in the development of this application is that the
goal is a reusable framework.
The system is partitioned into four components as shown in Figure 20.2.
Each component addresses specifically one or more essential features of the
system. The negotiation framework component handles the negotiation
problems. The resource booking component is a framework that works on
top of the negotiation framework and extends it to handle the problem of
Figure 20.1 Physical structure of the system