These layers are described below.

1. Application layer or Business layer

2. Business layer
    a. Property layer(Sub layer of business layer)
3. data layer

Advantages of three Tier Architecture.

The main characteristic of a Host Architecture is that the application and databases reside on
the same host computer and the user interacts with the host using an unfriendly and dump
terminal. This architecture does not support distributed computing (the host applications are
not able to connect a database of a strategically allied partner). Some managers found that
developing a host application take too long and it is expensive. Consequently led these
disadvantages to Client-Server architecture.

Client-Server architecture is 2-Tier architecture because the client does not distinguish
between Presentation layer and business layer. The increasing demands on GUI controls
caused difficulty to manage the mixture of source code from GUI and Business Logic
(Spaghetti Code). Further, Client Server Architecture does not support enough the Change
Management. Let suppose that the government increases the Entertainment tax rate from
4% to 8 %, then in the Client-Server case, we have to send an update to each clients and they
must update synchronously on a specific time otherwise we may store invalid or wrong
information. The Client-Server Architecture is also a burden to network traffic and resources.
Let us assume that about five hundred clients are working on a data server then we will have
five hundred ODBC connections and several ruffian record sets, which must be transported
from the server to the clients (because the Business layer is stayed in the client side). The
fact that Client-Server does not have any caching facilities like in ASP.NET, caused additional
traffic in the network. Normally, a server has a better hardware than client therefore it is
able compute algorithms faster than a client, so this fact is also an additional pro argument
for the 3.Tier Architecture. This categorization of the application makes the function more
reusable easily and it becomes too easy to find the functions which have been written
previously. If programmer wants to make further update in the application then he easily
can understand the previous written code and can update easily.

Application layer or Presentation layer

Application layer is the form which provides the user interface to either programmer of end
user. Programmer uses this layer for designing purpose and to get or set the data back and
forth.

Business layer

This layer is a class which we use to write the function which works as a mediator to transfer
the data from Application or presentation layer data layer. In the three tier architecture we
never let the data access layer to interact with the presentation layer.
a. Property Layer

This layer is also a class where we declare the variable corresponding to the fields of the
database which can be required for the application and make the properties so that we can
get or set the data using these properties into the variables. These properties are public so
that we can access its values.

Data Access Layer

This layer is also a class which we use to get or set the data to the database back and forth.
This layer only interacts with the database. We write the database queries or use stored
procedures to access the data from the database or to perform any operation to the
database.

Summary

o Application layer is the form where we design using the controls like textbox, labels,
command buttons etc.
o Business layer is the class where we write the functions which get the data from the
application layer and passes through the data access layer.
o Data layer is also the class which gets the data from the business layer and sends it to
the database or gets the data from the database and sends it to the business layer.
o Property layer is the sub layer of the business layer in which we make the properties
to sent or get the values from the application layer. These properties help to sustain
the value in a object so that we can get these values till the object destroy
In the beginning, there were mainframes. Every program and piece of data was stored in a
single almighty machine. Users could access this centralized computer only by means of
dumb terminals. (See Figure 1.)

Figure 1. Mainframe Architecture

In the 1980s, the arrival of inexpensive network-connected PCs produced the popular two-
tier client-server architecture. In this architecture, there is an application running in the
client machine which interacts with the server—most commonly, a database management
system (see Figure 2). Typically, the client application, also known as a fat client, contained
some or all of the presentation logic (user interface), the application navigation, the business
rules and the database access. Every time the business rules were modified, the client
application had to be changed, tested and redistributed, even when the user interface
remained intact. In order to minimize the impact of business logic alteration within client
applications, the presentation logic must be separated from the business rules. This
separation becomes the fundamental principle in the three-tier architecture.
Figure 2. Two-Tier Client-Server Architecture

In a three-tier architecture (also known as a multi-tier architecture), there are three or more
interacting tiers, each with its own specific responsibilities (see Figure 3):

Figure 3. Three-Tier Architecture

 Tier 1: the client contains the presentation logic, including simple control and user
input validation. This application is also known as a thin client.
 Tier 2: the middle tier is also known as the application server, which provides the
business processes logic and the data access.
 Tier 3: the data server provides the business data.
These are some of the advantages of a three-tier architecture:

 It is easier to modify or replace any tier without affecting the other tiers.
 Separating the application and database functionality means better load balancing.
 Adequate security policies can be enforced within the server tiers without hindering
the clients.

Putting the Theory into Practice

