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.

It shall be possible to represent albums of containing entries where each entry can be a photo or and album (recursive).
It shall be possible to restrict access to photo albums based on authorization rules.

The overhead of evaluating authorization rules shall be negligible.

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:

Interface definitions: used by clients of the model. A client never needs to know the concrete type of an album of photo because the correct objects will be created by the implementations.
Storage based implementation: One or more implementations that store the model in some way (e.g. file system, database, in memory).
Decorators for implementing other concerns such as security/authorization and concurrency.

The relevant packages for the model are:

org.wamblee.photos.model: Containing the model interfaces
org.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.