<?xml version="1.0"?>
<!--
  Copyright 2002-2004 The Apache Software Foundation or its licensors,
  as applicable.
  
  Licensed under the Apache License, Version 2.0 (the "License");
  you may not use this file except in compliance with the License.
  You may obtain a copy of the License at
  
  http://www.apache.org/licenses/LICENSE-2.0
  
  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.
-->
<document xmlns="http://maven.apache.org/XDOC/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/XDOC/2.0 http://maven.apache.org/xsd/xdoc-2.0.xsd">
  <properties>
    <title>design</title>
  </properties>
  <body>
    <section name="Table of contents">
      <macro name="toc">
        <param name="section" value="0"/>
        <param name="fromDepth" value="0"/>
        <param name="toDepth" value="4"/>
      </macro>
    </section>
    <section name="Structure of the documentation">
      <p>
        Design documentation is provided to illustrate different aspects of the 
        software. Each design document has the following structure:
      </p>
      <ul>
        <li><strong>Introduction</strong>: A short introduction into the 
          functionality and why it is necessary </li>
        <li><strong>Requirements</strong>: Outlining the basic requirements</li>
        <li><strong>Design</strong>: Describing the overall solution principle and basic ideas
          without mentioning classes, only the functional solution. </li>
        <li><strong>Structure</strong>: Describes relevant class diagrams. </li>
        <li><strong>Dynamics</strong>: Describes the most important scenarios to illustrate the
          dynamic behavior of the system. </li>
        <li><strong>Design Rules</strong>: Describes the main attention points
          when using the described designs, something like the highlights of
          the user manual of the design </li>
      </ul>
    </section>
    <section name="Available Documentation">
      <p>The following design documentation is available:</p>
      <ul>
        <li>Framework documentation: Documentation of the generic frameworks used.</li>
        <li>Application documentation: General design of the application itself and a description of
          how the frameworks were used. </li>
      </ul>
      <subsection name="Framework Documentation">
        <ul>
          <li>
            <p><strong><a href="caching/caching.html">Caching</a></strong>: Explains the caching 
            support utilities used for application-level caching. </p>
          </li>
          <li>
            <p><strong><a href="persistence/persistence.html">Persistence</a></strong>:
            Explains the persistence support utilities to make Hibernate persistence 
            easier to use. </p>
          </li>
          <li>
            <p><strong><a href="concurrency/concurrency.html">Concurrency</a></strong>: 
            Explains concurrency support. </p>
          </li>
          <li>
            <p><strong><a href="security/security.html">Security</a></strong>: Explains the security
            requirements and how they are realized. </p>
          </li>
          <li>
            <p><strong><a href="usermgt/usermgt.html">User Management</a></strong>: Explains user management
            design.</p>
          </li>
        </ul>
      </subsection>
      <subsection name="Application Documentation">
        <ul>
          <li>
            <p><strong><a href="photos/model.html">Model</a></strong>: The model used for the
              application and how authorization is used for it. </p>
          </li>
        </ul>
      </subsection>
    </section>
    <section name="Architectural Roadmap">
      <ul>
        <li>Use of a generic authorization mechanism to restrict access to photo albums based on user identity.</li>
        <li>The current implementation of the photo albums is done directly on a file system. 
          This will move to an implementation where the albums are maintained in a database
          together with metadata for the photos and albums. The current implementation will just
          become a storage bin for photos. This is because it is convenient to have direct 
          access to photos and because storing photos as big binary objects in a database is
          generally not that efficient. </li>
        <li>Concurrency for photo albums is implemented using standard JVM locking. Concurrency
          will also be delegated to the database to make it ready for clustered environments. </li>
        <li>
          Use of a workflow engine. This is required for screen navigation (Tapestry does not really
          provide anything, although Struts like navigation can be done in Tapestry) and for other 
          tasks such as online registration. 
        </li>
        <li>More strict separation of presentation and business tier. Currently, the photo album 
          API is used directly in the presentation layer and this can encourage the implementation
          of 'business functionality' in the presentation tier, which is not desired. </li>
      </ul>
    </section>
  </body>
</document>