In order to demonstrate these design concepts, the general outline of a simple three-tier
“Hangman” game will be presented (check the source code in the archive file). The purpose
of this game, just in case the reader isn't familiar with it, is to try to guess a mystery word,
one letter at a time, before making a certain number of mistakes.

Figure 4. Hangman Client Running in Windows 98

The data server is a Linux box running the MiniSQL database management system. The
database is used to store the mystery words. At the beginning of each game, one of these
words is randomly selected.

At the client side, a Java applet contained in a web page (originally obtained from a web
server) is responsible for the application's graphical user interface (see Figure 4). The client
platform may be any computer with a web browser that supports applets. The game's logic
is not controlled by the applet; that's the middle tier's job. The client only takes care of the
presentation logic: getting the user's input, performing some simple checking and drawing
the resulting output.
The server in the middle tier is a Java application, also running within a Linux box. The rules
of the “Hangman” game (the business rules) are coded in this tier. Sockets and JDBC,
respectively, are used to communicate with the client and the data server through TCP/IP.

Figure 5. Diagram of Hardware Nodes

Figure 5 presents a UML (Unified Modeling Language) deployment diagram that shows the
physical relationship among the hardware nodes of the system.

Even though the design described gives the impression of requiring a different machine for
each tier, all tiers (each one running on a different process) can be run in the same
computer. This means the complete application is able to run in a single Linux system with a
graphical desktop, and it doesn't even have to be connected to the Net!

Conclusions

The three-tier architecture is a versatile and modular infrastructure intended to improve

usability, flexibility, interoperability and scalability. Linux, Java and MiniSQL result in an
interesting combination for learning how to build three-tier architecture systems.
Nevertheless, more convenient implementations than the one presented here may be
produced using component technology in the middle tier, such as CORBA (Common Object
Request Broker Architecture), EJB (Enterprise Java Beans) and DCOM (Distributed
Component Object Model). The interested reader should review these topics to get a better
understanding of the current three-tier architecture capabilities.
Client–server model

The client–server model of computing is a distributed application structure that partitions

tasks or workloads between the providers of a resource or service, called servers, and
service requesters, called clients.[1] Often clients and servers communicate over a computer
network on separate hardware, but both client and server may reside in the same system. A
server machine is a host that is running one or more server programs which share their
resources with clients. A client does not share any of its resources, but requests a server's
content or service function. Clients therefore initiate communication sessions with servers
which await (listen for) incoming requests.

Description

The client–server characteristic describes the relationship of cooperating programs in an

application. The server component provides a function or service to one or many clients,
which initiate requests for such services.

Functions such as email exchange, web access and database access, are built on the client–
server model. For example, a web browser is a client program running on a user's computer
that may access information stored on a web server on the Internet. Users accessing banking
services from their computer use a web browser client to send a request to a web server at a
bank. That program may in turn forward the request to its own database client program that
sends a request to a database server at another bank computer to retrieve the account
information. The balance is returned to the bank database client, which in turn serves it back
to the web browser client displaying the results to the user. The client–server model has
become one of the central ideas of network computing. Many business applications being
written today use the client–server model. So do the Internet's main application protocols,
such as HTTP, SMTP, Telnet, and DNS. In marketing, the term has been used to distinguish
distributed computing by smaller dispersed computers from the "monolithic" centralized
computing of mainframe computers. But this distinction has largely disappeared as
mainframes and their applications have also turned to the client–server model and become
part of network computing.

Each instance of the client software can send data requests to one or more connected
servers. In turn, the servers can accept these requests, process them, and return the
requested information to the client. Although this concept can be applied for a variety of
reasons to many different kinds of applications, the architecture remains fundamentally the
same.

The most basic type of client–server architecture employs only two types of hosts: clients
and servers. This type of architecture is sometimes referred to as two-tier. It allows devices
to share files and resources. The two tier architecture means that the client acts as one tier
and application in combination with server acts as another tier. The Internet increasingly
uses a three-tier architecture. In this the server side consists of an Application Server (such
as Web Server) and a Database Server (such as a SQL Server). Thus the three tiers become -
Client, Application Server and Database. All three tiers are relatively independent; for
example you can switch to a different Web Server while maintaining the integrity of the
model.

The interaction between client and server is often described using sequence diagrams.
Sequence diagrams are standardized in the Unified Modeling Language.

Specific types of clients include web browsers, email clients, and online chat clients.

Specific types of servers include web servers, ftp servers, application servers, database
servers, name servers, mail servers, file servers, print servers, and terminal servers. Most
web services are also types of servers.

Comparison to peer-to-peer architecture

in peer-to-peer architectures, each host or instance of the program can simultaneously act
as both a client and a server, and each has equivalent responsibilities and status.

