FB_Architectural Checklist

cuttlefishblueΔιαχείριση Δεδομένων

16 Δεκ 2012 (πριν από 4 χρόνια και 10 μήνες)

224 εμφανίσεις



NCI Center for Bioinformatics















Architectural Review Checklist


Firebird (Federal Investigator Registry)

1.3















Architectural Review Checklist


Version: 0.1

Firebird 1.3


Date: 03/27/2008



Confidential


Page
2

of
15

Revision Document History

Date

Versi
on

Description

Author

3/27
/08

0.1

Initial draft

Amy Henry













Architectural Review Checklist


Version: 0.1

Firebird 1.3


Date: 03/27/2008



Confidential


Page
3

of
15

Table of Contents
1. Introduction

6

1.1 Purpose

6

1.2 Guidelines for Completing the ARC

6

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

6

2.1 General Information

6

2.1.1 Project Description

................................
................................
................................
......................

6

2.1.2 Contact Information

................................
................................
................................
.....................

6

2.1.3 Major Deployment

Milestones

................................
................................
................................
.....

7

2.2 Architectural Details

7

2.2.1 caBIG Silver Compliance

7

2.2.2 BRIDG Model Harmonization

7

2.2.3 PO provides the user front
-
end interface

7

2.2.4 General purpose API

7

2.2.5 Grid Service

7

2.2.6 Messaging

8

2.2.7 Node support over Grid

8

2
.2.8 Data Curation

9

2.2.9 Security

9

2.3 High Level Design Diagram (If available):

10

2.3.1 Implementation language(s) used?

................................
................................
...........................

11

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

........

11

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

................................
................................
................................
................................
..............

11

2.3.4 What data files will be created (if any)? How much data will be s
aved on an on going basis?

11

2.3.5 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?

................................
................................
......

11

2.3.6 Are there any external/non
-
NCICB data sources that will be accesse
d by the application?

....

11

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

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

................................
................................
................................
................................
.......

11

2.4 Performan
ce Requirements

11

2.4.1 Total number of users for this application?

................................
................................
...............

11

2.4.2 Peak number of concurrent users?

................................
................................
...........................

12

2.4.3 Peak number of requests/minute?

................................
................................
............................

12

2.4.4 Up time requirements?

................................
................................
................................
..............

12

2.4.5 Acceptable down time when recovering from major systems disaster
?

................................
...

12

2.5 NCICB Project Dependencies

12

2.6 Configuration Management Details

12

2.6.1 Version Control

................................
................................
................................
..........................

12

2.6.2 Change Control

................................
................................
................................
.........................

12

2.6.3 Migration to CVS

................................
................................
................................
.......................

13

2.6.4 Users

................................
................................
................................
................................
.........

13

2.6.5 Build Process
................................
................................
................................
.............................

13

2.6.6 Other CM Needs

................................
................................
................................
.......................

13

2.7 Additional Notes

13

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

13

3.1 Operating System

13

3.2 Software (Technology Stack)

14

Architectural Review Checklist


Version: 0.1

Firebird 1.3


Date: 03/27/2008



Confidential


Page
4

of
15

3.2.1 Web Server: <<Apache/Tomcat/ZOPE/…>>

................................
................................
............

14

3.2.2 App Server:
................................
................................
................................
................................

14


JBoss Application Server

................................
................................
................................
..................

14


JBOSS Messaging

................................
................................
................................
............................

14


Java Enterprise Ed
ition 5

................................
................................
................................
..................

14

3.2.3 Database Server:

................................
................................
................................
.....................

14

3.2.4 PostgreSQL Database Server

................................
................................
................................
...

14

3.2.5 Other software components: <<PERL x.x, Python x.x, …>>

................................
....................

14

3.3 Server Hardware

14

3.3.1 Server: <<type, model, …>>

................................
................................
................................
.....

14

3.3.2 Minimum processor speed:

................................
................................
................................
.......

14

3.3.3 Minimum memory:

................................
................................
................................
....................

14

3.3.4 Minimum local drive space:

................................
................................
................................
.......

14

3.4 Storage

15

3.4.1 Expected file server disk storage (in MB):

................................
................................
.................

15

3.4.2 Expected database storage (in MB):

................................
................................
.........................

15

3.4.3 Expected ftp storage (in MB):

................................
................................
................................
....

15

3.4.4 Expected media/image storage (in MB):

................................
................................
...................

15

3.5 Load Balancing/Fau
lt Tolerance

