Introduction to N-tier Architecture

N-Tier architecture is an industry-proved software architecture model, suitable to

support enterprise-level client/server applications by resolving issues like scalability,
security, fault tolerance and etc.

Some Terminology's Difference and Relationship

Tier and Layer

Firstly we need to clarify the difference between two terms in N-Tier architecture: tier
and layer. Tier usually means the physical deployment computer. Usually an individual
running server is one tier. Several servers may also be counted as one tier, such as
server failover clustering. By contrast, layer usually means logic software component
group mainly by functionality; layer is used for software development purpose. Layer
software implementation has many advantages and is a good way to achieve N-Tier
architecture. Layer and tier may or may not exactly match each other. Each layer may
run in an individual tier. However, multiple layers may also be able to run in one tier.

A layer may also be able to run in multiple tiers. For example, in Diagram 2 below, the
persistence layer in .NET can include two parts: persistence Lib and WCF data service.
The persistence lib in the persistence layer always runs in the same process as business
layer to adapt the business layer to the WCF data service. However, the WCF data
service in persistence layer can run in a separate individual tier. Here is another
example: we may extract the data validation in business layer into a separate library
(but still kept in business layer), which can be called by client presenter layer directly
for a better client-side interactive performance. If this occurs, then data validation part
of the business layer runs in the same process of the client presenter layer, the rest of
business layer runs in a separate tier.

Tier And Process

If a layer can run in an individual process, usually it will also be able to run in an
individual computer (tier), hence it can be considered capable for an individual tier in N-
Tier architecture. However, this isn’t always true. For example, assume that there are
two layers which are implemented to run in two individual processes; they communicate
with each other too. However, if these two layers are implemented in such a way that
their IPC (inter-process communication) is solely based on a non-distributed way, such
as the local shared memory, then these two layers can run in two different processes
only in the same computer, not in two different computers. Unless there is another
alternative distributed IPC way (such as socket) available for these two layers, these
two layers will be considered capable for only 1-tier even though they can run in two
different processes of the same computer.

Layer and Process

A layer may run in an individual process; several layers may also run in an individual
process; a layer may run in several processes too. If you read above section “Tier and
Layer Relationship”, you can understand here easily.

3-Tier Architecture
We introduce the 3-Tier concept first so that we can understand other tier concepts
later easily. The simplest of N-Tier architecture is 3-Tier which typically contains
following software component layers listed from the top level to the low level:
presentation layer, application layer and data layer, which are depicted in Diagram 1.

A layer can access directly only the public components of its directly-below layer. For
example, presentation layer can only access the public components in application layer,
but not in data layer. Application layer can only access the public components in data
layer, but not in presentation layer. Doing so can minimize the dependencies of one
layer on other layers. This dependency minimization will bring benefits for layer
development/maintenance, upgrading, scaling and etc. Doing so also makes the tier
security enforcement possible. For example, the client layer cannot access the data
layer directly but through the application layer, so data layer has a higher security
guarding. Finally, doing so can also avoid cyclic dependencies among software
components.

In order to claim a complete 3-Tier architecture, all three layers should be able to run in
separate computers.

Diagram 1: 3-Tier Architecture

These three layers are briefly described as below:

Presentation layer: a layer that users can access directly, such as desktop UI, web
page and etc. Also called client.

Application layer: this layer encapsulates the business logic (such as business rules
and data validation), domain concept, data access logic and etc. Also called middle
layer.

Data layer: the external data source to store the application data, such as database
server, CRM system, ERP system, mainframe or other legacy systems and etc. The one
we meet often today is database server. For N-Tier architecture, we need to use the
non-embedded database server, such as SQL server, Oracle, DB2, MySQL or
PostgreSQL. The non-embedded database server can be run in an individual computer.
Whereas, the embedded type databases, such as Microsoft access, dbase and etc,
cannot run in an individual computer, and then cannot be used as the data layer of the
3-Tier architecture.
1, 2, 3 or More Tier Architecture
1-Tier: all above layers can only run in one computer. In order to achieve 1-Tier, we
need to use the embedded database system, which cannot run in an individual process.
Otherwise, there will be at least 2-Tier because non-embedded databases usually can
run in an individual computer (tier).

2-Tier: Either presentation layer and application layer can only run in one computer, or
application layer and data layer can only run in one computer. The whole application
cannot run in more than 2 computers.

3-Tier: the simplest case of N-Tier architecture; all above three layers are able to run in
three separate computers. Practically, these three layers can also be deployed in one
computer (3-Tier architecture, but deployed as 1-Tier).