Both client–server and peer-to-peer architectures are in wide usage today. Details may be
found in Comparison of Centralized (Client-Server) and Decentralized (Peer-to-Peer)
Networking.

Advantages

 In most cases, a client–server architecture enables the roles and responsibilities of a

computing system to be distributed among several independent computers that are
known to each other only through a network. This creates an additional advantage to
this architecture: greater ease of maintenance. For example, it is possible to replace,
repair, upgrade, or even relocate a server while its clients remain both unaware and
unaffected by that change.
 All data is stored on the servers, which generally have far greater security controls
than most clients.[citation needed] Servers can better control access and resources, to
guarantee that only those clients with the appropriate permissions may access and
change data.
 Since data storage is centralized, updates to that data are far easier to administer in
comparison to a P2P paradigm. In the latter, data updates may need to be distributed
and applied to each peer in the network, which is both time-consuming and error-
prone,[citation needed] as there can be thousands or even millions of peers.
 Many mature client–server technologies are already available which were designed
to ensure security, friendliness of the user interface, and ease of use. [citation needed]
 It functions with multiple different clients of different capabilities.
Disadvantages

 As the number of simultaneous client requests to a given server increases, the server
can become overloaded.[citation needed] Contrast that to a P2P network, where its
aggregated bandwidth actually increases as nodes are added, since the P2P
network's overall bandwidth can be roughly computed as the sum of the bandwidths
of every node in that network.
 The client–server paradigm lacks the robustness of a good P2P network. [citation needed]
Under client–server, should a critical server fail, clients’ requests cannot be fulfilled.
In P2P networks, resources are usually distributed among many nodes. Even if one or
more nodes depart and abandon a downloading file, for example, the remaining
nodes should still have the data needed to complete the download.
Multitier architecture

In software engineering, multi-tier architecture (often referred to as n-tier architecture) is a

client–server architecture in which the presentation, the application processing, and the
data management are logically separate processes. For example, an application that uses
middleware to service data requests between a user and a database employs multi-tier
architecture. The most widespread use of multi-tier architecture is the three-tier
architecture.

N-tier application architecture provides a model for developers to create a flexible and
reusable application. By breaking up an application into tiers, developers only have to
modify or add a specific layer, rather than have to rewrite the entire application over. There
should be a presentation tier, a business or data access tier, and a data tier.

The concepts of layer and tier are often used interchangeably. However, one fairly common
point of view is that there is indeed a difference, and that a layer is a logical structuring
mechanism for the elements that make up the software solution, while a tier is a physical
structuring mechanism for the system infrastructure.

Three-tier architecture

Visual overview of a Three-tiered application

Three-tier[2] is a client–server architecture in which the user interface, functional process

logic ("business rules"), computer data storage and data access are developed and
maintained as independent modules, most often on separate platforms. It was developed by
John J. Donovan in Open Environment Corporation (OEC), a tools company he founded in
Cambridge, MA.

The three-tier model is a software architecture and a software design pattern.

Apart from the usual advantages of modular software with well-defined interfaces, the
three-tier architecture is intended to allow any of the three tiers to be upgraded or replaced
independently as requirements or technology change. For example, a change of operating
system in the presentation tier would only affect the user interface code.

Typically, the user interface runs on a desktop PC or workstation and uses a standard
graphical user interface, functional process logic may consist of one or more separate
modules running on a workstation or application server, and an RDBMS on a database server
or mainframe contains the computer data storage logic. The middle tier may be multi-tiered
itself (in which case the overall architecture is called an "n-tier architecture").

Three-tier architecture has the following three tiers:

Presentation tier

This is the topmost level of the application. The presentation tier displays information
related to such services as browsing merchandise, purchasing, and shopping cart
contents. It communicates with other tiers by outputting results to the
browser/client tier and all other tiers in the network.

Application tier (business logic, logic tier, data access tier, or middle tier)

The logic tier is pulled out from the presentation tier and, as its own layer, it controls
an application’s functionality by performing detailed processing.

Data tier

This tier consists of database servers. Here information is stored and retrieved. This
tier keeps data neutral and independent from application servers or business logic.
Giving data its own tier also improves scalability and performance.

Comparison with the MVC architecture

At first glance, the three tiers may seem similar to the model-view-controller (MVC) concept;
however, topologically they are different. A fundamental rule in a three tier architecture is
the client tier never communicates directly with the data tier; in a three-tier model all
communication must pass through the middleware tier. Conceptually the three-tier
architecture is linear. However, the MVC architecture is triangular: the view sends updates
to the controller, the controller updates the model, and the view gets updated directly from
the model.