15

3.5.1 Does the application support load balancing?

................................
................................
..........

15

3.5.2 Implement load balancing


YES/NO

................................
................................
........................

15

3.6 Networking

15

3.6.1 Any application specific port assignments?

................................
................................
..............

15

3.6.2 Any additional configuration?

................................
................................
................................
....

15

3.7 Additional Notes

15

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

15

4.1 Hardware

15

4.2 Technology Stack

15

4.3 File Server

15

4.4 Database

16

4.5 Networking

16

4.6 Other Resources

16

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

16

5.1 Overview

16

5.2 Cost

16

5.3 Timeline to implement

16

5.4 Additional Notes

16

6. Acceptance

16

7. Appendix 1
-

Future Systems Requirements

17

7.1 New Architecture Diagram

17

7.2 Notes on the design change

17

7.3 Hardware

17

7.3.1 Servers

................................
................................
................................
................................
......

17

7.3.2 Processor speed

................................
................................
................................
.......................

17

7
.3.3 Memory

................................
................................
................................
................................
......

17

7.3.4 Drive Space

................................
................................
................................
...............................

17

7.4 Software (Technology Stack)

17

7.4.1 Web Server

................................
................................
................................
................................

17

7.4.2 App Server

................................
................................
................................
................................
.

17

Architectural Review Checklist


Version: 0.1

Firebird 1.3


Date: 03/27/2008



Confidential


Page
5

of
15

7.4.3 Other components

................................
................................
................................
.....................

17

7.5 Fault Tolerance (Redundancy)

17

7.5.1 Does the application support load balancing?

................................
................................
..........

17

7.5.2 Implement load balancin
g


YES/NO

................................
................................
........................

17

7.5.3 Load balancing requirements

................................
................................
................................
....

17

7.5.4 Fault tolerance solution suggested
................................
................................
............................

17

7.5.5 Additional requirements (if any)
................................
................................
................................
.

17

7.6 Performance Enhancements

17

7.6.1 Processing Power

................................
................................
................................
.....................

17

7.6.2 Memory

................................
................................
................................
................................
......

17

7.6.3 I/O

................................
................................
................................
................................
..............

17

7.6.4 Other needs

................................
................................
................................
...............................

17

Architectural Review Checklist


Version: 0.1

Firebird 1.3


Date: 03/27/2008



Confidential


Page
6

of
15


1.
Introduc
tion


1.1
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 c
onsidered to be a dynamic artifact for
any NCICB project and should be maintained in the configuration library (i.e.
Subversion
) for
each project. For new projects, this document template will be automatically checked into the
projects repository by the S
CM 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 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 familiar
ity 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 th
e 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 applicatio
n.
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
Projec
t Description

The Firebird
application automates the FDA Form 1572 registration process and enables

investigators to
register online with NCI and other sponsors, including pharmaceutical companies. This release fixes
several defects.

2.1.2
Contact Information

Ti
tle

Name

Phone

Email

Project Manager

Shared between
Leslie Power and
David Loose

Leslie:
202
-
369
-
0971

David:

Leslie:
powerless@mail.nih.gov

David:

Lead Analyst

David Loose

See above

See above

Architect

Le
slie Power

See above

See above

SCM Coordinator

&
Tech Lead

Scott Miller

202
-
359
-
0990

smiller@5amsolutions.com

Architectural Review Checklist


Version: 0.1

Firebird 1.3


Date: 03/27/2008



Confidential


Page
7

of
15

Developer

Harsha Jayanna




2.1.3
Major Deployment Milestones

Milestone

Date

Planned Release to QA

Ap
ril 7
, 2008

Planned Release to Staging

April14
, 2008

Planned Release to Production

April 28, 2008


2.2
Architectural Details

FIREBIRD automate
s

the investigator registration process that currently requires submission of a
series of paper forms known as the
“1572” forms. FIREBIRD enable
s

investigators to register online
with NCI and other sponsors, including pharmaceutical companies. Through a single web
-
based
interface to a secure central repository, investigators will be able to maintain their profile cont
aining the
accreditation information required for their participation in drug trials. Investigators electing to
participate in government, academic, or industry drug trials can access and apply their profile
information to regulatory submission documents a
utomatically. FIREBIRD provides

