UCL ISD

High Level Design Document

Status: issued by Design Authority

Author: Simon Farrell
Version: 1.0
Date: 15th March 2010

Contents
Contents................................................................................................................ 2
Introduction........................................................................................................... 3
Purpose................................................................................................................................... 3
Scope...................................................................................................................................... 3
Audience................................................................................................................................. 3
Document Organisation.......................................................................................................... 3
Contacts.................................................................................................................................. 4
Design Overview....................................................................................................4
Goals....................................................................................................................................... 4
Constraints.............................................................................................................................. 4
Assumptions............................................................................................................................ 4
Principles................................................................................................................................. 4
System Architecture..............................................................................................4
Hardware Architecture............................................................................................................ 4
Topology Diagram................................................................................................................ 4
Network Considerations....................................................................................................... 5
Storage Considerations........................................................................................................ 5
Software Architecture............................................................................................................. 5
O/S & supporting software diagrams...................................................................................5
New and existing software components...............................................................................6
Application Architecture........................................................................................6
Design Patterns....................................................................................................................... 6
User Interface.......................................................................................................................... 6
Integration infrastructure........................................................................................................ 6
Application Logic..................................................................................................................... 7
Database & File Architecture.................................................................................7
Logical data model.................................................................................................................. 7
Filestores................................................................................................................................. 7
External Interfaces................................................................................................7
Inbound................................................................................................................................... 7
Outbound................................................................................................................................ 7
Security................................................................................................................. 7
Authentication & Authorisation...............................................................................................7
Special security concerns........................................................................................................8
Appendix A: Glossary.............................................................................................8
Appendix B: Products & Tools................................................................................8

Introduction
Purpose
The purpose of this document is to outline the technical design of XXX and provide input to its
detailed design.
Its main purpose is to

Permit review and approval by the UCL Design Authority pre- or post-approval of the
Project Initiation Document (PID)

Detail the functionality which will be provided by each system component or group of
components and show how the various components interact in the design

Provide a basis for detailed design and development

This document is not intended to address installation and configuration details of the actual
implementation. Installation and configuration details should be provided in technology
guides and handover documents produced during the course of project.
As is true with any high level design, this document will be updated and refined based on
changing requirements.

Scope
The design outlined in this document builds upon the scope defined in the PID and/or Project
Startup phase.

Audience
The intended audiences for this document are the UCL Design Authority, project stakeholders,
the project development teams, technical designers, database designers, testers and
vendors.

Document Organisation
This document contains the following sections:
Section
Design Overview
System Architecture
Application Architecture
Database & File Architecture
External Interfaces
Security

Glossary
Products & Tools

Explanation
Describes the goals, constraints, assumptions and principles
that affect the system.
Describes the various system hardware, software, network
and storage components of the system, and shows how they
link together
Describes the new software components that the system will
provide
Describes the design of the underlying data repositories and
the relationship between these and existing repositories
Describes how this system will exchange data with other
applications
Describes the security components of the system including
how access will be authorised and whether any specific
measures (e.g. penetration testing) need to be undertaken
during development and test.
Describes acronyms, abbreviations, terms and definitions
Lists all products and tools used in development, test and
production

Contacts
Questions and suggestions about the format of this document should be directed to:Questions about the content of this document should be directed to:-

Design Overview
Goals
<Example>: The overall goal of this system is to provide a highly available and easy to use
system that allows UCL researchers to see a consolidated view of all information about their
research activities and to enrich this information. A secondary goal is to provide a flexible and
performant reporting system for the VP of Research.

Constraints
<Example>: The system must re-use the existing Ubuntu server and Oracle database
platforms. It must be usable in all modern browsers. It must be restricted to UCL staff users
only.

Assumptions
<Example>: Sufficient server, network and database capacity exist for the system as
designed.
<Example>: Testing & operational support resources will be available to consult during
detailed design.

Principles
<Example>: Design of the system will confirm to UCLs IT Standards (insert URL). Where no
UCL standard applies, the project will select industry standards with a > 5 year predicted
lifespan.
<Example>: The system will be built to scale both horizontally(by adding more servers) and
vertically (by adding more disk space and processing power). To support flexibility, it will be
designed and built in a modular way to minimise coupling and isolate complexity. To permit
future integration with new technologies, the user interface will be decoupled from the
business logic and the business logic will be decoupled from the database.

System Architecture
Hardware Architecture
Topology Diagram
<Example>:

Public
Internet
HTTPS

UCL Network