From a historical perspective the three-tier architecture concept emerged in the 1990s from
observations of distributed systems (e.g., web applications) where the client, middleware
and data tiers ran on physically separate platforms. Whereas MVC comes from the previous
decade (by work at Xerox PARC in the late 1970s and early 1980s) and is based on
observations of applications that ran on a single graphical workstation; MVC was applied to
distributed applications much later in its history (see Model 2).

Web development usage

In the web development field, three-tier is often used to refer to websites, commonly
electronic commerce websites, which are built using three tiers:

1. A front-end web server serving static content, and potentially some are cached
dynamic content. In web based application, Front End is the content rendered by the
browser. The content may be static or generated dynamically.
2. A middle dynamic content processing and generation level application server, for
example Java EE, ASP.NET, PHP platform.
3. A back-end database, comprising both data sets and the database management
system or RDBMS software that manages and provides access to the data.

Other considerations

Data transfer between tiers is part of the architecture. Protocols involved may include one or
more of SNMP, CORBA, Java RMI, .NET Remoting, Windows Communication Foundation,
sockets, UDP, web services or other standard or proprietary protocols. Often middleware is
used to connect the separate tiers. Separate tiers often (but not necessarily) run on separate
physical servers, and each tier may itself run on a cluster.

Traceability

The end-to-end traceability of data flows through n-tier systems is a challenging task which
becomes more important when systems increase in complexity. The Application Response
Measurement defines concepts and APIs for measuring performance and correlating
transactions between tiers.
Model–View–Controller

Model–View–Controller (MVC) is a software architecture,[1] currently considered an

architectural pattern used in software engineering. The pattern isolates "domain logic" (the
application logic for the user) from input and presentation (UI), permitting independent
development, testing and maintenance of each.

The model is used to manage information and notify observers when that information
changes. The model is the domain-specific representation of the data upon which the
application operates. Domain logic adds meaning to raw data (for example, calculating
whether today is the user's birthday, or the totals, taxes, and shipping charges for shopping
cart items). When a model changes its state, it notifies its associated views so they can be
refreshed.

Many applications use a persistent storage mechanism such as a database to store data.
MVC does not specifically mention the data access layer because it is understood to be
underneath or encapsulated by the model. Models are not data access objects; however, in
very simple apps that have little domain logic there is no real distinction to be made. Active
Record is an accepted design pattern which merges domain logic and data access code - a
model which knows how to persist itself.

The view renders the model into a form suitable for interaction, typically a user interface
element. Multiple views can exist for a single model for different purposes. A viewport
typically has a one to one correspondence with a display surface and knows how to render
to it.

The controller receives input and initiates a response by making calls on model objects. A
controller accepts input from the user and instructs the model and viewport to perform
actions based on that input.

An MVC application may be a collection of model/view/controller triads, each responsible

for a different UI element.

MVC is often seen in web applications where the view is the HTML or XHTML generated by
the app. The controller receives GET or POST input and decides what to do with it, handing
over to domain objects (i.e. the model) that contain the business rules and know how to
carry out specific tasks such as processing a new subscription.
History

MVC was first described in 1979[2] by Trygve Reenskaug, then working on Smalltalk at Xerox
PARC. The original implementation is described in depth in the influential paper
"Applications Programming in Smalltalk-80: How to use Model–View–Controller". [3]

There have been several derivatives of MVC. For example, Model View Presenter is used
with the .NET Framework[4], and the XForms standard uses a "model-view-controller-
connector architecture"[5]. However, standard MVC remains popular.[citation needed]

Overview

Though MVC comes in different flavors, control flow is generally as follows:

1. The user interacts with the user interface in some way (for example, presses a mouse
button).
2. The controller handles the input event from the user interface, often via a registered
handler or callback and converts the event into appropriate user action,
understandable for the model.
3. The controller notifies the model of the user action, possibly resulting in a change in
the model's state. (For example, the controller updates the user's shopping cart.)[6]
4. A view queries the model in order to generate an appropriate user interface (for
example, the view lists the shopping cart's contents). The view gets its own data from
the model. In some implementations, the controller may issue a general instruction
to the view to render itself. In others, the view is automatically notified by the model
of changes in state (Observer) which require a screen update.
5. The user interface waits for further user interactions, which restarts the cycle.

Some implementations such as the W3C XForms also use the concept of a dependency graph
to automate the updating of views when data in the model changes.

The goal of MVC is, by decoupling models and views, to reduce the complexity in
architectural design and to increase flexibility and maintainability of code.

Selected frameworks

GUI frameworks

VCL, CLX, Cocoa, CocoaTouch

Controllers.

The controller is represented by the visual forms created either in the form designer
or via code.
Combined frameworks

Java: Java Platform, Enterprise Edition (Java EE)

Simple Version implementing Java Servlets and JavaServer Pages from Java EE:

Model

The model is a collection of Java classes that form a software application intended to
store, and optionally separate, data. A single front end class that can communicate
with any user interface (for example: a console, a graphical user interface, or a web
application).

View

The view is represented by a JavaServer Page, with data being transported to the
page in the HttpServletRequest or HttpSession.

Controller

The Controller servlet communicates with the front end of the model and loads the
HttpServletRequest or HttpSession with appropriate data, before forwarding the
HttpServletRequest and Response to the JSP using a RequestDispatcher.

The Servlet is a Java class, and it communicates and interacts with the model but does not
need to generate HTML or XHTML output; the JSPs do not have to communicate with the
model because the Servlet provides them with the information—they can concentrate on
creating output.

Unlike the other frameworks, Java EE defines a pattern for model objects.

Model

The model is commonly represented by entity beans, although the model can be
created by a servlet using a business object framework such as Spring.

View

The view in a Java EE application may be represented by a Pages|JavaServer Page]],

which may be currently implemented using a web framework, such as Adobe Flex,
Struts 2, or JavaServer Faces (JSF). Alternatively, the code to generate the view may
be part of a servlet.

Controller

The controller in a Java EE application may be represented by a servlet, which may be

currently implemented using JavaServer Faces (JSF).
XForms

XForms is an XML format for the specification of a data processing model for XML data and
user interface(s) for the XML data, such as web forms.

Model

XForms stores the Model as XML elements in the browser. They are usually placed in the
non-visible <head> elements of a web page.

View

The Views are XForms controls for screen elements and can be placed directly in the visible
section of web page. They are usually placed in the <body> elements of a web page.

The model and views are bound together using reference or binding statements. These
binding statements are used by the XForms dependency graph to ensure that the correct
views are updated when data in the model changes. This means that forms developers do
not need to be able to understand either the push or pull models of event processing.

Controller

All mouse events are processed by XForms controls and XML events are dispatched.

Implementations of MVC as GUI frameworks

Smalltalk's MVC implementation inspired many other GUI frameworks, such as the
following:

 XPages - for IBM Lotus Notes/Domino

 Cocoa framework and its GUI part AppKit, as a direct descendant of OpenStep,
encourage the use of MVC. Interface Builder constructs Views, and connects them to
Controllers via Outlets and Actions.
 GNUstep, also based on OpenStep, encourages MVC as well.
 GTK+ provides models (as both interfaces and as concrete implementations) and
views, while clients implement the controllers through signals.
 JFace.
 Microsoft Foundation Class Library (MFC) - called the Document/View architecture
 Microsoft Composite UI Application Block, part of the Microsoft Enterprise Library.
 Qt since Qt4 release.
 Java Swing.
 Adobe Flex.
 Wavemaker open source, browser-based development tool based on MVC.
 Windows Presentation Foundation (WPF) uses a similar Model–view–viewmodel
pattern.
 Visual FoxExpress is a Visual FoxPro MVC framework.
Implementations of MVC as web-based frameworks

In the design of web applications, MVC is implemented by web template systems as a "View
for web" component.

MVC is typically implemented as a "Model 2" architecture in Sun parlance. Model 2 focuses
on efficiently handling and dispatching full page form posts and reconstructing the full page
via a front controller. Complex web applications continue to be more difficult to design than
traditional applications because of this "full page" effect. More recently "View for web" AJAX
driven frameworks that focus on firing focused UI events at specific UI Components on the
page are emerging. This is causing MVC to be revisited for web application development
using traditional desktop programming techniques.[citation needed]

ABAP Objects

 Business Server Pages (BSP)

 Web Dynpro ABAP

Actionscript

 PureMVC Framework for Actionscript.

ASP

 ASP Xtreme Evolution (AXE)

 CodeCharge Studio

C++

 Wt - Web toolkit A library and application server for web applications using a
desktop-like event-driven MVC pattern.
 CppCMS - It is C++ MVC framework that had taken many ideas from Django.

CFML - Adobe ColdFusion, Railo, and Open BlueDragon

 ColdFusion on Wheels A convention over configuration framework similar to Ruby on

Rails.
 Framework One Framework/1 is a new framework developed by Sean Corfield and