the ability for an
I
nvestigator to apply a digital signature to the electronic version of the form. When the signature is
authenticated with an appropriate, legally supported identity credential, it carries the same legitima
cy
as an ink signature on a paper document. By allowing investigators to maintain and manage all
registrations centrally, the resulting reduction of paperwork is expected to increase the efficiency and
lower the cost of conducting clinical trials, thereby
speeding the delivery of new therapies to patients
and the medical community

2.2.1
Encryption

The community this application serves is very sensitive about their data and must use
applications that support the HIPPA Guidelines depicted in
21 CFR Part 11

regarding electronic
records and signatures. Therefore, the entire application will be encrypted using a Secure Socket
Layer (SSL) of 128
-
bit encryption.

2.2.2
caBIG Silver Compliance

Firebird

must be implem
ented in such a way that it may be certified caBIG Silver compliant.

2.2.3
Grid Service

Firebird

will
use the PO
Grid data service
and CQL query
to bootstrap their data (populate
FIREBIRD
local caches from PO


typically a one
-
time activity), or perform caBIG c
ompliant
searches. This service will be deployed with a Globus container configured to run in JBoss.

2.2.4
Messaging

Because Firebird relies heavily on PO data and messaging techniques, Firebird must be
deployed in identical environment to PO.

Architectural Review Checklist


Version: 0.1

Firebird 1.3


Date: 03/27/2008



Confidential


Page
8

of
15

Firebird will us
e the
PO service
, which
is designed to be the “the consistent source of truth” for
information relating to person and organizations.
Firebird can choose
to read information directly
from PO as it is needed, while retaining only a reference to the data in
PO.
Or Firebird may
determine to retain a
local cache of person and organization information for performance,
practicality, or preference will have a need to maintain coherence between
Firebird

data and PO
data. This is achieved through a publish/subscri
be paradigm, where PO publishes changes to
objects to the
Firebird
. In order for
Firebird

to have reliable copies of the “truth,” PO will need a
reliable messaging system that can easily be integrated.

In considering how to meet the requirements, we review
ed two candidate interfaces:


Java Messaging Service (JMS)
, a well accepted Java API
(
http://java.sun.com/products/jms/
) that provides a standard API to talk to message
queues and a standard API for pub/sub
. Most messaging queues have an interface that
speaks JMS.

Web Services Notification (WS
-
N)

is a well defined web services
-
based messaging and
notification standard. (
http://www
.oasis
-
open.org/committees/tc_home.php?wg_abbrev=wsn

and
http://www.ibm.com/developerworks/library/specification/ws
-
notification/
). WS
-
N is
platform independent and u
ses web service standards. The deployment and use of WS
-
N
is somewhat more burdensome than JMS (the necessary burdens of platform
independence).

The caGRID platform theoretically supports WS
-
N because the grid supports web
services. In practice, however,
the grid does not make web notification available as an
API for other systems to use. Instead the grid uses Globus to handle notification. Globus
has WS
-
N but is not a general purpose messaging system, so additional development
will be required to support
WS
-
N. (In addition and generally speaking, the burden on PO
clients to utilize WS
-
N is greater than to use JMS.)

Our recommendation is to write PO messaging in JMS for the first release, hosted on
JBoss Messaging (JM), a full
-
featured messaging system. Sub
scribing external systems
subscribe to JM via JMS. This allows us to control authentication over the queue, using
the same authentication mechanisms used by client apps when they connect with PO via
its (non
-
grid) API. (In this initial release, non
-
Java ex
ternal apps would have difficulty
subscribing and may not be able to subscribe.)

As the need evolves, a WS
-
N translator can be written and deployed in a PO future
release,
or

PO can publish to a different messaging queue (such as Apache Service Mix,
advis
ed by the Grid development team), which, with some level of custom development,
would be able to provide WS
-
N. (Note that some level of custom code is required to
support WS
-
N regardless of methodology or message provider.)

This proposal allows PO to have

guaranteed message delivery with initial support for
JMS and future support for WS
-
N.

2.2.5
Security

Firebird i
s concerned with the security of all interfaces to the system:



Grid service security is managed by Globus (running in JBoss).



SOAP, RMI, and curator w
eb UI interactions will be handled via CSM.

Architectural Review Checklist


Version: 0.1

Firebird 1.3


Date: 03/27/2008



Confidential


Page
9

of
15

Firebird using the
web UI services

of PO
,
has
the burden of authenticating the user
.
PO,
however, will need to establish trust with the client application, and also, that PO is servicing a
user trusted by the cli
ent application.

2.3
High Level Design Diagram (If available):

2.3.1
Implementation language(s) used?

