**Architectural Review Checklist**

Protégé GUI NCIEditTab Plug-In

Collaborative Development Tools

Version 1.0

Revision Document History

  ---------- --------- ---------------------------------- ---------------------
  Date       Version   Description                        Author

  08/30/07   1.0       First draft                        Gilberto Fragoso, Bob
                                                          Dionne

                                                          

                                                          
  ---------- --------- ---------------------------------- ---------------------

Table of Contents

1\. Introduction 6

Purpose 6

Guidelines for Completing the ARC 6

2\. Project Details (To be answered by development team) 6

General Information 6

Project Description 6

Contact Information 6

Major Deployment Milestones 6

Architectural Details 7

High level architectural description: 7

High Level Design Diagram (If available): 7

Implementation language(s) used? 7

Will connections/requests to the application be session based (i.e.
statefull versus stateless)? If so, is there any reason why application
would not support "sticky session" load balancing? 7

Will the application be caching data? If so, what is being cached and
how much data will be cached? 7

What data files will be created (if any)? How much data will be saved on
an on going basis? 7

Will this application need a database schema(s) created on the NCICB
infrastructure? If so, what is the maximum number of objects to be
stored? 7

Are there any external/non-NCICB data sources that will be accessed by
the application? 7

If this is a web-based application, what are the preferred virtual hosts
names to be registered? 7

Any additional architectural details that may be of significance to the
needed deployment environment. 7

Performance Requirements 8

Total number of users for this application? 8

Peak number of concurrent users? 8

Peak number of requests/minute? 8

Up time requirements? 8

Acceptable down time when recovering from major systems disaster? 8

NCICB Project Dependencies 8

Configuration Management Details 8

Version Control 8

Change Control 8

Migration to CVS 8

Users 8

Build Process 8

Other CM Needs 8

Additional Notes 8

3\. System Requirements (To be answered by both development & systems
team) 9

Operating System 9

\<\<Solaris/LINUX/Windows 2000/...\>\> 9

Software (Technology Stack) 9

Web Server: \<\<Apache/Tomcat/ZOPE/...\>\> 9

App Server: \<\<Tomcat/JBoss/Oracle 9iAS/...\>\> 9

Database Server: \<\<Oracle/MySQL/PostgreSQL/...\>\> 9

Other software components: \<\<PERL x.x, Python x.x, ...\>\> 9

Server Hardware 9

Server: \<\<type, model, ...\>\> 9

Minimum processor speed: 9

Minimum memory: 9

Minimum local drive space: 9

Storage 9

Expected file server disk storage (in MB): 9

Expected database storage (in MB): 9

Expected ftp storage (in MB): 9

Expected media/image storage (in MB): 9

Load Balancing/Fault Tolerance 9

Does the application support load balancing? 9

Implement load balancing -- YES/NO 9

Networking 9

Any application specific port assignments? 9

Any additional configuration? 9

Additional Notes 9

4\. Proposed NCICB Deployment Environment (To be answered by systems
team) 9

Hardware 9

Technology Stack 10

File Server 10

Database 10

Networking 10

Other Resources 10

5\. Impact Assessment (To be answered by systems team) 10

Overview 10

Cost 10

Timeline to implement 10

Additional Notes 10

6\. Acceptance 10

7\. Appendix 1 - Future Systems Requirements 11

New Architecture Diagram 11

Notes on the design change 11

Hardware 11

Servers 11

Processor speed 11

Memory 11

Drive Space 11

Software (Technology Stack) 11

Web Server 11

App Server 11

Other components 11

Fault Tolerance (Redundancy) 11

Does the application support load balancing? 11

Implement load balancing -- YES/NO 11

Load balancing requirements 11

Fault tolerance solution suggested 11

Additional requirements (if any) 11

Performance Enhancements 11

Processing Power 11

Memory 11

I/O 11

Other needs 11

# Introduction

## Purpose

The purpose of the Architectural Review Checklist (ARC) is to help
identify the deployment environment (both hardware and software
components) necessary for an application to execute optimally within the
NCICB IT infrastructure. The ARC is considered to be a dynamic artifact
for any NCICB project and should be maintained in the configuration
library (i.e. CVS) for each project. For new projects, this document
template will be automatically checked into the projects repository by
the SCM team upon project initiation. The ARC should be reviewed on at
least a quarterly basis to capture any application design changes that
may effect the deployment environment necessary for optimal performance.