provides a good stepping stone for users new to the MVC pattern. It consists of a
single CFC and favors convention over configuration.
 Fusebox Fusebox does not force the Model–View–Controller (MVC) pattern or
Object-Oriented Programming (OOP) on the developer. However, either or both of
these development approaches can be used with Fusebox.
  Mach-II A framework that focuses on trying to ease software development and
maintenance.
 Model-Glue Through a simple implementation of Implicit Invocation and Model–
View–Controller, they allow applications to be well organized without sacrificing
flexibility.
 PureMVC Framework for ColdFusion.

Delphi

 Delphi On Rails

Erlang

 Chicago Boss
 Erlang Web

Flex

 Cairngorm one of the primary open source frameworks for application architecture in
Adobe Flex.
 PureMVC ActionScript 3 MVC framework for Flex, Flash and AIR development.

Groovy

 Grails

Java

MVC web application frameworks:

 Aranea
 Cocoon
 CodeCharge Studio
 Induction
 JSF
 Makumba Web development framework in the form of JSP Tag Library and Java API
that is based on MVC, but willingly breaks it
 Oracle Application Framework
 Play Framework
 PureMVC, a framework for Java
 Sling, used to create content based applications on top of JCR. Supported scripting
languages are JSP, server-side JavaScript, Ruby, Velocity
 Spring MVC Framework
 Struts
 Struts2
 Stripes
  Tapestry
 Wavemaker, a WYSIWYG development platform for Ajax web applications.[7]
 WebObjects
 WebWork
 Wicket
 Web Dynpro Java

Java Stand-alone Application Toolkit:

 Swing, which uses a Model-Delegator pattern, where the view and controller are
combined, but the model is separate.

JavaScript

MVC web application frameworks:

 SproutCore
 PureMVC Framework for JavaScript
 JavascriptMVC Javascript MVC framework based upon jQuery core.[8]
 eMVC is an MVC framework based upon Dojo Toolkit.

Informix 4GL

 IBM Informix-4GL MVC models to use for Informix 4GL report and form creation
 EGL — IBM's EGL MVC Implementation

Lasso

http://code.google.com/p/engineroom/ engineRoom is an MVC-like framework

Lua

 Orbit

.NET

 ASP.NET MVC Framework

 Bistro Framework
 CodeCharge Studio
 Maverick.NET
 MonoRail An ActionPack inspired MVC framework from the Castle Project
 Naked Objects MVC
 PureMVC Framework for C#
 Spring Framework.NET
Perl

 Catalyst - Mature, stable and fast MVC framework inspired by Ruby on Rails.
 CodeCharge Studio
 Maypole - An MVC Web framework, superseded by Catalyst.
 Mojolicious - A next generation web framework inspired by Catalyst.

PHP

 Agavi A powerful, scalable PHP5 application framework that follows the MVC
paradigm.
 CakePHP A webapplication framework modeled after the concepts of Ruby on Rails.
 CodeCharge Studio is a visual rapid application development environment for web-
based database driven application development. CodeCharge Studio places emphasis
on code generation technology to provide ASP.NET, PHP, JSP, Servlets, ColdFusion
and Perl language support.
 CodeIgniter An MVC framework for PHP4 (up-compatible with PHP 5.3.0 as of version
1.7.2).
 Drupal An open source content management system that uses MVC for its add-ons
called modules.
 Exponent CMS A Content Management System web application framework using its
own MVC framework modeled after Rails.
 eZ Publish Based on eZ Components is an object-oriented web application framework
written in PHP that separates its functionality into several abstraction layers,
following a strict MVC approach.
 Joomla! v1.5.x is an open source content management system that employs the MVC
model for its extensions, called components and modules.
 Kohana is an elegant HMVC PHP5 framework that provides a rich set of components
for building web applications.
 MODx A full-featured open source OOP MVC/ORB xPDO-based CMS.
 NanoMVC A rapid development PHP 5.3 framework for large-scale web applications.
 Odin Assemble A Small footprint PHP based MVC framework.
 phpXCore A MVC design pattern based PHP content management framework
compatible with PHP4 and PHP5.
 PureMVC A framework for PHP.
 Qcodo An open-source PHP 5 web application framework.
 Spawn Framework A framework for PHP5.
 SilverStripe Contains a fully fledged PHP 5.2 ORM/MVC framework focused on
building websites.
 Swiftlet A lightweight open-source web application framework for PHP 5.
 Switch board (framework) A PHP 5 MVC framework with routing.
 Symfony Framework A PHP 5 MVC framework modeled after the concepts of Ruby on