Java
1.5


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

Yes. HTTP request for the web UI rely on statefull sessions for processing. The load balancer should use
the
jsessionid

parameter and cookie to bind requests from the client to the servers that are hosting the
session
.


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

PO will utilize Hibernate's 2nd level cache to improve performance and reduce hits to the database. The
amount of data cached is relatively small
-

und
er 50MB
-

and will be stored in memory. Hibernate's
caching mechanism will need no more that 1GB of disk space for swapping (or spillover) in the directory
identified by the System Property
java.io.tmpdir.


2.3.4
What data files will be created (if any)? How m
uch data will be saved on an on going basis?

PO will
need

1GB of disk space for CSM lab imports that will be loaded from a file. The CMS lab files are
about 800Mb. These are quarterly updates of lab information provided to us via subscription (on DVD)
from

CMS. These files can be deleted once the import is complete.


2.3.5
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?

Yes,
we request that
Firebird

schemas be created

in Postgres for the va
rious tiers

dev, QA and Staging
and Production.



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

Firebird is hosted at NCI.
(Leslie, isn’t it also deployed at a few research centers?)


2.3.7
If this

is a web
-
based application, what are the preferred virtual
host’s

names to be registered?

Don’t we have one already?

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


2.4
Performance Requirements

2.4.1
Total num
ber of users for this application?

Any ideas


For the PO web application for curation, we expect about 10
-
15 users at NCI.

Architectural Review Checklist


Version: 0.1

Firebird 1.3


Date: 03/27/2008



Confidential


Page
10

of
15

2.4.2
Peak number of concurrent users?

We’ll come up with 5 candidate operations that we’ll ensure won’t take any more than 3 to 5
seconds

to perform under a concurrent user load of 25.

2.4.3
Peak number of requests/minute?

See above; will this work for you?

2.4.4
Up time requirements?

The reliance on the system’s availability is critical to the client applications that get and send data
to PO and rely

on the PO interface to perform functions on their behalf. Since the Production tier
for the application will not be hosted at NCI, do you still need this information?

In general any client app and PO should have maintenance scheduled at the same time.

2.4.5
Ac
ceptable down time when recovering from major systems disaster?

I will confirm this with the Product Manager, but we propose recovery should be within 2
-
4 hours.
The important consideration is that the client apps cannot be up when PO is down. (Initial cli
ent
apps are Firebird and caCTUS Lite.)


2.5
NCICB Project Dependencies

The following caCore components must be incorporated into
FIREBIRD
’s architecture:

CSM


The security modu
le must implement CSM

BRIDG


A comprehensive domain analysis model used to collaborate with other components.

caDSR


Must be used to register meta data for exposed API(s)

caGRID


Must be used to allow access to the to the consistent source of truth for People and
Organizations.


2.6
Configurati
on Management Details

Briefly describe your current configuration management practices here.

Code is checked in daily into developer’s branch. After code is reviewed, the code is merged to
the proper tag.

All project artifacts are stored in the Subversion
repository. Updates are made by project team
members on the documents in the repository and committed when completed.

2.6.1
Version Control

What version control software are you currently using, if any?

Subversion


2.6.2
Change Control

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

