PhotoXChange -
design model
This document explains the model used in the photos application as well as its implementation and several non-functional aspects.
The model is the central part of the photos application because it provides the interface for dealing with photo albums inside the application. This version of the documentation is very high level. It will be extended in the future as more work is done on the model. In particular, file system based storage and concurrency support also exist but are not discussed in this document. This is because storage and concurrency will be handled differently in the future. The current document focuses exclusively on the photo model and on authorization.
The model is a basic example of the composite pattern and allows arbitrarily deep nesting of photo albums. Authorization is implemented as a decorator which filters the list of photo entries for an album based on authorization rules using the AuthorizationService.
The general design filosophy of the model is based on the factory method and decorator design patterns. The model is cleanly separated into:
The relevant packages for the model are:
Note that the authorization rules are not used directly by the authorization package. This is because the AuthorizationService is used and the rules are configured in the authorization service and never accessed directly by the model.
The model is a standard example of the Composite pattern. The general abstraction is that of a photo entry which can be either a photo or a photo album. The model provides a basic API for manipulating photos and iterating through the photo album. In addition, the Path utility class is used for manipulating paths.
To implement authorization for the photos application, two rules are provided:
Authorization is implemented as a decorator of the model. One common base class AuthorizedPhotoEntry stores a reference to the decorated object. Authorization is done in the AuthorizedAlbum class which computes a list of authorized entries to which a user may have access using the AuthorizationService.
The list of authorized photo entries is cached using CachedObject (not shown in the figure). If an appropriate cache is used, then at certain time, this list will expire and the CachedObject will call a computation callback on the AuthorizedAlbum to recompute the list of authorized entries. To create a unique id for the cached photo entry an id must be used as key for the cache which is guaranteed to uniquely identify a session.
The caching approach ensures efficiency because the authorization rules are checked less frequently, and because the authorized photo entries are not cached indefinitely. Note that for this approach to work, the authorized album should be specific to a specific user, which means it is best stored in session scope in the web tier.