Rails.
 temovico is a lightweight PHP MVC framework.
 TinyMVC A lightweight framework with a database support layer and plugin support.
  Vork, MVC framework designed for rapid development of performance-oriented
scalable applications
 Yii Framework A new high-performance component-based PHP 5-based framework
for developing large-scale Web applications.
 Zend Framework An open-source PHP 5-based framework featuring an MVC layer
and a broad-spectrum of loosely coupled components.
 Zext CMS The Zext Project, MVC content management system.

Python

 Django A complete Python web application framework. Django prefers to call its MVC
implementation MTV, for Model-Template-View.[9]
 Enthought The Enthought Tool Suite brings the Model–view–controller mindset to
scientific GUIs and visualization
 Pylons—Python Web Framework
 TurboGears for Python
 web2py A scalable full-stack enterprise level Python agile web development
framework with support for highly flexible and rapid database-driven web application
development.
 Zope Web application server
 Plone Content management system built on top Zope
 PureMVC Framework for Python

Ruby

 Ruby on Rails
 Merb
 Ramaze
 Camping
 Nitro
 Monkeybars
 PureMVC Framework for Ruby.
 Sinatra

Smalltalk

 AIDA/Web

XML

 XForms—XForms has an integrated Model–view–controller architecture with an

integral dependency graph that frees the programmer from specifically having to
perform either push or pull operations.
Web application

A web application is an application that is accessed over a network such as the Internet or
an intranet. The term may also mean a computer software application that is hosted in a
browser-controlled environment (e.g. a Java applet)[citation needed] or coded in a browser-
supported language (such as JavaScript, combined with a browser-rendered markup
language like HTML) and reliant on a common web browser to render the application
executable.

Web applications are popular due to the ubiquity of web browsers, and the convenience of
using a web browser as a client, sometimes called a thin client. The ability to update and
maintain web applications without distributing and installing software on potentially
thousands of client computers is a key reason for their popularity, as is the inherent support
for cross-platform compatibility. Common web applications include webmail, online retail
sales, online auctions, wikis and many other functions.

History

In earlier types of client–server computing, each application had its own client program
which served as its user interface and had to be separately installed on each user's personal
computer. An upgrade to the server part of the application would typically require an
upgrade to the clients installed on each user workstation, adding to the support cost and
decreasing productivity.

In contrast, web applications use web documents written in a standard format such as HTML
(and more recently XHTML), which are supported by a variety of web browsers.
Generally, each individual web page is delivered to the client as a static document, but the
sequence of pages can provide an interactive experience, as user input is returned through
web form elements embedded in the page markup. During the session, the web browser
interprets and displays the pages, and acts as the universal client for any web application.

In 1995, Netscape introduced a client-side scripting language called JavaScript, which

allowed programmers to add some dynamic elements to the user interface that ran on the
client side. Until then, all the data had to be sent to the server for processing, and the results
were delivered through static HTML pages sent back to the client.

In 1996, Macromedia introduced Flash, a vector animation player that could be added to
browsers as a plug-in to embed animations on the web pages. It allowed the use of a
scripting language to program interactions on the client side with no need to communicate
with the server.

In 1999, the "web application" concept was introduced in the Java language in the Servlet
Specification version 2.2. [2.1?].[1][2] At that time both JavaScript and XML had already been
developed, but Ajax had still not yet been coined and the XMLHttpRequest object had only
been recently introduced on Internet Explorer 5 as an ActiveX object.[3]

In 2005, the term Ajax was coined, and applications like Gmail started to make their client
sides more and more interactive.

Interface

The web interface places very few limits on client functionality. Through Java, JavaScript,
DHTML, Flash, Silverlight and other technologies, application-specific methods such as
drawing on the screen, playing audio, and access to the keyboard and mouse are all possible.
Many services have worked to combine all of these into a more familiar interface that
adopts the appearance of an operating system. General purpose techniques such as drag
and drop are also supported by these technologies. Web developers often use client-side
scripting to add functionality, especially to create an interactive experience that does not
require page reloading. Recently, technologies have been developed to coordinate client-
side scripting with server-side technologies such as PHP. Ajax, a web development technique
using a combination of various technologies, is an example of technology which creates a
more interactive experience.

Structure