All change requests are logged in the gforge tracker under Feature Requests. The project CCG must
indicate if a change request is approved. (See the PO confi
guration management plan:
http://gforge.nci.nih.gov/svnroot/posvc/po/trunk/documents/config_change_management/po_configu
ration
_management_plan.doc

Architectural Review Checklist


Version: 0.1

Firebird 1.3


Date: 03/27/2008



Confidential


Page
11

of
15


2.6.3
Migration to CVS

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

Not sure, we planned to stay in Subversion. Is it required to move to CVS?


2.6.4
Users

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

Person

E
-
mail

Gmail







Scott Miller

smiller@5amsolutions.com

scott.miller5am@gmail.com







Leslie Power

powerless@mail.nih.gov

elliemental@gmail.com




Harsha Jayanna

jayannah@mail.nih.gov

hjayana@gmail.com


2.6.5
Build Process

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

We’ll be working with the automated build team and will need Maven 2.0.8.

2.6.6
Other CM Needs

Describe any other CM needs?


2.7
Additional Notes


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

3.1
Operating System

The expectation is that PO will be installed in multiple locations outside of NCI as well as within
NCI. For those ins
tallations outside NCI, PO should be installable on the following Operating
Systems:

RedHat Linux Enterprise (EL3O04)

Windows 2003 Server (not Vista)

The variety of flavors directs the decision to choose Java as the platform for deployment.

Architectural Review Checklist


Version: 0.1

Firebird 1.3


Date: 03/27/2008



Confidential


Page
12

of
15

3.2
Software (Tec
hnology Stack)

3.2.1
Web Server: <<Apache/Tomcat/ZOPE/…>>

3.2.2
App Server:



JBoss Application Server

For the production environment, the version of JBoss will be 4.2.2
(
http://sourceforge.net/project/showfiles.php?group_id=22866&package_id
=16942&release_id=548923
)

When PO becomes available over the caGrid (version 1.1), a separate instance of JBoss
will need to be mounted, version 4.0.4 per grid specifications
.



JBOSS Messaging

To support communication with external systems, PO will use JBoss Messaging 1.3.0
SP3.



Java Enterprise Edition 5

While acknowledging that CBITT prefers all Java EE technologies to be within the CBIIT
supported technology stack, the PO pro
ject will make special requests for components
that are not currently supported.



Java EE 5 (provided by JBoss AS 4.2.2GA)

o

Java SE 1.5.0_14

o

JSP 2.1

o

Servlet 2.5

o

EJB 3.0



JBoss Messaging 1.4.0 SP3



Hibernate 3.2 (provided by JBoss AS 4.2.2GA)



Struts 2.0.x (pr
ovided by PO)

3.2.3
Database Server:

3.2.4
PostgreSQL Database Server

We’d prefer PostgreSQL version 8.3, but 8.1 + is fine. Support for different database vendors
(Oracle, IBM, MySQL) is not in scope.

3.2.5
Other software components: <<PERL x.x, Python x.x, …>>


3.3
Server Ha
rdware

3.3.1
Server: <<type, model, …>>

3.3.2
Minimum processor speed:

3.3.3
Minimum memory:

The minimum amount of memory to be available to the application should be 1GB of memory.


Architectural Review Checklist


Version: 0.1

Firebird 1.3


Date: 03/27/2008



Confidential


Page
13

of
15

3.3.4
Minimum local drive space:

The expectation is that the application server should have roug
hly 1GB of space available.
However, the file and database servers will need significant resources available to them as the
data they will handle will be at the terabyte level for a long time to come.


3.4
Storage

3.4.1
Expected file server disk storage (in MB):

Tem
porary storage needed (see, 2.3.4 )

3.4.2
Expected database storage (in MB):

The database server space needs will not exceed 50GB.

3.4.3
Expected ftp storage (in MB):

Not

needed

3.4.4
Expected media/image storage (in MB):


3.5
Load Balancing/Fault Tolerance

3.5.1
Does the applicatio
n support load balancing?

The PO system must provide a reliable and fast service to external systems that depend on it. It
will be designed to function as both a standalone server, and as cluster of homogeneous servers.
The initial deployment can be a si
ngle node. More nodes can be added to the cluster to reduce
load and increase redundancy.

3.5.2
Implement load balancing


YES/NO


3.6
Networking

3.6.1
Any application specific port assignments?

All of these answers are for the initial release of PO. When we go to expose

the messaging,
remote java api, or grid, the answers will change.

From outside the firewall, we need 443 open (SSL / HTTPS). We should also have 80 open from
outside, then configure apache with a rewrite rule from 80
-
> 443 (http
-
> https).

From inside t
he firewall, we need the JNDI ports to be at a know location for Firebird to connect
to. This is similar to caArray, so systems should know what we're looking for here [Bill/Eric have
the details.] We also need the JMS queue to be at a known port, also f
or Firebird.

3.6.2
Any additional configuration?


3.7
Additional Notes


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

4.1
Hardware

Dev, QA and Staging

Production will be hosted off
-
site


Architectural Review Checklist


Version: 0.1

Firebird 1.3


Date: 03/27/2008



Confidential


Page
14

of
15

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 Resource
s

<<e.g. ftp server access, media server access, …>>



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

5.1
Overview


5.2
Cost


5.3
Timeline to implement


5.4
Additional Notes



6.
Acceptance

Project Lead ( )


Project Coordinator


NCICB (

)


Systems Team


SCM Administrator




Architectural Review Checklist


Version: 0.1

Firebird 1.3


Date: 03/27/2008



Confidential


Page
15

of
15

7.
Appendix 1
-

Future Systems Requirements

In 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
Proc
essor 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 solu
tion 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