FMO
Architecture Design
Project Code: FMO
Document Code: FMO_Architecture Design_v1.0
Hanoi, Aug 2011
FMO – Architecture Design
v1.0
RECORD OF CHANGE
*A - Added M - Modified D - Deleted
Effective
Changed Items
A*
Date
2-Aug-11
04ae-BM/PM/HDCV/FSOFT v1/2
Change Description
New Version
M, D
A
Create new
Internal use
1.0
2/34
FMO – Architecture Design
v1.0
SIGNATURE PAGE
ORIGINATOR: Nguyen Tien Dat
2-Aug-11
Designer
REVIEWERS:
Le Hai Nam
3-Aug-11
Technical Leader
Doan Thi Thuy Linh
3-Aug-11
Quality Assurance
APPROVAL:
Nguyen Tien Chien
3-Aug-11
Project Manager
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
3/34
FMO – Architecture Design
v1.0
TABLE OF CONTENTS
1
INTRODUCTION ........................................................................................................ 6
1.1
Purpose ...................................................................................................................6
1.2
Scope ......................................................................................................................6
1.3
Definitions, Acronyms and Abbreviations ...................................................................6
1.4
References ..............................................................................................................7
1.5
Overview .................................................................................................................7
2
ARCHITECTURAL REPRESENTATION ........................................................................ 9
3
ARCHITECTURAL GOALS AND CONSTRAINTS ........................................................11
3.1
Technical Platform ................................................................................................. 11
3.2
Security ................................................................................................................. 11
3.3
Persistence ............................................................................................................ 11
3.4
Reliability/Availability .............................................................................................. 12
3.5
Performance .......................................................................................................... 12
4
USE CASE VIEW ......................................................................................................13
5
LOGICAL VIEW ........................................................................................................16
6
PROCESS VIEW .......................................................................................................17
7
6.1
Client Environment ................................................................................................. 18
6.2
Server Environment ............................................................................................... 18
DEPLOYMENT VIEW ................................................................................................19
7.1
7.1.1
Application server ......................................................................................................... 19
7.1.2
Database server ........................................................................................................... 20
7.2
8
Hardware recommendations for servers .................................................................. 19
Software recommendations for servers .................................................................... 20
IMPLEMENTATION VIEW ........................................................................................22
8.1
Implementation Technology ................................................................................... 22
8.1.1
8.2
Why ASP.Net MVC ........................................................................................................ 22
Layer Technology ................................................................................................... 24
8.2.1
View ........................................................................................................................... 24
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
4/34
FMO – Architecture Design
9
v1.0
8.2.2
Controller .................................................................................................................... 24
8.2.3
Model .......................................................................................................................... 25
8.2.4
Common ..................................................................................................................... 26
SIZE AND PERFORMANCE .......................................................................................30
9.1
Network Load Balancing (NLB) ................................................................................ 30
9.2
Failover Clustering ................................................................................................. 31
9.3
Hardware recommendations for high availability servers ........................................... 32
9.3.1
Application server ......................................................................................................... 32
9.3.2
Database server ........................................................................................................... 32
9.4
Software recommendations for high availability servers ............................................ 33
10 QUALITY .................................................................................................................33
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
5/34
FMO – Architecture Design
1
v1.0
INTRODUCTION
1.1 Purpose
This Software Architecture Document (SAD) describes the proposed architecture for El Camino
Hospital (ECH) Mobile Website. It is intended to capture and convey the significant
architectural decisions that have been made on the system.
The SAD has two purposes. First, it is intended to communicate the architectural direction for
El Camino Hospital Mobile Website to ECH. Second, it is to inform the architect of El Camino
Hospital Mobile Website by software development organization.
1.2 Scope
The SAD addresses the entire architecture of the custom software to be developed to
implement ECH Mobile Website. The architecture is presented in various views that present
ECH Mobile Website’s high-level functionality, major logical components, deployment,
implementation technologies, considerations for performance and security.
The SAD does not address the following:
• The architecture of underlying commercial off-the-shelf software, such as Microsoft .NET or
HTML 5
• The architecture of existing framework of ECH
• The architecture of other ECH applications
• The architecture of specific hardware and network infrastructure to be used to support ECH
Mobile Website
1.3 Definitions, Acronyms and Abbreviations
Term
Definition
ECH
El Camino Hospital
MVC
Model – View – Controller
SAD
Software Architecture Design
WS
Web Service
IIS
Internet Information Server
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
6/34
FMO – Architecture Design
v1.0
Term
Definition
User
The normal user of ECH website
Registered User
The user who has a login account to ECH website
NLB
Network Load Balancing
1.4 References
Document
Location
iPhone_App_Concepts_Presentation_ Customer Supplied
Description
Vision
by_ECH_201101.pdf
iPhone_App_Research_Presentation_ Customer Supplied
Vision
by_ECH_20110126.pdf
Mobile_POV_v2_20110208
Customer Supplied
Vision
Mobile_Optimized_Website_Strategy
Customer Supplied
Requirement
Customer Supplied
Requirement
_Presentation_v1_20110328.pdf
ECH_MobileWeb_0727.pdf
FMO_Functional
Requirement Project folder
Requirement
Specification_v1.0.doc
FMO_Questions
and
Answers Customer Supplied
Management Sheet_20110727.xslx
Requirement
MVC overview
http://msdn.microsoft.com/enus/library/ff649643.aspx
Architect
ASP.Net MVC 3
http://www.asp.net/mvc/mvc3#o Architect
verview
Log4Net features
http://logging.apache.org/log4n
et/release/features.html
Architect
1.5 Overview
In order to cover all area of the architecture, the SAD contains the following sections:
Architectural Representation: describe the purpose of each view of the system.
Architectural Goal and Constraints: describe the architectural constraints of the system.
Use Case View: describe the major use cases of the system.
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
7/34
FMO – Architecture Design
v1.0
Logical View: describe the logical parts of the system.
Process View: describe the main processes of the system and the external system that it
interacts with.
Deployment View: describe how the system will be deployed.
Implementation View: describe how the system will be implemented, in development
perspective.
Size and Performance: describe the proposed solution to satisfy the need of a scalable and
high performance system.
Quality: describe the quality goals of the system.
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
8/34
FMO – Architecture Design
2
v1.0
ARCHITECTURAL REPRESENTATION
The ECH System Architecture is represented by five views defined in the 4+1 view model. The
views of the system includes the Use Case View defining key functionality, the Logical View
defining structure of components, the Process View delineating performance factors, the
Deployment View describing the system topology and the Implementation View describing the
software construction.
Figure 1: The 4+1 View Model
1. Use Case View
Audience: All stake-holders.
Related Artifacts: Use Case Model
Area: this view overviews ECH’s use cases that define the functions expected of the
software. It describes major use cases that have significant impact on the system
architecture.
2. Logical View
Audience: Designers.
Related Artifacts: Design Model
Area: This view contains diagrams and descriptions of the software tiers and
components within each tier needed to perform the functions documented in the Use
Case View.
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
9/34
FMO – Architecture Design
v1.0
The layer diagram, also known as the technology stack, defines the tiers of software
components used to implement ECH:
View, Controller and Model. Each layer is
defined by its purpose and processing responsibilities.
In addition to the layer diagram, the Logical view also contains several diagrams
depicting interaction between components within each layer. These diagrams are
derived from use cases and provide a logical structure for architecturally significant
functionality.
3. Process View
Audience: Integrators.
Related Artifacts: N/A
Area: This view describes the set up, break down, and run-time architecture of the
system in terms of the processes and threads that execute on each system platform.
4. Deployment View
Audience: Deployment Managers.
Related Artifacts: Deployment Model
Area: This view describes the mapping of the software onto the hardware (network
topology) in various deployments along with the software configurations needed to
support these deployments.
5. Implementation View
Audience: Programmers.
Related Artifacts: Implementation Model, components
Area: This view describes the actual software components that support the
implementation of the logical and process views. The view contains an enumeration
of all subsystems in the implementation model, package diagrams illustrating how
subsystems are organized as bodies of programming code.
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
10/34
FMO – Architecture Design
3
v1.0
ARCHITECTURAL GOALS AND CONSTRAINTS
This section describes the software requirements and objectives that have some significant
impact on the system architecture.
3.1 Technical Platform
Server side: ECH site will be hosted on IIS web servers and connecting to SQL Server 2008
Database servers.
The web server is listening on the web standard port 80.
All communications with clients have to comply with public HTTP, HTTPS, TCP/IP
communication protocol standards.
The system has interactions with three interfaces: ER Wait Time API, Find a Physician API and
Google Map API. The communications with the first two are just SOAP calls, while the
communication with the last one is done via a Javascript API.
Client side: Clients are iPhone and Android devices. The hybrid applications running on these
devices use the default web browsers which come along with the associated mobile OS to
make request to the server side. For example: Safari for iPhone devices. The target OS are:
-
iPhone: iOS v4 or above
-
Android: Android OS v2.2 or above
3.2 Security
The HTTP protocol will be used to facilitate communications between the client and server and
HTTPS protocol will be used for all My Family&Me functions. Basic password authentication and
role based security mechanisms will be used to protect My Family&Me site from unauthorized
access. All medical information of users must be secured per requirements of HIPAA and
TRUSTe.
3.3 Persistence
Data persistence will be addressed using a relational database.
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
11/34
FMO – Architecture Design
v1.0
3.4 Reliability/Availability
Scalability, availability and reliability are key requirements for any IT system. For this mobile
web application, we assume that the target availability is 95%.
The remaining time (18.25 days) is reserved for maintenance activities. The higher availability
can be achieved by the solution discussed in section 9 - Size and Performance.
3.5 Performance
Below are the two requirements for the performance of ECH mobile web application, with the
assumption that in normal case, there will be less than or equal to 100 concurrent users:
1. Each page should load in 4 seconds or less for 100 concurrent users.
2. Each page should load in 12 seconds or less for more than 100 concurrent users.
The solution to achieve the target performance when the number of user grows will be
discussed in section 9 – Size and Performance.
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
12/34
FMO – Architecture Design
4
v1.0
USE CASE VIEW
The diagram below included a list of use cases that represent significant and major
functionality of the system. The use cases that have significant impact on the system are:
1. Find Physician
2. View ER Wait Time
3. View ER Profile
4. Get Directions
5. View Visiting ECH
6. View Hospital Profile
7. View ECH News
8. Login (My Family&Me)
9. Create Account (My Family&Me)
10. View Family Dashboard (My Family&Me)
11. Add Profile (My Family&Me)
12. View Profile (My Family&Me)
13. Edit Profile (My Family&Me)
14. Delete Profile (My Family&Me)
<<system>>
Find Physician WS
Find Physician
Login
<<system>>
ER Wait Time WS
Create Account
View ER Wait Time
Registered User
View ER Profile
<<extend>>
User
View Family Dashboard
<<extend>>
<<extend>>
<<extend>>
Get Directions
View Profile
Add Profile
<<extend>>
Edit Profile
<<extend>>
<<extend>>
View Visiting ECH
<<extend>>
View Hospital Profile
Delete Profile
View ECH News
<<system>>
External RSS
Figure 2: Use Case Diagram (only major use cases are included)
1. Find Physician
a. Actor: User, Find Physician WS
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
13/34
<<system>>
Google API
FMO – Architecture Design
v1.0
b. Description: this is a highlighted feature based on traffic and usage of current
ECH website. It enables user to search for a doctor using full name initial, specialty
or location. System calls Find Physician web service to get the search result. The
result contains the address, phone number and certification information… of the
doctor and returned in several pages.
2. View ER Wait Time
a. Actor: User, ER Wait Time WS
b. Description: this is a high value feature of the current ECH website. It provides
user the estimated wait time for both locations of hospital: Mountain View and Los
Gatos. System calls ER Wait Time web service to get the wait times (in minutes).
The result is refreshed every 10 minutes.
3. View ER Profile
a. Actor: User
b. Description: this feature provides user the useful information of the emergency
room: address, phone number and estimated wait time.
4. Get Directions
a. Actor: User, Google Map API
b. Description: this feature allows user to see where the hospital is located in the
Google Map. It also shows users the way to the hospital from either their current
location or an entered address. This feature facilitates the Google Map API to show
the map and displays the directions.
5. View Visiting ECH
a. Actor: User
b. Description: this feature provides user the general information of the hospital.
User can choose to view information of either one of two locations of hospital or
select other locations.
6. View Hospital Profile
a. Actor: User
b. Description: this feature provides user more detail information of a location of the
hospital. User can choose to view the useful information for visitors, call the front
desk, see the campus map or get the directions to the associated location.
7. View ECH News
a. Actor: User, External RSS
b. Description: this is a useful feature that provides user lots of news from various
news sources. System gets the updates from many external RSS feeds and
networks such as Facebook, Twitter, Youtube, as well as the internal RSS feed of
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
14/34
FMO – Architecture Design
v1.0
ECH. The results will be displayed and user can choose to read, like or follow…
depends on the type of news source.
8. Login (My Family&Me)
a. Actor: Registered User
b. Description: user has to login before using any function of My Family&Me. Users
will stay login until they logout or the cookie has been cleared.
9. Create Account (My Family&Me)
a. Actor: User
b. Description: users can create a new account if they do not have one. Then they
can login to My Family&Me once the account is created.
10. View Family Dashboard (My Family&Me)
a. Actor: Registered User
b. Description: this feature display a list of the family members associated with
current logged in account. User can add, edit or delete members from this
dashboard.
11. Add Profile (My Family&Me)
a. Actor: Registered User
b. Description: this feature enables user to create a new profile for a family member.
This has five steps in which user needs to enter the personal information, medical
history, current medication, known allergies and primary physician of this profile.
12. View Profile (My Family&Me)
a. Actor: Registered User
b. Description: this feature enables user to view all information of a family member
profile. User can choose to edit or delete profile here.
13. Edit Profile (My Family&Me)
a. Actor: Registered User
b. Description: this feature enables user to edit all information of a family member
profile.
14. Delete Profile (My Family&Me)
a. Actor: Registered User
b. Description: this feature enables user to delete profile of a family member. User
will be asked to confirm the request before the deletion is triggered.
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
15/34
FMO – Architecture Design
5
v1.0
LOGICAL VIEW
This section describes the architecturally significant parts of ECH from a logical perspective,
independent of technology. The key functional components of the ECH architecture are
presented in the following diagram.
Figure 3: Logical View
Model: The model manages the behavior and data of the application domain, responds to
requests for information about its state and responds to instructions to change state.
View: The view manages the display of information. It renders the model into the suitable form
of user interface elements. There are two different views for the two types of target devices:
iPhone and Android. A server-side script will be used to detect the type of device that makes the
request and choose the corresponding view to display.
Controller: The controller receives user inputs, informing the model and/or the view to change
appropriately.
Common: This is the container of all shared modules that are used by the three layers above. It
consists of, but not limit to the following:
o
Log: the Log module contains the functions to log error exceptions to log destinations.
o
Security:
the Security module contains the functions relating to security (HIPAA,
TRUSTe).
o
Processor: the Processor module contains the functions to call web service, xml feeds.
o
Mail: the Mail module contains functions to send notification mail.
o
Validation: The Validation module contains functions to validate input data, input
request…
o
Utility: the Utility module contains utility functions (eg. Number and String functions...).
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
16/34
FMO – Architecture Design
v1.0
The diagram below explains how the Model, View and Controller work together in a simple
request flow.
Figure 4: Logical View - How MVC Works
6
PROCESS VIEW
This section describes the decomposition of the software into independent execution
processes, and the methods and modes by which these processes interact.
The runtime structure of the ECH application is that of a client-server application, with a client
(hybrid application using the default web browser) acting as a thin host for user interface
views. The other processes supporting the presentation layer, and all layers further down the
software stack, reside on the application server and/or database server. The key processes,
interfaces, threads, and systems are shown in the diagram below.
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
17/34
FMO – Architecture Design
v1.0
Figure 5: Process View
6.1
Client Environment
The client element of the ECH application will run on mobiles, and will be a simple hybrid
application using the default browser. The client element will be initiated when the user start
the hybrid application. No business logic will run in the client environment.
6.2
Server Environment
The application server components of ECH runs the presentation layer (generation of the user
interface views), the business logic layer, and the resource access layer.
The server component of ECH will take the form of a self-hosted web application.
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
18/34
FMO – Architecture Design
7
v1.0
DEPLOYMENT VIEW
Figure 6: Deployment Overview
There are three key communication links between the mobiles/PDAs and the two server groups
running in the data center. Given that messages sent between systems and servers, secure
connections are used. Encryption is used when message go across firewalls and out on the
internet. Each communication link is explained below.
• Link 1. End-users connect from their mobiles to an application server. As the number of endusers grows, more application servers will be added to maintain an acceptable response time.
The application servers are network load balanced. Each runs the View, Controllers and Data
Model layers.
• Link 2. The application servers access a database server running SQL Server to store and
recall persistent data. The number of database servers depends on the data load required. The
database servers are clustered with failover mode.
7.1 Hardware recommendations for servers
7.1.1
Component
Application server
Minimum requirement
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
19/34
FMO – Architecture Design
v1.0
Processor
64-bit, four cores, Intel Itanium 2 processor
RAM
8 GB for production use in a single server or multiple server farm
Hard disk
80 GB for system drive
7.1.2
Database server
Component
Minimum requirement
Processor
Minimum: AMD Opteron, AMD Athlon 64, Intel Xeon with Intel EM64T
support, Intel Pentium IV with EM64T support
Recommended: 64-bit, four cores
Processor speed:
Minimum: 1.4 GHz
Recommended: 2.0 GHz or faster
RAM
Minimum: 2 GB
Recommended: 4 GB or more
Maximum: 64 GB to 2 TB
Hard disk
80 GB for system drive
7.2 Software recommendations for servers
Server Type
Application server
Software requirement
Windows 2008 R2 64-bit x64 Standard OR Windows Server 2008 SP2 64-bit
x64 Enterprise
IIS 7 or above
.NET framework 4.0
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
20/34
FMO – Architecture Design
Database server
v1.0
Windows 2008 R2 64-bit x64 Standard OR Windows Server 2008 SP2 64-bit
x64 Enterprise
SQL Server 2008 R2 Standard (64-bit) x64 OR SQL Server 2008 R2
Enterprise (64-bit) x64
Note: If Standard Version of Windows Server and SQL Server are used, server scalability and
high availability are not supported.
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
21/34
FMO – Architecture Design
8
v1.0
IMPLEMENTATION VIEW
8.1 Implementation Technology
The ECH implementation will be centered around Microsoft technologies, which will include, but
not limited to, the following:
• The major implementation language will be C# with ASP.Net MVC 3 as framework
• HTML 5 for presentation layer which enables smaller effort in UI development if ECH wants
to extend ECH mobile website to other PDAs/ smart phones
• The ADO.Net Entity Framework will be used to build a data model for the business layer, and
a mapping to the logical schema used by the database
• SQL Server 2008 R2 will be the core database servers
• Language Integrated Query (LINQ) will be used to compose and execute business layer
queries.
8.1.1
Why ASP.Net MVC
The MVC pattern helps you create applications that separate the different aspects of the
application (input logic, business logic, and UI logic), while providing a loose coupling
between these elements. The pattern specifies where each kind of logic should be located in
the application. The UI logic belongs in the view. Input logic belongs in the controller. Business
logic belongs in the model. This separation helps you manage complexity when you build an
application, because it enables you to focus on one aspect of the implementation at a time. For
example, you can focus on the view without depending on the business logic.
The loose coupling between the three main components of an MVC application also promotes
parallel development. For example, one developer can work on the view, a second
developer can work on the controller logic, and a third developer can focus on the business
logic in the model
MVC web application advantages:
It makes it easier to manage complexity by dividing an application into the model, the view,
and the controller.
It does not use view state or server-based forms. This makes the MVC framework ideal for
developers who want full control over the behavior of an application.
It provides better support for test-driven development (TDD).
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
22/34
FMO – Architecture Design
v1.0
It works well for Web applications that are supported by large teams of developers and for
Web designers who need a high degree of control over the application behavior.
The ASP.NET MVC framework provides the following features:
Separation of application tasks (input logic, business logic, and UI logic), testability, and testdriven development (TDD)
All core contracts in the MVC framework are interface-based and can be tested by using mock
objects, which are simulated objects that imitate the behavior of actual objects in the
application. You can unit-test the application without having to run the controllers in an
ASP.NET process, which makes unit testing fast and flexible. You can use any unit-testing
framework that is compatible with the .NET Framework.
An extensible and pluggable framework
The components of the ASP.NET MVC framework are designed so that they can be easily
replaced or customized. You can plug in your own view engine, URL routing policy, actionmethod parameter serialization, and other components. The ASP.NET MVC framework also
supports the use of Dependency Injection (DI) and Inversion of Control (IOC) container
models. DI enables you to inject objects into a class, instead of relying on the class to create
the object itself. IOC specifies that if an object requires another object, the first objects should
get the second object from an outside source such as a configuration file. This makes testing
easier.
Extensive support for ASP.NET routing, which is a powerful URL-mapping component that lets
you build applications that have comprehensible and searchable URLs
URLs do not have to include file-name extensions, and are designed to support URL naming
patterns that work well for search engine optimization (SEO) and representational state
transfer (REST) addressing.
Support for using the markup in existing ASP.NET page (.aspx files), user control (.ascx files),
and master page (.master files) markup files as view templates. You can use existing ASP.NET
features with the ASP.NET MVC framework, such as nested master pages, in-line expressions
(<%= %>), declarative server controls, templates, data-binding, localization, and so on.
Support for existing ASP.NET features. ASP.NET MVC lets you use features such as forms
authentication and Windows authentication, URL authorization, membership and roles, output
and data caching, session and profile state management, health monitoring, the configuration
system, and the provider architecture.
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
23/34
FMO – Architecture Design
v1.0
8.2 Layer Technology
8.2.1
View
Figure 7: View Layer Technology
The presentation layer (view) will be implemented using HTML 5 which is more lightweight
than flash technology and easy to extend to other PDAs and smart phones. Presentation layer
with HTML 5 is a hybrid of Model-View-Controller (MVC) UI patterns and ASP.NET MVC 3
HTML5 provides mobile device users richer web applications and improved usability. The new
features of HTML5 standardize the use cases and technologies that are common in
smartphone-optimized mobile web applications. In today’s Mobile Web of WML or XHTML-MP
or HTML 4 documents, these features are implemented using proprietary device and browser
APIs. With HTML5, advanced web application features are available in all mobile browsers
supporting the markup language, using the same standard syntax and displaying the same
standard behavior.
8.2.2
Controller
Figure 8: Controller Layer Technology
The controllers will be implemented by C# based on ASP.NET MVC 3 framework which provides
tools and background processing for latest web standards.
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
24/34
FMO – Architecture Design
v1.0
ASP.NET MVC 3 builds on ASP.NET MVC 1 and 2, adding great features that both simplify your
code and allow deeper extensibility. This topic provides an overview of many of the new
features that are included in this release, organized into the following sections:

Extensible Scaffolding with MvcScaffold integration

HTML 5 enabled project templates

The Razor View Engine

Support for Multiple View Engines

Controller Improvements

JavaScript and Ajax

Model Validation Improvements

Dependency Injection Improvements
For detailed description, please refer to the bellowing link: ASP.NET MVC3 Features
8.2.3
Model
The model contains the business objects, with the state and behavior which are pertinent to a
particular business domain. There may be more than one business domain active at any time.
Each business domain is encapsulated in one or more .NET assemblies, which are loaded as
needed by the base executable.
The ECH business model will be defined and described using the Microsoft Entity Data Model
(EDM) which is part of the Microsoft ADO.Net Entity Framework. Entity Framework is intended
to permit the developer of business logic to write queries against the business layer model
rather than the database schema, making business logic more natural and expressive. The
Entity Framework also provides support for query mapping between the business model and
the database schema, allowing business logic to be couched in terms of CLR objects (to the
extent supported by the Entity Data Model,) rather than in terms of database tables, rows and
columns.
The below diagram depicts entity framework acting as model getting data from XML or other
format source data, My Family DB and ECH DB.
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
25/34
FMO – Architecture Design
v1.0
Figure 9: Model Layer Technology
Entity framework is the Microsoft realization of EDM which abstracts the database layer into
models thus helping to eliminate the impedance mismatch between data models and between
languages that application developers would otherwise have to deal with. Two innovations that
make this move possible are Language-Integrated Query and the ADO.NET Entity Framework.
The Entity Framework exists as a new part of the ADO.NET family of technologies. ADO.NET
will LINQ-enable many data access components: LINQ to SQL, LINQ to DataSet and LINQ to
Entities.
For more details on Entity framework, refer to The ADO.NET Entity Framework: Modeling at
the Right Level of Abstraction
8.2.4
Common
Log
Log4Net is chosen for its functionality and performance. The object of log is all system errors
happen during execution of system. Log content will be written to files located in a log folder.
The format of content will be defined more detail in the detailed design document.
Security
In order to make ECH mobile website secure, we will use Role based Security for data
security and SSL for data transportation security. We will need to buy third party certificate for
SSL. SSL can be configured to page level with IIS 7. For Role based Security, data will be
stored in database and each time user signs in, information provided by user will be checked
with his credentials in database.
SSL
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
26/34
FMO – Architecture Design
v1.0
SSL provides one of the most commonly available security mechanisms on the Internet. SSL
stands for Secure Sockets Layer. SSL is used extensively by web browsers to provide secure
connections for transferring credit cards numbers and other sensitive data. An SSL-protected
HTTP transfer uses port 443 (instead of HTTP's normal port 80), and is identified with a special
URL method - https. Thus, https://www.verisign.com/ would cause an SSL-enabled browser to
open a secure SSL session to port 443 at www.verisign.com.
SSL, like most modern security protocols, is based on cryptography. When an SSL session is
established, the server begins by announcing a public key to the client. No encryption is in use
initially, so both parties (and any eavesdropper) can read this key, but the client can now
transmit information to the server in a way that no one else could decode. The client generates
46 bytes of random data, forms them into a single very large number according to PKCS#1,
encrypts them with the server's public key, and sends the result to the server. Only the server,
with its private key, can decode the information to determine the 46 original bytes. This shared
secret is now used to generate a set of conventional RC4 cipher keys to encrypt the rest of the
session.
X.509 certificates are used to authenticate the server, and the client can be authenticated as
well, by presenting a certificate of its own, then computing a hash of all the SSL messages that
have been exchanged up to a certain point, encrypting the result with its private key, and
sending this to the server. The server, which can compute the same hash value, having seen
all the messages as well, can decrypt using the client's public key, which is part of the
certificate, and verify that the two results are the same. Thus the client is authenticated.
Role based Security
.NET Framework role-based security supports authorization by making information about the
principal, which is constructed from an associated identity, available to the current thread. The
identity (and the principal it helps to define) can be either based on a Windows account or be a
custom identity unrelated to a Windows account. .NET Framework applications can make
authorization decisions based on the principal's identity or role membership, or both. A role is a
named set of principles that have the same privileges with respect to security (such as a teller
or a manager). A principal can be a member of one or more roles. Therefore, applications can
use role membership to determine whether a principal is authorized to perform a requested
action.
To provide ease of use and consistency with code access security, .NET Framework role-based
security provides PrincipalPermission objects that enable the common language runtime to
perform authorization in a way that is similar to code access security checks. The
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
27/34
FMO – Architecture Design
v1.0
PrincipalPermission class represents the identity or role that the principal must match and is
compatible with both declarative and imperative security checks. You can also access a
principal's identity information directly and perform role and identity checks in your code when
needed.
The .NET Framework provides role-based security support that is flexible and extensible
enough to meet the needs of a wide spectrum of applications. You can choose to interoperate
with existing authentication infrastructures, such as COM+ 1.0 Services, or to create a custom
authentication system. Role-based security is particularly well-suited for use in ASP.NET Web
applications, which are processed primarily on the server. However, .NET Framework rolebased security can be used on either the client or the server
There are also two classes for Authorization and Authentication which will be shared
across application. The methods in these 2 classes will be specified at detailed design level.
The below diagram depicts sample implementation
Figure 10: Security Class
Processor
The system calls many third parties for data retrieval. For future system extension, there will
be processor class for every processing type. The below diagrams depicts a sample
implementation.
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
28/34
FMO – Architecture Design
v1.0
Figure 11: Processor diagram
Mail
System.Net.Mail (supported by .Net Framework) is used to send the emails in the system via
SMTP protocol.
Validation
This includes classes and methods which are used to validate input data.
Utility
This includes classes and methods which are used in different modules and can be reused, e.g.
mathematic functions, date time functions…
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
29/34
FMO – Architecture Design
9
v1.0
SIZE AND PERFORMANCE
Providing high availability to mission-critical applications, services, and data is a primary
objective of every successful IT system. When services are down or fail, business continuity is
interrupted, which can result in significant losses.
The below diagram depicts the solution how to scale out servers in case of high volume of data
and increased concurrent users by adding Application Servers into the system using network
load balancing (NLB) mechanism of windows server 2008 R2 and also ensures failover for
system high availability by clustering database servers in failover mode. The detailed
mechanism will be further described in 9.1 NLB and 9.2 Failover Clustering
Figure 12: Deployment diagram
9.1 Network Load Balancing (NLB)
Network Load Balancing provides scalability and high availability to enterprise-wide TCP/IP
services, such as Web, Terminal Services, proxy, Virtual Private Networking (VPN), and
streaming media services. Network Load Balancing brings special value to enterprises
deploying TCP/IP services, such as e-commerce applications, that link clients with transaction
applications and back-end databases.
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
30/34
FMO – Architecture Design
v1.0
Network Load Balancing servers (also called hosts) in a cluster communicate among
themselves to provide key benefits, including:
Scalability. Network Load Balancing scales the performance of a server-based program, such
as a Web server, by distributing its client requests across multiple servers within the cluster. As
traffic increases, additional servers can be added to the cluster, with up to 32 servers possible
in any one cluster.
High Availability. Network Load Balancing provides high availability by automatically
detecting the failure of a server and repartitioning client traffic among the remaining servers
within ten seconds, while providing users with continuous service.
Network Load Balancing distributes IP traffic to multiple copies (or instances) of a TCP/IP
service, such as a Web server, each running on a host within the cluster. Network Load
Balancing transparently partitions the client requests among the hosts and lets the clients
access the cluster using one or more "virtual" IP addresses. From the client's point of view, the
cluster appears to be a single server that answers these client requests. As enterprise traffic
increases, network administrators can simply plug another server into the cluster.
Figure 13: Network Load Balancing
9.2 Failover Clustering
Failover clustering provides high-availability support for an entire instance of SQL Server. A
failover cluster is a combination of one or more nodes, or servers, with two or more shared
disks. Applications are each installed into a Microsoft Cluster Service (MSCS) cluster group,
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
31/34
FMO – Architecture Design
v1.0
known as a resource group. At any time, each resource group is owned by only one node in
the cluster. The application service has a virtual name that is independent of the node names,
and is referred to as the failover cluster instance name. An application can connect to the
failover cluster instance by referencing the failover cluster instance name. The application does
not have to know which node hosts the failover cluster instance.
A SQL Server failover cluster instance appears on the network as a single computer, but has
functionality that provides failover from one node to another if the current node becomes
unavailable. For example, during a non-disk hardware failure, operating system failure, or
planned operating system upgrade, you can configure an instance of SQL Server on one node
of a failover cluster to fail over to any other node in the disk group.
A failover cluster does not protect against disk failure. You can use failover clustering to reduce
system downtime and provide higher application availability. Failover clustering is supported in
SQL Server Enterprise and SQL Server Developer, and, with some restrictions, in SQL Server
Standard
9.3 Hardware recommendations for high availability servers
9.3.1
Application server
Component
Minimum requirement
Processor
64-bit, four cores, Intel Itanium 2 processor
RAM
256GB for production use in a single server or multiple server farm
Hard disk
80GB for system drive
9.3.2
Database server
Component
Minimum requirement
Processor
Processor type:
Itanium processor or faster
64-bit, quad cores
Processor speed:
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
32/34
FMO – Architecture Design
v1.0
Minimum: 1.4 GHz
Recommended: 2.0 GHz or faster
RAM
Minimum: 2 GB
Recommended: 4 GB or more
Maximum: 2 TB ( SQL Server Enterprise Edition supports a maximum of 2 TB of
RAM or operating system maximum, whichever is lower).
Hard disk
80 GB for system drive
9.4 Software recommendations for high availability servers
Server Type
Software requirement
Application server
Windows Server 2008 SP2 64-bit x64 Enterprise
IIS 7 or more
.NET framework 4.0
Database server
Windows Server 2008 SP2 64-bit x64 Enterprise
SQL Server 2008 R2 Enterprise (64-bit) x64
10 QUALITY
Quality goals, including the following, are to be determined.
• Performance: refer to 9 Size and Performance
• Security: refer to 8.2 Security
• Availability: refer to 9 Size and Performance
• Usability: refer to 8.2
• Reliability: refer to 9.2
• Extension: refer to 8.2
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
33/34
FMO – Architecture Design
v1.0
• Reusability: refer to 8.2
04ae-BM/PM/HDCV/FSOFT v1/2
Internal use
34/34