Applications are usually broken into logical chunks called "tiers", where every tier is assigned
a role.[4] Traditional applications consist only of 1 tier, which resides on the client machine,
but web applications lend themselves to a n-tiered approach by nature.[4] Though many
variations are possible, the most common structure is the three-tiered application.[4] In its
most common form, the three tiers are called presentation, application and storage, in this
order. A web browser is the first tier (presentation), an engine using some dynamic Web
content technology (such as ASP, ASP.NET, CGI, ColdFusion, JSP/Java, PHP, Perl, Python,
Ruby on Rails or Struts2) is the middle tier (application logic), and a database is the third tier
(storage).[4] The web browser sends requests to the middle tier, which services them by
making queries and updates against the database and generates a user interface.

For more complex applications, a 3-tier solution may fall short, and you may need a n-tiered
approach, where the greatest benefit is breaking the business logic, which resides on the
application tier, into a more fine-grained model.[4] Or adding an integration tier that
separates the data tier from the rest of tiers by providing an easy-to-use interface to access
the data.[4] For example, you would access the client data by calling a "list_clients()" function
instead of making a SQL query directly against the client table on the database. That allows
you to replace the underlying database without changing the other tiers.[4]

There are some who view a web application as a two-tier architecture. This can be a "smart"
client that performs all the work and queries a "dumb" server, or a "dumb" client that relies
on a "smart" server.[4] The client would handle the presentation tier, the server would have
the database (storage tier), and the business logic (application tier) would be on one of them
or on both.[4] While this increases the scalability of the applications and separates the display
and the database, it still doesn't allow for true specialization of layers, so most applications
will outgrow this model.[4]

Business use

An emerging strategy for application software companies is to provide web access to

software previously distributed as local applications. Depending on the type of application, it
may require the development of an entirely different browser-based interface, or merely
adapting an existing application to use different presentation technology. These programs
allow the user to pay a monthly or yearly fee for use of a software application without
having to install it on a local hard drive. A company which follows this strategy is known as
an application service provider (ASP), and ASPs are currently receiving much attention in the
software industry.

Writing web applications

There are many web application frameworks which facilitate rapid application development
by allowing the programmer to define a high-level description of the program. [5] In addition,
there is potential for the development of applications on Internet operating systems,
although currently there are not many viable platforms that fit this model.

The use of web application frameworks can often reduce the number of errors in a program,
both by making the code simpler, and by allowing one team to concentrate just on the
framework. In applications which are exposed to constant hacking attempts on the Internet,
security-related problems can be caused by errors in the program. Frameworks can also
promote the use of best practices[6] such as GET after POST.

Applications

Browser applications typically include simple office software (word processors, online
spreadsheets, and presentation tools), with Google Docs being the most notable example,
and can also include more advanced applications such as project management, computer-
aided design, video editing and point-of-sale.

Benefits

 Web applications do not require any complex "roll out" procedure to deploy in large
organisations. A web browser is all that is needed;
 Browser applications typically require little or no disk space on the client;
 They require no upgrade procedure since all new features are implemented on the
server and automatically delivered to the users;
 Web applications integrate easily into other server-side web procedures, such as
email and searching.
 They also provide cross-platform compatibility in most cases (i.e., Windows, Mac,
Linux, etc.) because they operate within a web browser window.

Drawbacks

 Web applications absolutely require compatible web browsers. If a browser vendor

decides not to implement a certain feature, or abandons a particular platform or
operating system version, this may affect a huge number of users;
 Standards compliance is an issue with any non-typical office document creator, which
causes problems when file sharing and collaboration becomes critical;
 Browser applications rely on application files accessed on remote servers through the
Internet. Therefore, when connection is interrupted, the application is no longer
usable but if it uses HTML5 API's such as Offline Web application caching[7], it can be
downloaded and installed locally, for offline use. Google Gears, although no longer in
active development, is a good example of a third party plugin for web browsers that
provides additional functionality for creating web applications;
 Since many web applications are not open source, there is also a loss of flexibility,
making users dependent on third-party servers, not allowing customizations on the
software and preventing users from running applications offline (in most cases).
However, if licensed, proprietary software can be customized and run on the
preferred server of the rights owner;
 They depend entirely on the availability of the server delivering the application. If a
company goes bankrupt and the server is shut down, the users have little recourse.
Traditional installed software keeps functioning even after the demise of the
company that produced it (though there will be no updates or customer service);
 Likewise, the company has much greater control over the software and functionality.
They can roll out new features whenever they wish, even if the users would like to
wait until the bugs have been worked out before upgrading. The option of simply
skipping a weak software version is often not available. The company can foist
unwanted features on the users or cut costs by reducing bandwidth. Of course,
companies will try to keep the good will of their customers, but the users of web
applications have less options in such cases unless a competitor steps in and offers a
better product and easy migration;
 The company can theoretically track anything the users do. This can cause privacy
problems.