## Guidelines for Completing the ARC

The ARC is divided into 4 main sections. The first section (Project
Details) is meant to capture general information about the project. The
project development team should fill out the Project Details section and
return it to the systems team. The second section (Systems Requirements)
is meant to capture details of specific system requirements for the
project. Both the development and system teams will preferably answer
the Systems Requirement section jointly. However, depending on the
development teams familiarity with the NCICB infrastructure, they may
choose to answer either all or parts of this section on their own. The
third section (Planned Deployment Environment) specifies the proposed
deployment environment for the application and is to be answered by the
systems team based on the response to section 1 & 2. Finally, the last
section (Impact Assessment) describes the impact (additional
hardware/software costs, staffing resources...) to the existing NCICB IT
infrastructure in order to support this application. Upon completion of
the Deployment Environment and Impact Assessment sections, the systems
team will return the ARC to the development team for final review and
comments.

# Project Details *(To be answered by development team)*

## General Information

### Project Description

The Protégé software is a vocabulary development tool, with a plugin
architecture supporting third party add-ons. The NCIEditTab is a plugin
developed by the NCICB EVS group for the Protégé environment.

### Contact Information

  ---------------- ---------------------- --------------- ----------------
  **Title**        **Name**               **Phone**       **Email**

  Project Manager  Sherri de Coronado,                    
                   Gilberto Fragoso                       

  Team             Bob Dionne                             
  Lead/Architect                                          

  SCM Coordinator                                         
  ---------------- ---------------------- --------------- ----------------

### Major Deployment Milestones

+-----------------------------------+----------------------------------+
| **Milestone**                     | **Date**                         |
+-----------------------------------+----------------------------------+
| Planned Release to QA             | 1.1 in QA August 2007            |
+-----------------------------------+----------------------------------+
| Planned Release to Staging        | 1.1 in Stg September 2007        |
+-----------------------------------+----------------------------------+
| Planned Release to Production     | Protégé 1.1 in production        |
|                                   | mid-September 2007               |
|                                   |                                  |
|                                   | (Protégé 1.0 in production since |
|                                   | June 2007)                       |
+-----------------------------------+----------------------------------+

## Architectural Details

### High level architectural description:

Desktop application running in client-server mode with a database
backend. On the server side, a) the Protégé server provides the main
support for editing, b) data persisted in a mysql database.

Other services are not yet integrated with the Protégé server and run
standalone instead. In addition to the Protégé server, the NCIEditTab
plugin to the Protégé client connects to a classifier (pellet), a code
generator, and an explanation server.

### High Level Design Diagram (If available):

### Implementation language(s) used?

Java.

### Will connections/requests to the application be session based (i.e. statefull versus stateless)? If so, is there any reason why application would not support "sticky session" load balancing?

There is state maintained on the server side. In any case, this
application will not require load balancing as it's an editing tool and
high-throughput is not essential.

### Will the application be caching data? If so, what is being cached and how much data will be cached?

The protégé server caches several items. At startup it will cache
user-configured taxonomic hierarchies to speed up navigation, it also
pre-computes possible requests based on nodes visited and populates a
frame cache.

### What data files will be created (if any)? How much data will be saved on an on going basis?

Lucene indices, updated on each individual editing action.

Database exports to file every 2 weeks. Database exports would be
processed and published to FTP, the LexBig terminology server (in
production for caCORE 4), and the Semantic Media Wiki (under
development).

Classification reports periodically (\~ twice a week), baseline diffs
periodically (\~ weekly).

### Will this application need a database schema(s) created on the NCICB infrastructure? If so, what is the maximum number of objects to be stored?

The mySql database is currently in the same box as the Protégé server.
The Protégé tool creates the database schema. Eventually, when
performance considerations are less of a concern, the database can be
migrated to the common NCICB infrastructure.

### Are there any external/non-NCICB data sources that will be accessed by the application?

Not dependent on external data sources.

The NCIEditTab plugin is dependent on the open source Protégé software.

### If this is a web-based application, what are the preferred virtual hosts names to be registered?

