Software Architecture Document

Purpose
This document provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system. It is intended to capture and convey the significant architectural decisions which have been made on the system.

Overview
The divides the system into different views. Each view descripbing one aspect of the system

Logical View
Taken from [1].

Architecturally Significant Design Packages
[For each significants package, include a subsection with its name, its brief description, and a diagram with all significant classes and packages contained within the package.

For each significant class in the package, include its name, brief description, and, optionally a description of some of its major responsibilities, operations and attributes.]

Ruby On Rails
The System uses the open-source off the shelf Ruby-On-Rails web framework as its core architecture for server-side programming. This section describes its components. At the core of Rails is the Model, View, Controller architecture, usually just called MVC. MVC benefits include:


 * Isolation of business logic from the user interface
 * Ease of keeping code "Don't Repeat Yourself"
 * Making it clear where different types of code belong for easier maintenance

Models
A model represents the information (data) of the application and the rules to manipulate that data. In the case of Rails, models are primarily used for managing the rules of interaction with a corresponding database table. In most cases, each table in your database will correspond to one model in your application. The bulk of your application’s business logic will be concentrated in the models.

Views
Views represent the user interface of your application. In Rails, views are often HTML files with embedded Ruby code that perform tasks related solely to the presentation of the data. Views handle the job of providing data to the web browser or other tool that is used to make requests from your application.

Controllers
Controllers provide the “glue” between models and views. In Rails, controllers are responsible for processing the incoming requests from the web browser, interrogating the models for data, and passing that data on to the views for presentation.

The Components of Rails
Rails ships as many individual components. Each of these components are briefly explained below.


 * Action Pack
 * Action Controller
 * Action Dispatch
 * Action View
 * Action Mailer
 * Active Model
 * Active Record
 * Active Resource
 * Active Support
 * Railties

Action Pack
Action Pack is a single gem that contains Action Controller, Action View and Action Dispatch. The “VC” part of “MVC ”.

Action Controller
Action Controller is the component that manages the controllers in a Rails application. The Action Controller framework processes incoming requests to a Rails application, extracts parameters, and dispatches them to the intended action. Services provided by Action Controller include session management, template rendering, and redirect management.

Action View
Action View manages the views of your Rails application. It can create both HTML and XML output by default. Action View manages rendering templates, including nested and partial templates, and includes built-in AJAX support. View templates are covered in more detail in another guide called Layouts and Rendering.

Action Dispatch
<p style="margin-top: 0px; margin-bottom: 1.5em; border-style: initial; border-color: initial; outline-width: 0px; outline-style: initial; outline-color: initial; font-size: 14px; background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; color: rgb(51, 51, 51); font-style: normal; text-align: left;">Action Dispatch handles routing of web requests and dispatches them as you want, either to your application or any other Rack application.

Action Mailer
<p style="margin-top: 0px; margin-bottom: 1.5em; border-style: initial; border-color: initial; outline-width: 0px; outline-style: initial; outline-color: initial; font-size: 14px; background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; color: rgb(51, 51, 51); font-style: normal; text-align: left;">Action Mailer is a framework for building e-mail services. You can use Action Mailer to receive and process incoming email and send simple plain text or complex multipart emails based on flexible templates.

Active Model
<p style="margin-top: 0px; margin-bottom: 1.5em; border-style: initial; border-color: initial; outline-width: 0px; outline-style: initial; outline-color: initial; font-size: 14px; background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; color: rgb(51, 51, 51); font-style: normal; text-align: left;">Active Model provides a defined interface between the Action Pack gem services and Object Relationship Mapping gems such as Active Record. Active Model allows Rails to utilize other <span class="caps" style="border-style: initial; border-color: initial; outline-width: 0px; outline-style: initial; outline-color: initial; background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: transparent; ">ORM frameworks in place of Active Record if your application needs this.

Active Record
<p style="margin-top: 0px; margin-bottom: 1.5em; border-style: initial; border-color: initial; outline-width: 0px; outline-style: initial; outline-color: initial; font-size: 14px; background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; color: rgb(51, 51, 51); font-style: normal; text-align: left;">Active Record is the base for the models in a Rails application. It provides database independence, basic <span class="caps" style="border-style: initial; border-color: initial; outline-width: 0px; outline-style: initial; outline-color: initial; background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: transparent; ">CRUD functionality, advanced finding capabilities, and the ability to relate models to one another, among other services.

