Resource allocation systems

Resource allocation systems are a type of information system that have the same four-layer generic structure discussed in Chapter 6. Resource allocation systems manage a fixed amount of some given resource, such as tickets for a concert or a football game, that must be allocated to users who request that resource from the supplier. Ticketing systems are an obvious example of a resource allocation system, but a large number of apparently dissimilar programs are also actually resource allocation systems. Some examples of this class of system are:

1. Timetabling systems that allocate classes to timetable slots. The resource being allocated here is a time period and there are usually a large number of constraints associated with each demand for the resource.
2. Library systems that manage the lending and withdrawal of books or other items. In this case, the resources being allocated are the items that may be borrowed. In this type of system, the resources are not simply allocated but must sometimes be deallocated from the user of the resource.
3. Air traffic management systems where the resource that is being allocated is a segment of airspace so that separation is maintained between the planes that are being managed by the system. Again, this involves dynamic allocation and reallocation of resource, but the resource is a virtual rather than a physical resource.

Figure 1. A layered model of a resource allocation system

            Resource allocation systems are a very widely used class of application. If we look at their architecture in detail, we can see how it is aligned with the information system model shown in Figure 6.X. The components of a resource allocation system (shown in Figure 1) include:

1. A resource database that holds details of the resources being allocated. Resources may be added or removed from this database. For example, in a library system, the resource database includes details of all items that may be borrowed by users of the library. Normally, this is implemented using a database management system that includes a transaction processing system. The database management system also includes resource-locking facilities so that the same resource cannot be allocated to users who make simultaneous requests.
2. A rule set that describes the rules of resource allocation. For example, a library system normally limits who may be allocated a resource (registered library users), the length of time that a book or other item may be borrowed, the maximum number of books that may be borrowed and so on. This is encapsulated in the resource policy control component.
3. A resource management component that allows the provider of the resources to add, edit or delete resources from the system.
4. A resource allocation component that updates the resource database when resources are assigned and that associates these resources with details of the resource requestor.
5. A user authentication module that allows the system to check that resources are being allocated to an accredited user. In a library system this might be a machine-readable library card; in a ticket allocation system it could be a credit card that verifies the user is able to pay for the resource.
6. A query management module that allows users to discover what resources are available. In a library system, this would typically be based around queries for particular items; in a ticketing system, it could involve a graphical display showing what tickets are available for particular dates.
7. A resource delivery component that prepares the resources for delivery to the requestor. In a ticketing system, this might involve preparing an e-mail confirmation and sending a request to a ticket printer to print the tickets and the details of where these should be posted
8. A user interface component (often a web browser) that is outside the system and allows the requester of the resource to issue queries and requests for the resource to be allocated.

This layered architecture can be realised in several ways. Information systems software can be organised so that each layer is a large-scale component running on a separate server. Each layer defines its external interfaces and all communication takes place through these interfaces. Alternatively, if the entire information system executes on a single computer, then the middle layers are usually implemented as a single program that communicates with the database through its API. A third alternative is to implement finer-grain components as separate web services (discussed in Chapter 19) and compose these dynamically according to the user’s requests.