This is not a web-based application.

### Any additional architectural details that may be of significance to the needed deployment environment.

## Performance Requirements

### Total number of users for this application? 10

### Peak number of concurrent users? 10

### Peak number of requests/minute? -

### Up time requirements? Business hours

### Acceptable down time when recovering from major systems disaster? 48 hours (might change)

## NCICB Project Dependencies

Collaborative environment involving the Semantic Media Wiki (under
development)

Classification project (incremental classifier)

## Configuration Management Details

Briefly describe your current configuration management practices here.

### Version Control

Gforge SVN is currently being utilized in this project. Some modules are
in the NCICB CVS repository and will be moved to the same Gforge SVN as
the NCIEditTab.

### Change Control

What are your current change control practices? What procedures are in
place to determine whether to implement a change request?

The software is being developed and deployed following NCICB practices.
Requests for enhancements are being incorporated into development cycles
and deployed as part of major/minor releases.

### Migration to CVS

Indicate whether you will require SCM support migrating your source code
to the NCICB CVS repository.

N.A.

### Users

Provide a list of all developers who require access to your repository
modules.

Bob Dionne, Tim Redmond, Tania Tudorache, Chris Callendar, Kim Ong, Mike
Smith, Evren Sirin, Steve Hunter, Tracy Safran, John Parks, Gilberto
Fragoso

### Build Process

Describe your build process here. For example, are you using Ant, Make,
or something else?

We are using Ant to build server, client, and admin packages from the
SVN and CVS sources.

### Other CM Needs

Describe any other CM needs?

## Additional Notes

# System Requirements *(To be answered by both development & systems team)*

## Operating System

### Linux, 64 bit  {#linux-64-bit .unnumbered}

## Software (Technology Stack)

### Web Server: 

### App Server: 

### Database Server: mySQL 5

### Other software components: java 1.5, javacc, gcc 3.4.4+, Xerces cpp libraries (for FaCT++)

## Server Hardware

### Server: DL 585 (Prod), DL385 (QA, DEV, STG) 

### Minimum processor speed:

### Minimum memory: 32 GB (Prod), 16 GB (QA), 4 GB (DEV, STG)

### Minimum local drive space: 150 GB

## Storage

### Expected file server disk storage (in MB): -

### Expected database storage (in MB): 10 GB

### Expected ftp storage (in MB): -

### Expected media/image storage (in MB): -

## Load Balancing/Fault Tolerance 

### Does the application support load balancing? No

### Implement load balancing -- YES/NO

## Networking

### Any application specific port assignments? Yes

### Any additional configuration? Blank for now

## Additional Notes

# Proposed NCICB Deployment Environment *(To be answered by systems team)*

## Hardware

Currently we have production hardware, cbiows501. We need Dev, QA, and
Stg with lower CPU & memory requirements, can be virtual environments.

## Technology Stack

*\<\<specific technology stack to be used\>\>*

## File Server

*\<\<space allocation on big IP, NFS mount points, initial size
allocation...\>\>*

## Database

MySQL running in cbiows501

## Networking

None of the tiers needs to be accessible through the firewall. A remote
possibility exists for the production tier, but it would be in the
distant future ( \>12 months)*.*

## Other Resources

*\<\<e.g. ftp server access, media server access, ...\>\>*

# Impact Assessment *(To be answered by systems team)*

## Overview

## Cost 

## Timeline to implement

## Additional Notes

# Acceptance

  ----------------------------------- -----------------------------------
  Project Lead ( )                    Project Coordinator -- NCICB ( )

  Systems Team                        SCM Administrator
  ----------------------------------- -----------------------------------

#  {#section .unnumbered}

# Appendix 1 - Future Systems Requirements

In this section, describe any projected future anticipated requirements
for your system.

## New Architecture Diagram

## Notes on the design change

## Hardware

### Servers

### Processor speed

### Memory

### Drive Space

## Software (Technology Stack)

### Web Server

### App Server

### Other components

## Fault Tolerance (Redundancy)

### Does the application support load balancing?

### Implement load balancing -- YES/NO

### Load balancing requirements

### Fault tolerance solution suggested

### Additional requirements (if any)

## Performance Enhancements

### Processing Power

### Memory

### I/O

### Other needs