NCIt Browser (Term Browser) · Web viewEVS NCIt Browser (Term Browser) 2.0 08/19/10 Revision...

NCI Center for Bioinformatics

Architectural Review Checklist

EVSNCIt Browser (Term Browser) 2.0

08/19/10

Architectural Review Checklist Version: 2.0 Date: 08/19/10

Revision Document HistoryDate Version Description Author01/14/09 1.0 First draft NCICB Dedicated Support02/23/10 1.1 Revised for Term Browser as follows:

- Local (file system) LexEVS 5.1 is required.- Load balancing is required.- Cache file is required.

NCICB Dedicated Support

04/07/10 1.2 - Release number updated NCICB Dedicated Support08/18/10 2.0 Revised for Term Browser as follows:

- Change to LexEVS 6.0 .- Change to JBoss 5.1 from JBoss 4.0.5- Upgrade to BDA 1.7.2 scripts

NCICB Dedicated Support

Confidential


Table of Contents1. Introduction 6

1.1 Purpose 61.2 Guidelines for Completing the ARC 6

2. Project Details (To be answered by development team) 62.1 General Information 62.1.1 Project Description 62.1.2 Major Deployment Milestones 72.2 Architectural Details 72.2.1 High level architectural description: 72.2.2 High Level Design Diagram (If available): 82.2.3 Implementation language(s) used? 82.2.4 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? 82.2.5 Will the application be caching data? If so, what is being cached and how much data will be cached? 82.2.6 What data files will be created (if any)? How much data will be saved on an on going basis?

92.2.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? 92.2.8 Are there any external/non-NCICB data sources that will be accessed by the application? 92.2.9 If this is a web-based application, what are the preferred virtual hosts names to be registered? 92.2.10 Any additional architectural details that may be of significance to the needed deployment environment. 92.3 Performance Requirements 92.3.1 Total number of users for this application? 92.3.2 Peak number of concurrent users? 92.3.3 Peak number of requests/minute? 92.3.4 Up time requirements? 10Standard for NCICB. (24 hours/day, 7 days/week) 102.3.5 Acceptable down time when recovering from major systems disaster? 10Standard for NCICB (24 – 48 hours) 102.4 NCICB Project Dependencies 102.5 Configuration Management Details 102.5.1 Version Control 102.5.2 Change Control 102.5.3 Migration to CVS 102.5.4 Users 102.5.5 Build Process 112.5.6 Other CM Needs 112.6 Additional Notes 11

3. System Requirements (To be answered by both development & systems team) 113.1 Operating System 113.2 Software (Technology Stack) 113.2.1 Web Server: 113.2.2 App Server: 113.2.3 Database Server: 113.2.4 Other software components: 11

Confidential


3.3 Server Hardware 113.3.1 Server: 113.3.2 Minimum processor speed: 113.3.3 Minimum memory: 113.3.4 Minimum local drive space: 113.4 Storage 123.4.1 Expected file server disk storage (in MB): 123.4.2 Expected database storage (in MB): 123.4.3 Expected ftp storage (in MB): 123.4.4 Expected media/image storage (in MB): 123.5 Load Balancing/Fault Tolerance 123.5.1 Does the application support load balancing? Yes. 123.5.2 Implement load balancing – YES/NO: 123.6 Networking 123.6.1 Any application specific port assignments? 123.6.2 Any additional configuration? 123.7 Additional Notes 12

4. Proposed NCICB Deployment Environment (To be answered by systems team) 124.1 Hardware 124.2 Technology Stack 124.3 File Server 124.4 Database 124.5 Networking 134.6 Other Resources 13

5. Impact Assessment (To be answered by systems team) 135.1 Overview 135.2 Cost 135.3 Timeline to implement 135.4 Additional Notes 13

6. Acceptance 13

7. Appendix 1 - Future Systems Requirements 147.1 New Architecture Diagram 147.2 Notes on the design change 147.3 Hardware 147.3.1 Servers 147.3.2 Processor speed 147.3.3 Memory 147.3.4 Drive Space 147.4 Software (Technology Stack) 147.4.1 Web Server 147.4.2 App Server 147.4.3 Other components 147.5 Fault Tolerance (Redundancy) 147.5.1 Does the application support load balancing? 147.5.2 Implement load balancing – YES/NO 147.5.3 Load balancing requirements 147.5.4 Fault tolerance solution suggested 147.5.5 Additional requirements (if any) 147.6 Performance Enhancements 14