Active Resource
<p style="margin-top: 0px; margin-bottom: 1.5em; border-style: initial; border-color: initial; outline-width: 0px; outline-style: initial; outline-color: initial; font-size: 14px; background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; color: rgb(51, 51, 51); font-style: normal; text-align: left;">Active Resource provides a framework for managing the connection between business objects and RESTful web services. It implements a way to map web-based resources to local objects with<span class="caps" style="border-style: initial; border-color: initial; outline-width: 0px; outline-style: initial; outline-color: initial; background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: transparent; ">CRUD semantics.

Active Support
<p style="margin-top: 0px; margin-bottom: 1.5em; border-style: initial; border-color: initial; outline-width: 0px; outline-style: initial; outline-color: initial; font-size: 14px; background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; color: rgb(51, 51, 51); font-style: normal; text-align: left;">Active Support is an extensive collection of utility classes and standard Ruby library extensions that are used in Rails, both by the core code and by your applications.

Railties
<p style="margin-top: 0px; margin-bottom: 1.5em; border-style: initial; border-color: initial; outline-width: 0px; outline-style: initial; outline-color: initial; font-size: 14px; background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; color: rgb(51, 51, 51); font-style: normal; text-align: left;">Railties is the core Rails code that builds new Rails applications and glues the various frameworks and plugins together in any Rails application.

Process View
This section describes the system's decomposition into processes (single threads of control) and heavyweight processes (groupings of lightweight processes).

Apache Multitasking Architecture
<p style="border-style: initial; border-color: initial; font-style: normal; margin-top: 1em; margin-bottom: 1em;">As part of the Apache webserver's functionnalities. Concurrency issues in the system can be resolved through multi-tasking + mutli-threading. This section describes the Apache Web Server "default" multitasking architecture : the preforked Apache Mutli Process Module (MPM). All the architecture information were taken from [2]

All Apache Multitasking Architectures are based on a task pool architecture. At start-up, Apache creates a number of tasks (processes and/or threads), most of them are idle. A request will be processed by an idle task, therefore there's no need to create a task for request processing.

Another common component is the master server, a task controlling the task pool -- either control the number of idle tasks or just restart the server something goes wrong. The master server also offers the control interface for the administrator.

In the following, the preforking architecture will be presented as the first and most important architecture for unix systems. The Leader Followers Pattern The preforking architecture is based on a pool of tasks (processes or threads) which are playing 3 different roles:


 * wait for requests (listener)
 * process a request (worker)
 * queue in and wait to become the listener (idle worker)



<span style="color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style: normal; line-height: normal; text-align: -webkit-center; font-size: medium; ">The leader-followers pattern used in the preforking server architecture  The figure shows the structure of the system: The listener is the leader. Only one task can be granted the right to wait for connection requests. If the listener gets a request, it hands over the right to listen and switches his role to worker, that means he processes the request using the connection he established as listener. If he's finished processing the request, he closes the connection and becomes an idle worker. That means he queues in waiting to become the listener. Usually an idle worker task will be suspended. An incoming request will be treated immediately by the listener task -- no new task has to be created. On the other hand there should always be a certain number of idle worker tasks to make sure there is always a listener. There is no need to pass information about a request to another task because the listener just switches his role and keeps the information. The task pool must be created at server start. The number of tasks in the pool should be big enough to ensure quick server response, but a machine has resource restriction. The solution is to control the number of tasks in the pool by another agent: the master server.

Preforking Architecture
The Preforking architecture was the first multitasking architecture of Apache. In Apache 2.0 it is still the default MPM for Unix. Summarizingly the Preforking architecture of Apache takes a conventional Approach as each child server is a process by itself. That makes Preforking a stable architecture but also reduces performance.

<p style="text-align: center;"><span style="color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style: normal; line-height: normal; text-align: -webkit-center; font-size: medium; ">The Apache 2.0 Preforking MPM The structure diagram in the figure shows the structure of the Preforking architecture of Apache 2.0 and is important for the description of the behavior of Apache. You can see which component is able to communicate with which other component and which storage a component can read or modify. There is one master server and multiple child servers. The child server processes exists before a request comes in. As the master server uses the fork system call to create processes and does this before the first request comes in, it is called a preforking server. The master server doesn't wait for incoming requests at all -- the existing child servers wait and then handle the request directly. The master server creates a set of idle child server processes, which register with the TCP/IP communication service to get the next request. The first child server getting a connection handles the request, sends the response and waits for the next request. The master server adjusts the number of idle child server processes within given bounds.

