hazza/DSpace
1
0
Fork 0
mirror of https://github.com/DSpace/DSpace.git synced 2025-10-17 15:03:18 +00:00
Code Issues Packages Projects Releases Wiki Activity

Rename the html and pdf build script to be move obvious. Incorporate

Browse Source 
1.5.2 documentation notes from Graham Triggs, Mark Diggory, Larry 
Stone.  Regenerate the html and pdf.



git-svn-id: http://scm.dspace.org/svn/repo/branches/dspace-1_5_x@3679 9c30dcfa-912a-0410-8fc2-9e0234be79fd
This commit is contained in:
Brad McLean
2009-04-06 14:38:41 +00:00
parent 93abec17ef
commit ce7855934f
26 changed files with 1080 additions and 362 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
dspace/docs/html/ch08.html
View File

@@ -1,6 +1,6 @@
<html><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter&nbsp;8.&nbsp;DSpace System Documentation: Architecture</title><meta content="DocBook XSL Stylesheets V1.74.3" name="generator"><link rel="home" href="index.html" title="DSpace 1.5.2 Manual"><link rel="up" href="index.html" title="DSpace 1.5.2 Manual"><link rel="prev" href="ch07.html" title="Chapter&nbsp;7.&nbsp;DSpace System Documentation: Directories and Files"><link rel="next" href="ch09.html" title="Chapter&nbsp;9.&nbsp;DSpace System Documentation: Application Layer"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">Chapter&nbsp;8.&nbsp;DSpace System Documentation: Architecture</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="ch07.html">Prev</a>&nbsp;</td><th align="center" width="60%">&nbsp;</th><td align="right" width="20%">&nbsp;<a accesskey="n" href="ch09.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="N12E6E"></a>Chapter&nbsp;8.&nbsp;<a name="docbook-architecture.html"></a>DSpace System Documentation: Architecture</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="ch08.html#N12E74">8.1. Overview</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N12E74"></a>8.1.&nbsp;<a name="docbook-architecture.html-overview"></a>Overview</h2></div></div></div><p>The DSpace system is organized into three layers, each of which consists of a number of components.</p><p>
<html><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter&nbsp;8.&nbsp;DSpace System Documentation: Architecture</title><meta content="DocBook XSL Stylesheets V1.74.3" name="generator"><link rel="home" href="index.html" title="DSpace 1.5.2 Manual"><link rel="up" href="index.html" title="DSpace 1.5.2 Manual"><link rel="prev" href="ch07.html" title="Chapter&nbsp;7.&nbsp;DSpace System Documentation: Directories and Files"><link rel="next" href="ch09.html" title="Chapter&nbsp;9.&nbsp;DSpace System Documentation: Application Layer"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">Chapter&nbsp;8.&nbsp;DSpace System Documentation: Architecture</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="ch07.html">Prev</a>&nbsp;</td><th align="center" width="60%">&nbsp;</th><td align="right" width="20%">&nbsp;<a accesskey="n" href="ch09.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="N12F42"></a>Chapter&nbsp;8.&nbsp;<a name="docbook-architecture.html"></a>DSpace System Documentation: Architecture</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="ch08.html#N12F48">8.1. Overview</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N12F48"></a>8.1.&nbsp;<a name="docbook-architecture.html-overview"></a>Overview</h2></div></div></div><p>The DSpace system is organized into three layers, each of which consists of a number of components.</p><p>
<span class="inlinemediaobject"><img src="image/architecture-600x450.gif" width="585"></span>
</p><p>DSpace System Architecture</p><p>The storage layer is responsible for physical storage of metadata and content. The business logic layer deals with managing the content of the archive, users of the archive (e-people), authorization, and workflow. The application layer contains components that communicate with the world outside of the individual DSpace installation, for example the Web user interface and the <a class="ulink" href="http://www.openarchives.org/" target="_top">Open Archives Initiative</a> protocol for metadata harvesting service.</p><p>Each layer only invokes the layer below it; the application layer may not used the storage layer directly, for example. Each component in the storage and business logic layers has a defined public API. The union of the APIs of those components are referred to as the Storage API (in the case of the storage layer) and the DSpace Public API (in the case of the business logic layer). These APIs are in-process Java classes, objects and methods.</p><p>It is important to note that each layer is <span class="emphasis"><em>trusted</em></span>. Although the logic for <span class="emphasis"><em>authorising actions</em></span> is in the business logic layer, the system relies on individual applications in the application layer to correctly and securely <span class="emphasis"><em>authenticate</em></span> e-people. If a 'hostile' or insecure application were allowed to invoke the Public API directly, it could very easily perform actions as any e-person in the system.</p><p>The reason for this design choice is that authentication methods will vary widely between different applications, so it makes sense to leave the logic and responsibility for that in these applications.</p><p>The source code is organized to cohere very strictly to this three-layer architecture. Also, only methods in a component's public API are given the <code class="literal">public</code> access level. This means that the Java compiler helps ensure that the source code conforms to the architecture.</p><div class="table"><a name="N12EA4"></a><p class="title"><b>Table&nbsp;8.1.&nbsp;Source Code Packages</b></p><div class="table-contents"><table summary="Source Code Packages" border="0"><colgroup><col><col></colgroup><tbody><tr><td>
</p><p>DSpace System Architecture</p><p>The storage layer is responsible for physical storage of metadata and content. The business logic layer deals with managing the content of the archive, users of the archive (e-people), authorization, and workflow. The application layer contains components that communicate with the world outside of the individual DSpace installation, for example the Web user interface and the <a class="ulink" href="http://www.openarchives.org/" target="_top">Open Archives Initiative</a> protocol for metadata harvesting service.</p><p>Each layer only invokes the layer below it; the application layer may not used the storage layer directly, for example. Each component in the storage and business logic layers has a defined public API. The union of the APIs of those components are referred to as the Storage API (in the case of the storage layer) and the DSpace Public API (in the case of the business logic layer). These APIs are in-process Java classes, objects and methods.</p><p>It is important to note that each layer is <span class="emphasis"><em>trusted</em></span>. Although the logic for <span class="emphasis"><em>authorising actions</em></span> is in the business logic layer, the system relies on individual applications in the application layer to correctly and securely <span class="emphasis"><em>authenticate</em></span> e-people. If a 'hostile' or insecure application were allowed to invoke the Public API directly, it could very easily perform actions as any e-person in the system.</p><p>The reason for this design choice is that authentication methods will vary widely between different applications, so it makes sense to leave the logic and responsibility for that in these applications.</p><p>The source code is organized to cohere very strictly to this three-layer architecture. Also, only methods in a component's public API are given the <code class="literal">public</code> access level. This means that the Java compiler helps ensure that the source code conforms to the architecture.</p><div class="table"><a name="N12F78"></a><p class="title"><b>Table&nbsp;8.1.&nbsp;Source Code Packages</b></p><div class="table-contents"><table summary="Source Code Packages" border="0"><colgroup><col><col></colgroup><tbody><tr><td>
<p>
<span class="bold"><strong>Packages within</strong></span>
</p>
@@ -56,7 +56,7 @@ mvn javadoc:javadoc
</p></li><li><p>
<a class="link" href="ch10.html#docbook-business.html-browse">Browse API</a>
</p></li><li><p>
<a class="link" href="ch10.html#docbook-business.html-history">History Recorder</a>
<a class="link" href="">History Recorder</a>
</p></li><li><p>
<a class="link" href="ch10.html#docbook-business.html-checker">Checksum Checker</a>
</p></li></ul></div>