Confidential


7.6.1 Processing Power 147.6.2 Memory 147.6.3 I/O 147.6.4 Other needs 14

Confidential


1. Introduction

1.1 PurposeThe 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.

1.2 Guidelines for Completing the ARCThe 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 team’s 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.

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

2.1 General Information

2.1.1 Project DescriptionThe NCIt Browser (Term Browser) is a web-based terminology browser which is intended to allow users to browse and search the NCI supported vocabularies along with other biomedical vocabularies. The terminology sources exposed through the NCItBrowser (Term Browser) will be retrieved via LexEVS 6.0.

Confidential


Contact InformationTitle Name Phone Email

Product Manager Larry Wright (301) 435-4873 [email protected]

Project Manager Jason Lucas (301) 527-6615 [email protected]

QA Manager Steve Hunter (301) 435-6370 [email protected]

Development Lead Kim Ong (301) 443-2962 [email protected]

Developer David Yee (301) 443-6219 [email protected]

Technical Lead Wilberto Garcia (301) 443-3343 [email protected]

2.1.2 Major Deployment MilestonesMilestone Date

Planned Release to DEV 09/15/2010

Planned Release to QA 12/15/2010

Planned Release to Staging TBD

Planned Release to Production TBD

2.2 Architectural Details

2.2.1 High level architectural description:

The NCIt Browser (Term Browser) is Java-Based n-Tier architecture is which assigns functional responsibilities to separate application layers. N-Tier architecture fosters loosely coupled and tightly cohesive architecture in which objects in each layer are focused on specific architectural responsibilities yet, cleanly integrate with the other layers. Separation between UI elements and the business model is accomplished using Sun’s Java Server Faces release 1.2.

Confidential


2.2.2 High Level Design Diagram (If available):

Figure 1 - High Level Diagram

2.2.3 Implementation language(s) used?

The NCIt Browser (Term Browser) implementation language is Java.

2.2.4 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?Connections/requests to the NCIt Browser (Term Browser) application will be session based. There is no reason why the application would not support “sticky session” load balancing. Our server side communications will go against the Distributed LexEVS 6.0 API and all requests will be stateless.

2.2.5 Will the application be caching data? If so, what is being cached and how much data will be cached?Yes, for performance, the NCIt Browser (Term Browser) application uses the Ehcache open source product to cache vocabulary trees in memory. Tree overflow is written to disk. Usage is less that 25mb.

Confidential


2.2.6 What data files will be created (if any)? How much data will be saved on an on going basis?Yes, overflow from vocabulary tree caching (see 2.2.5) is written to disk.

We don’t anticipate the cache file exceeding 50mb.

File written is: ${application.data.path}/cache/treeCache.data

2.2.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?No, the NCIt Browser (Term Browser) will access the terminology data via the LexEVS 6.0 API. A “local, file system” LexEVS 6.0 deployment is required.

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

2.2.9 If this is a web-based application, what are the preferred virtual hosts names to be registered?The NCIt Browser (Term Browser) is a web-based application. The preferred virtual host name is

ncit.nci.nih.govncitbrowser.nci.nih.govnciterms.nci.nih.gov(No change for the previous release)

2.2.10 Any additional architectural details that may be of significance to the needed deployment environment.The NCIt Browser (Term Browser) application links to the “New Term” web form to allow users to submit suggestions for new terms or modifications to existing terms. This suggest ”New Term” functionality has been implemented in a, small, separate war file (for easy of deployment) and deployed in the same container as the NCIt Browser (Term Browser).

See GForge “New Term Architectural Review Checklist ” document for “New Term” details at https://gforge.nci.nih.gov/docman/index.php?group_id=590&selected_doc_group_id=4953&language_id=1

2.3 Performance Requirements

2.3.1 Total number of users for this application?Initial Estimate: 2000

2.3.2 Peak number of concurrent users?Initial Estimate: 200

2.3.3 Peak number of requests/minute?Initial estimate: 30

Confidential

https://gforge.nci.nih.gov/docman/index.php?group_id=590&selected_doc_group_id=4953&language_id=1

https://gforge.nci.nih.gov/docman/index.php?group_id=590&selected_doc_group_id=4953&language_id=1


2.3.4 Up time requirements?

Standard for NCICB. (24 hours/day, 7 days/week)

2.3.5 Acceptable down time when recovering from major systems disaster?

