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:
org.wamblee.photos.model: Containing the model interfacesorg.wamblee.photos.model.authorization: Containing a decorator for
the model that applies authorization rules. org.wamblee.photos.authorizationrules: Containing the authorization
rules for the photos application.
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:
PhotoAuthorizationRule: This rule grants access to photo albums belonging
to the groups that a user belongs to. For instance, if a user belongs to group 'XY' and
'YA', then that user has access to the albums 'XY' and 'YA'. This means that the root
album itself and these two entries may be accessed as well as all other entries below
these albums. PageAuthorizationRule: This rule is used for granting access to certain
pages to certain users. This rule is used implicitly when ProtectedPage checks access
to a page. It is relevant for the model.
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.
In addition to the basic operations on the model, some additional operations are defined to allow operations in the user interface for creating albums and uploading photos.
The scenario below explains what happens when a photo entry is obtained.
-