FMO Architecture Design v1.0-2
FMO Architecture Design v1.0-2
Architecture Design
RECORD OF CHANGE
SIGNATURE PAGE
Designer
Technical Leader
Quality Assurance
Project Manager
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
5 LOGICAL VIEW........................................................................................................16
6 PROCESS VIEW........................................................................................................17
7 DEPLOYMENT VIEW................................................................................................19
8 IMPLEMENTATION VIEW........................................................................................22
8.2.2 Controller.......................................................................................................................24
8.2.3 Model.............................................................................................................................25
8.2.4 Common........................................................................................................................26
10 QUALITY..................................................................................................................33
1 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 architecture of specific hardware and network infrastructure to be used to support ECH
Mobile Website
Term Definition
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
by_ECH_201101.pdf
iPhone_App_Research_Presentation_ Customer Supplied Vision
by_ECH_20110126.pdf
Mobile_POV_v2_20110208 Customer Supplied Vision
_Presentation_v1_20110328.pdf
ECH_MobileWeb_0727.pdf Customer Supplied Requirement
Specification_v1.0.doc
FMO_Questions and Answers Customer Supplied Requirement
Management Sheet_20110727.xslx
MVC overview http://msdn.microsoft.com/en- Architect
us/library/ff649643.aspx
ASP.Net MVC 3 http://www.asp.net/mvc/mvc3#o Architect
verview
Log4Net features http://logging.apache.org/log4n Architect
et/release/features.html
1.5 Overview
In order to cover all area of the architecture, the SAD contains the following sections:
Architectural Goal and Constraints: describe the architectural constraints of the system.
Use Case View: describe the major use cases of the system.
Process View: describe the main processes of the system and the external system that it
interacts with.
Size and Performance: describe the proposed solution to satisfy the need of a scalable and
high performance system.
2 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.
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.
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.
This section describes the software requirements and objectives that have some significant
impact on the system architecture.
Server side: ECH site will be hosted on IIS web servers and connecting to SQL Server 2008
Database servers.
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:
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
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.
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)
Login
<<system>>
ER Wait Time WS
Create Account
View ER Wait Time
View ER Profile
<<extend>>
Registered User User
<<extend>> <<extend>>
Get Directions
<<system>>
View Profile Google API
Add Profile <<extend>>
<<extend>> <<extend>>
View Visiting ECH View Hospital Profile
<<extend>>
Edit Profile Delete Profile
Figure 2: Use Case Diagram (only major use cases are included)
1. Find Physician
a. Actor: User, Find Physician WS
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.
5 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.
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...).
The diagram below explains how the Model, View and Controller work together in a simple
request flow.
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.
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.
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.
7 DEPLOYMENT VIEW
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 end-
users 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.
Processor Minimum: AMD Opteron, AMD Athlon 64, Intel Xeon with Intel EM64T
support, Intel Pentium IV with EM64T support
Processor speed:
RAM Minimum: 2 GB
Recommended: 4 GB or more
Maximum: 64 GB to 2 TB
Application server Windows 2008 R2 64-bit x64 Standard OR Windows Server 2008 SP2 64-
bit x64 Enterprise
IIS 7 or above
Database server Windows 2008 R2 64-bit x64 Standard OR Windows Server 2008 SP2 64-
bit x64 Enterprise
Note: If Standard Version of Windows Server and SQL Server are used, server scalability and
high availability are not supported.
8 IMPLEMENTATION VIEW
The ECH implementation will be centered around Microsoft technologies, which will include, but
not limited to, the following:
• 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
• Language Integrated Query (LINQ) will be used to compose and execute business layer
queries.
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
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 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.
Separation of application tasks (input logic, business logic, and UI logic), testability, and test-
driven 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.
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, action-
method 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.
8.2.1 View
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
The controllers will be implemented by C# based on ASP.NET MVC 3 framework which provides
tools and background processing for latest web standards.
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:
Controller 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.
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
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.
.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
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 role-
based 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
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.
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…
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
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.
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.
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.
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,
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
RAM 256GB for production use in a single server or multiple server farm
Processor speed:
RAM Minimum: 2 GB
Recommended: 4 GB or more
IIS 7 or more
10 QUALITY