N-Tier: 3 or more tiers architecture. Diagram 2 below depicts a typical N-Tier

architecture. Some layers in 3-Tier can be broken further into more layers. These
broken layers may be able to run in more tiers. For example, application layer can be
broken into business layer, persistence layer or more. Presentation layer can be broken
into client layer and client presenter layer. In diagram 2, in order to claim a complete N-
Tier architecture, client presenter layer, business layer and data layer should be able to
run in three separate computers (tiers). Practically, all these layers can also be
deployed in one compute (tier).

Diagram 2: N-Tier Architecture

Below are brief summaries on all layers in Diagram 2:

Client layer: this layer is involved with users directly. There may be several different
types of clients coexisting, such as WPF, Window form, HTML web page and etc.

Client presenter layer: contains the presentation logic needed by clients, such as ASP
.NET MVC in IIS web server. Also it adapts different clients to the business layer.

Business layer: handles and encapsulates all of business domains and logics; also
called domain layer.

Persistence layer: handles the read/write of the business data to the data layer, also
called data access layer (DAL).

Data layer: the external data source, such as a database.

Sometimes, the number of tiers is able to be equal or more than 3, but client presenter
layer, business layer and data layer cannot run in three separate computers (tiers). Is
 this a N-Tier architecture? We categorize this N-Tier as an incomplete N-Tier
architecture because its client presenter layer, business layer and data layer cannot run
in three separate computers (tiers).

If we use the modern non-embedded database such as Sql Server, Oracle and etc, these
databases will always be able to run in an individual computer. Therefore, for this case
in Diagram 1, the criteria of a 2-Tier architecture is that presentation layer and
application layer can run in only one computer; the criteria of a complete 3-Tier
architecture is that presentation layer and application layer can run in different
computers. A complete N-Tier architecture has the same criteria as 3-Tier.

Advantages and Disadvantages of

Different Tier Architectures
1 or 2-Tier Architecture
Advantages: simple and fast for a lower number of users due to fewer processes and
fewer tiers; low cost for hardware, network, maintenance and deployment due to less
hardware and network bandwidth needed.

Disadvantages: will have issues when the number of users gets big; has limitation to
solve issues like security, scalability, fault tolerance and etc because it can be deployed
in only 1 or 2 computes.

N-Tier Architecture
Advantages: there are following general advantages:

1. Scalable: this is due to its capability of multiple tier deployment and the tier decoupling
it brought. For example, the data tier can be scaled up by database clustering without
other tiers involving. The web client side can be scaled up by load-balancer easily
without affecting other tiers. Windows server can be clustered easily for load balancing
and failover. In addition, business tier server can also be clustered to scale up the
application, such as Weblogic cluster in J2EE.

2. Better and finer security control to the whole system: we can enforce the security
differently for each tier if the security requirement is different for each tier. For
example, business tier and data tier usually need higher security level than
presentation tier does, then we can put these two high security tiers behind firewall for
protection. 1 or 2 tiers architecture cannot fully achieve this purpose because of a
limited number of tiers. Also, for N-Tier architecture, users cannot access business layer
and data layer directly, all requests from users are routed by client presenter layer to
business layer, then to data layer. Therefore, client presenter layer also serves as a
proxy-like layer for business layer, and business layer serves as a proxy-like layer for
data layer. These proxy-like layers provides further protection for their layers below.
3. Better fault tolerance ability: for example, the databases in data layer can be clustered
for failover or load balance purpose without affecting other layers.
4. Independent tier upgrading and changing without affecting other tiers: in object-
oriented world, Interface-dependency implementation can decouples all layers very well
so that each layer can change individually without affecting other layers too much.
Interface-dependency means a layer depends on another layer by interfaces only, not
concrete classes. Also, the dependency of a layer only on its directly-below layer also
minimizes the side effect of a layer’s change on the whole system. For example, if keep
the interfaces unchanged, we can update or replace the implementation of any layer
independently without affecting the whole system. Due to the changing of business
requirement and technology, changing the implementation of a layer to another totally
different one does happen often. For example, originally we use Windows Form mainly,
now we use WPF mainly. If our original system is implemented as the decoupled layer
structure, then we will only need to update the client side from Windows Form to WPF
without the need to change the server side layers.

5. Friendly and efficient for development: the decoupled layers are logic software
component groups mainly by functionality, they are very software development friendly
and efficient. Each layer can be assigned individually to a team who specializes in the
specific functional area; a specialized team can handle the relevant task better and
more efficiently.