General Behavior
The following figure shows the overall behavior of the server, including the master server and the child servers.

<p style="text-align: center;"><span style="color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style: normal; line-height: normal; font-size: medium; ">Behavior of Apache

Independently from the underlying multitasking architecture, Apache's behaviour consists of a sequence of the following parts which will be discussed individually for each of the architectures:

Allocate resources, read and check configuration, become a daemon. (Re-)read configuration, create task pool by starting child server processes and enter the master server loop. Control the number of idle child server processes in the task pool. Wait to become leader, wait for a connection request, become worker and enter the keep-alive-loop. Process HTTP requests As each multitasking architecture distinguishes itself from others by using different means to create and organize child servers, the behaviour of different multitasking architectures mainly differs when child servers, also called workers are created during the restart loop and within the master server loop when the workers are monitored and replaced.
 * First-time initialization:
 * The restart loop:
 * The master server loop:
 * The request-response loop (Child server only):
 * The keep-alive-loop (Child server only):
 * Clean-up before deactivation (Master server and Child servers)

Deployment View
This section describes one physical network configurations on which the software is deployed and run. It is a view of the Deployment Model.


 * Apache 2.x Web Server
 * Ruby 1.9.x Software Pack
 * MySQL 5.x Database :
 * Web Browser

Data View (optional)
A description of the persistent data storage perspective of the system.

taken from [3] and [4].

Definition
RDBMS stands for Relational Database Management System. RDBMS is the basis for SQL, and for all modern database systems like MS SQL Server, IBM DB2, Oracle, MySQL, and Microsoft Access. A Relational database management system (RDBMS) is a database management system (DBMS) that is based on the relational model as introduced by E. F. Codd.

What is a table ?
The data in RDBMS is stored in database objects called tables. The table is a collection of related data entries and it consists of columns and rows. A table is the most common and simplest form of data storage in a relational database.

What is a field ?
Every table is broken up into smaller entities called fields. A field is a column in a table that is designed to maintain specific information about every record in the table.

What is record, or row?
A record, also called a row of data, is each individual entry that exists in a table. A record is a horizontal entity in a table.

What is column?
A column is a vertical entity in a table that contains all information associated with a specific field in a table.

What is NULL value?
A NULL value in a table is a value in a field that appears to be blank which means A field with a NULL value is a field with no value. It is very important to understand that a NULL value is different than a zero value or a field that contains spaces. A field with a NULL value is one that has been left blank during record creation.

Database Transactions
As the Apache architecture supports concurrency, consistency issues may arise. In order to tackle this problem, the System will make the use of Database transactions. This section describes the SQL transaction system A transaction is a unit of work that is performed against a database. Transactions are units or sequences of work accomplished in a logical order, whether in a manual fashion by a user or automatically by some sort of a database program. A transaction is the propagation of one or more changes to the database. For example, if you are creating a record or updating a record or deleting a record from the table then you are performing transaction on the table. It is important to control transactions to ensure data integrity and to handle database errors. Practically you will club many SQL queries into a group and you will execute all of them together as a part of a transaction.

Properties of Transactions:
Transactions have the following four standard properties, usually referred to by the acronym ACID:


 * Atomicity: ensures that all operations within the work unit are completed successfully; otherwise, the transaction is aborted at the point of failure, and previous operations are rolled back to their former state.
 * Consistency: ensures that the database properly changes states upon a successfully committed transaction.
 * Isolation: enables transactions to operate independently of and transparent to each other.
 * Durability: ensures that the result or effect of a committed transaction persists in case of a system failure.

Transaction Control:
There are following commands used to control transactions:

Transactional control commands are only used with the DML commands INSERT, UPDATE, and DELETE only. They can not be used while creating tables or dropping them because these operations are automatically commited in the database. COMMIT
 * 1) <p style="text-align: justify;">COMMIT: to save the changes.
 * 2) <p style="text-align: justify;">ROLLBACK: to rollback the changes.
 * 3) <p style="text-align: justify;">SAVEPOINT: creates points within groups of transactions in which to ROLLBACK
 * 4) <p style="text-align: justify;">SET TRANSACTION: Places a name on a transaction.

The COMMIT command is the transactional command used to save changes invoked by a transaction to the database. The COMMIT command saves all transactions to the database since the last COMMIT or ROLLBACK command. ROLLBACK The ROLLBACK command is the transactional command used to undo transactions that have not already been saved to the database. The ROLLBACK command can only be used to undo transactions.