Standard for NCICB (24 – 48 hours)

2.4 NCICB Project DependenciesThe NCIt Browser (Term Browser) has a dependency on is the Distributed LexEVS 6.0 API and a locally deployed LexEVS 6.0 instance. Local file system access to the LexEVS 6.0 configuration and Lucene index files is required.

2.5 Configuration Management DetailsBriefly describe your current configuration management practices here.

Standard version control process for NCICB applications.

2.5.1 Version ControlWhat version control software are you currently using, if any?

SVN, url is https://gforge.nci.nih.gov/svnroot/ncit

Expecting migration to the new CSM with this release.

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

Standard version control process for NCICB applications.

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

Not needed, already on SVN.

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

Kim OngDavid YeeTracy SafranRobert WynneJason Lucas Wilberto A. Garcia

Confidential Page 1


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

NCIt Browser (Term Browser) will use the NCICB BDA process for its build and deployment. Currently implemented using BDA version 1.7.2.

2.5.6 Other CM NeedsDescribe any other CM needs?

None.

2.6 Additional NotesNone.

Confidential Page 1


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

3.1 Operating SystemNo operating system dependencies currently exist. Java based web application.

3.2 Software (Technology Stack)

3.2.1 Web Server:None.

3.2.2 App Server:JBoss 5.1.

3.2.3 Database Server:None

3.2.4 Other software components: Sun Microsystems Java Server Faces 1.2– Included with JBoss 5.1

3.3 Server Hardware

3.3.1 Server:NCI standard hardware. No hardware dependencies currently exist.

3.3.2 Minimum processor speed:Minimum required by JBoss 5.1.

3.3.3 Minimum memory:2048mb JVM heap size.

3.3.4 Minimum local drive space:Minimum required by JBoss 5.1 plus 150 MB for NCIt Browser (Term Browser).

3.4 Storage

3.4.1 Expected file server disk storage (in MB):Less than 100MB

3.4.2 Expected database storage (in MB):0 MB

3.4.3 Expected ftp storage (in MB):0 MB

3.4.4 Expected media/image storage (in MB): 0 MB

Confidential Page 1


3.5 Load Balancing/Fault Tolerance

3.5.1 Does the application support load balancing?Yes.

3.5.2 Implement load balancing – YES/NO: Yes. Load balancing was implement in release 1.1.

3.6 Networking

3.6.1 Any application specific port assignments?Standard port required by JBoss 5.1. May be set to any suitably available port #.

3.6.2 Any additional configuration?No.

3.7 Additional NotesNone.

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

4.1 Hardware<<dev, qa, staging, production servers to be used>>

4.2 Technology Stack<<specific technology stack to be used>>

4.3 File Server<<space allocation on big IP, NFS mount points, initial size allocation…>>

4.4 Database<<database server to used, schema names to be created, initial size, maximum size…>>

4.5 Networking<<e.g. any BigIP configuration necessary, …>>

4.6 Other Resources<<e.g. ftp server access, media server access, …>>

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

5.1 Overview

5.2 Cost

Confidential Page 1


5.3 Timeline to implement

5.4 Additional Notes

6. AcceptanceProject Lead ( ) Project Coordinator – NCICB ( )

Systems Team SCM Administrator

Confidential Page 1


7. Appendix 1 - Future Systems RequirementsIn this section, describe any projected future anticipated requirements for your system.

7.1 New Architecture Diagram

7.2 Notes on the design change

7.3 Hardware

7.3.1 Servers

7.3.2 Processor speed

7.3.3 Memory

7.3.4 Drive Space

7.4 Software (Technology Stack)

7.4.1 Web Server

7.4.2 App Server

7.4.3 Other components

7.5 Fault Tolerance (Redundancy)

7.5.1 Does the application support load balancing?

7.5.2 Implement load balancing – YES/NO

7.5.3 Load balancing requirements

7.5.4 Fault tolerance solution suggested

7.5.5 Additional requirements (if any)

7.6 Performance Enhancements

7.6.1 Processing Power

7.6.2 Memory

7.6.3 I/O

7.6.4 Other needs

Confidential Page 1

NCIt Browser (Term Browser) · Web viewEVS NCIt Browser (Term Browser) 2.0 08/19/10 Revision...

Documents

Transcript of NCIt Browser (Term Browser) · Web viewEVS NCIt Browser (Term Browser) 2.0 08/19/10 Revision...