6. Friendly for maintenance: N-Tier architecture groups different things together mainly by
functionality and then makes things clear, easily understandable and manageable.
Friendly for new feature addition: due to the logical grouped components and the
decoupling brought by N-Tier architecture, new features can be added easily without
affecting too much on the whole system.

Better reusability: this is due to the logically grouped components and the loose
couplings among layers. Loosely-coupled component groups are usually implemented in
more general ways, so they can be reused by more other applications.

The Disadvantages of the N-Tier Deployment

1. The performance of the whole application may be slow if the hardware and network
bandwidth aren’t good enough because more networks, computers and processes are
involved.
2. More cost for hardware, network, maintenance and deployment because more hardware
and better network bandwidth are needed.

The effects of N-Tier deployment on the application performance are a double edge
issue. In one side, if the number of uses isn’t big enough, the performance may be slow
due to more computers, process and network involved. Namely, if put everything in one
tier or one process, performance will be better for a small number of users. However, if
the number of user gets big, then the scalability brought by N-Tier will improve the
overall performance, such as load balancing and database clustering which all improve
the performance of N-Tier architecture. Why the performance result of the small
number of users and the big number of users are different? this is because the
bottleneck of the whole application are different for these two situations. For the case
with the small number users, the bottleneck is the time for data to communicate among
different processes. If more computer, more processes and longer network, then costs
longer, then performance is bad. However, when the number of user gets big, the
bottleneck shift to other things because of server’s capacity, such as cpu and memory
resource contentions in one computer, database threshold in server, horsepower
 limitation of a web server and etc. Only the scalability of N-Tier architecture can solve
these bottlenecks existing with a big number of users; usually load balancing by server
clustering is used for N-Tier architecture’s scalability. With more computers are scaled
up to share the task for big number of users, then performance is improved. Besides
gaining performance by scalability of N-Tier architecture, we can also improve the
performance with better hardware and better network bandwidth to meet our business
requirement.

Business Data Validation in N-Tier

Architecture
Data validation is important and a MUST in N-Tier architecture in order to keep the
whole business system healthy and integral. The first question for business data
validation will be: where or which layer should handle the data validation? There are
some rules and facts as below for the business data validation, which will give us some
tips and can answer this question too:

1. Data validation can be checked in any layer. Usually, the closer to the client layer the
validation is, the more efficient the performance is. The farther to the client layer the
validation is, the more reliable and robust the application is. When the validation is
checked in business layer or persistence layer, it is guaranteed that every type client
will get the validation regardless whether or not the client side will check the validation.
2. When we decide which layer should do the validation, we need to achieve a balance
result between performance, reliability and robustness, also we need to make decisions
based on the actual situation. If we have full control of the all layers, we can let all
validations happen in client/client presenter layers only to gain performance. However,
if the business layer is also exposed to some client/client presenter layers which is out
of our co3ntrol, then the business or lower layer must do all validations to gain reliability
regardless of whether or not our clients do the same validation.
3. Client side validation is efficient, such as Javascript validation in a web page. However,
users may bypass the client side validation easily and intentionally, such as webpage
hacking. Therefore, it is needed to do data validation in both client side and server side
to achieve both performance and reliability. The business layer and other further lower
layers usually belong to the server side. Client presenter layer may or may not be in the
server side; a webserver client presenter layer such as ASP.NET or PHP is in the server
side. Client presenter layer for WPF (Windows Presentation Foundation) may not be in
the server side.
4. A more practical way is to do the simple data validation in client side for performance
and further do a full validation in server side for reliability. The simple data validation is
mainly the single property checking of an entity instance. The full validation includes
the simple data validation and some complex data validation. The complex data
validation can include class-level data validation which crosses multiple properties of an
entity instance and the data validation which crosses multiple entity instances of similar
or different types.
5. For some interactive client application, we need to do client side validation anyway for
acceptable interactive performance, regardless of whether or not we will do the
validation in server side. Some game applications belong to this category.
6. We should implement and maintain one version of validation logics in one place,
regardless of where the validation will be checked. All layers should share this one
version of validation logics. Why? Doing so has better reusability; it can avoid duplicate
and conflicting validation logic in many places and makes the development,
maintenance and deployment easier; it keeps the whole validation logics consistent
throughout the whole application. In addition, the places to check validation may
change with the changing and growing of the business, so validation should be kept in
one place with one version but flexible to be called by any layer if needed.