Tomcat API Server (Location

TBD)

HTTPS
Public Apache Servers
Shibboleth
Authentication
www-a www-b

HTTP/XML APIs

UCL Firewalls

Java
File storage (photos)

???

Web Proxy

LAN TBD
New DB
(Location
TBD)

LAN TBD
Wolfson House Datacentre

LAN TBD
Database Server

HTTP
Internal Apache Server
PHP Application

msdp01

GEN
msdora01

PHP libraries:
Oracle, Smarty,
Zend framework

SITS

FIS

HR

Network Considerations
<Example>: The application expects to support ~ 100 concurrent users, each accessing ~
5Mb of information per web page refresh (mainly search results).
<Example>: The database will rely on materialised view technology to copy changed data
from the back end databases to the new database. Materialised view rebuilds may result in
nightly bulk copying of ~ 2Gb of data into the new database.
Storage Considerations
<Example>: The new database requires ~ 20Gb of data and index space.

Software Architecture
O/S & supporting software diagrams
App server
From proxy

Public web server

From user

Apache

mod_php

mod_shib

Zend
libraries

Smarty
libraries

Oracle
connector

Apache

mod_proxy

To app server

AJAX/JSON API
HTTPS GET/
POST

Application
code

Oracle database
connection

<Example>: Web application servers

Existing Oracle Database

App
server

Existing
component

New schema

Existing
schema

New tables

MV Logs

New
component

Materialised
Views

<example>: Database server components

Web browser
Jquery Javascript

AJAX to web
server
HTTPS to
web server

HTML pages

<Example>: User interface components

New and existing software components
<Example>: See diagrams in the preceding section. All non-read database access will be
mediated by PL/SQL stored procedures. In addition, a number of additional PL/SQL stored
procedures will be created to perform periodic maintenance, and at least one shell script will
be required to manage export of store photographs on a nightly basis.

Application Architecture
Design Patterns
<Example>: The web application will employ the industry standard Model-View-Controller
pattern, modified slightly by performing some data validation in the browser, using Javascript
<Example>: The application will also make use of the Factory pattern to decouple itself from
the details of database connections.

User Interface
<Example>: The user interface will be written in HTML, dynamically generated by the PHP
application and constructed via Smarty templates. JQuery will be used to enhance the UI and
manage AJAX requests to the server.

Integration infrastructure
<Example>: The API server will expose the following functionality using Spring Web Services:
-

Read-only query for people matching particular criteria (e.g. staff/student, job title,
department)

Per-person create/update/delete of URL references to associated files held in EDRM

<Example>: The application will make use of the existing Oracle SOA Suite ESB to subscribe
to EDRM document creation and modification events, which will result in the above APIs being
called. See Appendix Z for a high level design description of this component.

Application Logic
<Example>: Application logic will be written in PHP, Java and PL/SQL. Business logic will be
written as PHP classes, separated from UI and API logic. PL/SQL will be used to encapsulate,
authorise and validate changes to data.

Database & File Architecture

Logical data model
<Insert BPA export>

Filestores
<Example>: The application will make use of space on the Institutional File Store, mounted
via NFS, to store photographs. The application will store up to 20,000 photographs of about
1Mb each, in a directory structure similar to this:
Directory
<app root>
<uploads>
<photos>

Comments
World readable
World writeable, app readable
World readable, app writeable

External Interfaces
Inbound
<Example>: The application will expose SOAP APIs to properly authenticated UCL clients. It
will also import nightly a copy of the UPI CSO.DAT file, to refresh staff and student
information.
<Example>: When an API is called, the ESB will be responsible for checking authenticity of
the client and enriching the payload with the callers Department name.

Outbound
<Example>: Once every 24 hours, the application will export, zip and email a copy of all new
photographs to the UK Borders Agency (UKBA).

Security
Authentication & Authorisation
<Example>: Web application authentication will be via Shibboleth on the public-facing web
servers. Shibboleth is will be configured to provide the following attributes to the application:
-

Username

UPI

Email address

Staff/student group membership

Department name

<Example>: All API calls must provide the UPI of the original caller and must originate only
from trusted endpoints.
<Example>: Roles will be created in the Oracle database and mapped to the Department of
the end user to isolate data between departments.

Special security concerns

<Example>: Because data is exported to the UKBA on a nightly schedule, an audit trail of all
photograph uploads and modifications will be essential , including:
-

IP Address of the client that uploaded the file

Username of the user that uploaded the file

Appendix A: Glossary
Appendix B: Products & Tools