what is difference between 2 or 3 tier architecture and n tier architecture

2- or 3-tier architecture is specific case of n-tier one ;)
Nowadays approach to IT systems architecture is 4-tier.
1st tier is a Presentation Layer: this is what user sees and clicks.
2nd tier is a Business Logic Layer (BLL): this is a set of rules how system has to behave and process data.
3rd tier is a Data Access Layer (DAL): this is a set of fuctions for retriving and manipulating data in database.
4th tier is a database: it contains data scheme, data itself and (if used) stored procedures.
If you have 2-tier or 3-tier architecure it means that some mentioned above layers are implemented together that borders between them disappeared and can be treated as 1.

In a 2 tier architecture the program (sourcecode and business logic) are separated from the database ( data, tables). Example: a factory application with a server that holds the program, a second server that holds the database and a socalled consol that is use as an interface to users.
In a 3 tier environment there is also a separate program running on the lokal PC. This program performs the local activities and communcates with the program running on the application server.
n- tier add an extra level between the PC and the rest. Using the internet is an example. You explorer is the local program. The server of your provider is the informaten broker. This is the extra level that holds the logic of combining messages and information from diverent sources and systems into 1 HTML page. For example. You're using a google bar. This part of the page get's it information from the main program that runs at the Google server, which in it's turn is connected to the google database.

As others have written, n tier is a generlization of 2 or 3 tier arhictecture.
I look at tiers as isolated software layers that are responsbile for handling specific roles at your software - if you know the OSI 7 layers networking model, then the case is quite similar. Each tier is either using interfaces defined by components from the same tier, or one tear above or under.
Sometimes, even when you think your architecture is closed and that you have all the tiers, if you expose interfaces, another tier may be added in the future to the architecture.

Vivek, in addition to the other answers already given to you.

Layered models emphasize the independence of functionality in a software architecture. In other words, each layer performs a different set of functions, and each layer is independent of other layers. For example, UI logic in the Presentation Layer might depend on data from a business object implemented in the Business Servicing Layer. However the UI logic is not dependent on how the business logic was implemented. The UI logic can be JavaScript code, while the business logic was written in the Progress 4GL. Furthermore, the UI logic might be totally redesigned (or
even implemented through some other technology) without having to change the business logic. The following sections define each layer of a n-tier architecture in more detail.

Data Access Layer
The function of components in the Data Access Layer is to separate data access from data storage. The purpose is to shield the rest of the application from the details of data storage, which makes applications easier to build and to maintain. For example, you might need to
extend an application by changing the data source from a relational database to flat XML files. Such a change can be implemented in a single Data Access component rather than in multiple components throughout the application

Business Servicing Layer
The Business Servicing Layer contains the business logic and the processing components of an application. The components in this layer respond to events by taking certain actions. For example, when a price change occurs, update listings in a product catalog and notify sales reps.
The components in this layer also enforce business rules. For example, do not process an order if balance due is over thirty days old. Furthermore, the components in this layer are structured
to create a workflow among related processes.

Presentation Layer
The Presentation Layer is the user interface component of an application. It is the point where an external user interacts with an application. Interaction can be direct (by data input) or indirect
(by viewing data).

The Presentation Layer consists of three major components:
User interface components (forms, buttons, menus, etc.).
Controller logic that manages the binding between UI components and business logic in the Business Servicing Layer.
Service elements (or models) that define the contract with the Business Servicing and the Data Access Layers.

Integration Layer
The Integration Layer is similar to the Presentation Layer. Where the Presentation Layer exposes the n-tier application to external users, the Integration Layer exposes the application to external systems. Integration can be data-centric, which involves moving data from one application to another. Integration can also be functional, which involves exposing an
application’s business processes and logic as a service that can be used by external systems.

Links:
http://www.psdn.com

Short answer:

A two-tier architecture is where a client talks directly to a server,
with no intervening server. It is typically used in small environments
(less than 50 users).

A three tier is a client-server architecture in which the user interface is the 1st tier, the functional process logic ("business rules") is the second tier, the data storage and data access are the 3rd tier. Each tier is developed and maintained as independent modules, most often on separate servers.

An n-tier architecture is the extension of this concept where finer levels of functionality are distributed across multiple servers.

Long answer:

The answer to this question depends on the context that is being asked.

For example, are you asking from the perspective of software architecture, the design of a new communication protocol, etc? I will assume that you are asking about software architectures, as this is the most common context.

In software engineering, multi-tier architecture (often referred to as n-tier architecture) is a client server architecture in which more than one software agent usually running in different servers does the execution of an application. The reasons for multi-tier architectures are as follows:

1. Performance: allows for scalability by distributing the computation across multiple servers. Of course, a downfall of such strategy is when the communication costs are larger than the computation costs. In the old days, study of the decompositions of architectures was done by using queuing theory. A classic book in this area is the book by Kleinrock, Theory, Volume 1, Queueing Systems;

2. Security: by decomposition, different security strategies can be applied at each level of the hierarchy, and hence, this leads if properly designed to better security; and

3. Reliability and distribution: any layer of the architecture can be run in different servers, and therefore when a failure occurs, if properly designed, then a redirection to another server is possible. Of course for this to work a robust distributed architecture that often includes persistent transactions (a transaction that either completes or is roll back) are needed. If you want to learn more about this go to ACID PROPERTIES of TRANSACTIONS.


Hence, within this context, 2-tier, three-tier, and so for are mainly subsets of the general solution n-tier. The key is how do you separate the different functions most effectively to achieve your desired results. For example, let’s say that you want to implement an airline reservation system. You may select to build a 2-tier architecture whereas:

1. The so called presentation layer (what the user sees) runs on your local PC through a browser agent, and

2. Everything else, business logic, database layer, data base itself runs on a back-end server.

In this example, after you fill out the typical form and submit a request for travel you may get a web answer saying, “you forgot to fill out the destination city”. This happens because the business logic that understands the need for both an origination city and destination city to process a request does not run (execute) on your PC, and therefore, the backend server will not check it until the request is process. Is 5this efficient? Maybe?

Bottom line, decomposition into multiple tiers is good, but.. too much decomposition is bad – leads to performance problems, etc. I hope this helps.

One thing that it appears that the others have missed (although I'll admit that I didn't read them completly) is that there may be more than one data store, increasing the tier structure by at least one layer and possibly two.

One system I worked on had layers in the 4 tiers described by others but also another data access layer for connecting to a PBX. There could be multiple different flavors of PBXs as well, each with seperate access components. Depending on the intrerpretation that would be one or two additional layers per PBX family.

We also had out presentation layer segmented in such a way that that layer can be described as having one plus one for each PBX family which had its own presentation logic which was in fact an extension of main logic but was implemented in such a way that it was a unique layer.

Basically my point with all of this is that n-tier development is basically keeping presentation seperate from logic seperate from data, and that the number of layers it takes is not as important as the fact that it is done.

Tiers relate to layers of the system architecture. Tiers originated with model-view-controller (MVC) pattern many years ago in Smalltalk. This separated what the user sees (the view) from the logic to handle the user's actions (the controller) and the business logic (the model).

From this point, it somewhat depends on your application. For example, if you are targeting a service-oriented architecture (SOA) you will want to focus on creating Web services. Either way, you will want a layer to request functionality (services) from your business logic. I'd suggest a service layer, both interfaces for client code to build to and the actual underlying implementations.

You will certainly want to separate out database access. The "standard" is to use data access objects (DAOs) to manage model state persistence. If you are using Java, this would be through the JDBC standard or a persistence framework such as Hibernate. For .NET, you would use ADO.NET.

So, your tiers would look like this:

- view (or web)
- service
- service implementation
- dao
- dao implementation

This layering facilitates using most (all?) tooling. For example, you could easily use the Spring framework to handle authorization, transactions, AOP, ... with regular POJOs. Or you could use EJBs if you prefer. Or you can use .NET.

Getting back to your original question... 2-tier is an outdated way that systems were once built, usually with a UI interacting directly with an RDB. From there, the industry moved to 3-tier and n-tier. The difference is really what you count as a "tier". Some people consider parts of the system such as messaging (SOA, JMS, SOAP, ...) as a tier and some don't. I wouldn't get too hung up about 3-tier vs. n-tier, just be aware that all well-designed systems today have 3+ tiers. Just be clear what you are counting (e.g. by labeling parts of diagrams and/or including text descriptions) as a tier.

I hope this helps answer your question. Best of luck!
Mark

Clarification added 7 months ago:
Forgot to include some links... :")

One, two, three, or n tiers?
http://www.javaworld.com/javaworld/jw-01-2000/jw-01-ssj-tiers.html

Scaling the N-Tier Architecture
http://www.sun.com/software/whitepapers/wp-ntier/wp-ntier.pdf

Multitier architecture
http://en.wikipedia.org/wiki/N-tier

Understanding JavaServer Pages Model 2 architecture
http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-jspmvc.html

Designing Enterprise Applications
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html

Web Services and Service-Oriented Architectures
http://www.service-architecture.com/

What is a three-tier architecture?
http://www.jguru.com/faq/view.jsp?EID=125072

Building a 3-Tier Application using ASP.NET
http://www.c-sharpcorner.com/UploadFile/paulabraham/Building3TierAppPA11282005053625AM/Building3TierAppPA.aspx


You know the 'dhabas' in India where you get 'chai' (tea) and food? There's one guy who's running around to the beaton of the customers who're waiting on him. He comes to you to ask you what you want, writes down your order, then tucks into the kitchen, picks up the peeled and finely chopped onions that he'd diced into the morning, places the pan on the gas stove and cooks.

While it's cooking, he gets the next order from the guy behind you.

That is somewhat analogous to how the 'body of a software looked like from the inside' to the programmer, in the very olden days. If programmers in a company were creating software for an oil company to run its business, they wrote everything all in one place. As a result, the program was one monolithic structure that did everything -- got the data input from the user, did all the calculations, checked if he was telling the truth, stored his input in the database and got back some output to him after that. Just like the dhaba owner -- he put the eggs on the pan, took orders from customers, ran around to do a sitting customer's bidding, and yet people yelled at him.

That was the olden day. Today, the tasks performed by one software are divided into many different software programs. One program just displays a neat, click user interface to the user and that's that. It does nothing beyond that. When the user inputs data, the program passes on the data to another program, which in turn checks for the correctness of the data using some rules.

The data is passed to a third program that stores the data nicely so that it can be retrieved easily later on. This division of labour amoung three programs is called a three-tier architecture.

Now, you could employ a fourth program to do something else in between, like, to act as a translator between two of the existing programs. Adding any number of more programs to this division is called having an N-tier architecture.

Watch out - often N tier leads to many tears.

One risk is that people confuse/conflate functional decomposition with physical architecture.

So its an excellent thing to distinguish between user interface, application logic, domain/business logic, persistence at a functional level, and here language features like packages, and distribution jars are a way of enforcing that separation.

This doesn't mean that building an application in four physical tiers (such as the approach recommended in the J2EE Blueprints) is optimal. Most of the time this excessive distribution just adds complexity, latencies, and opportunities for partial failure.

Martin Fowler says that the Golden Rule of Distributed programming is don't distribute logic! There have been many attempts to move away from N tier approaches, because of their scalability limits, and to replace them with simpler, faster architectures such as that made possible with Gigaspace, JavaSpaces, peer to peer, Ruby DRB and Rinda, memcached, and the like.

It's important to distinguish between tiers as physical layer

I wanted to make one general distinction between layers and tiers since these two terms seem to be used interchangeably in many of the answers. These two terms are not interchangeable. A layered architecture is different from a tiered architecture. A tiered architecture consists of multiple processes running on different machines simulatenously. E.g.: The Client tier has client processes or programs running, while the server tier has the server process running. So, client server is an exampe of a 2-tiered architecture. When a single server is not capable or convenient to handle multiple such processes, the architecture has more tiers, like an application server which holds the appliation code and a data tier which holds the database and data access modules. It is important to note that all these are independently running programs (runtime components) usually on different machines. At runtime, there are multiple threads or processes of execution. This is unlike a layered architecture where each layer consists of different modules and modules in an upper layer can call modules (services) at the lower layer. At runtime, a layered architecture boils down to a single thread of execution.

In a very simple way the two-tier architecture:

Client -> User interface and some business logic
Database server -> Data managment and some business logic

The basics for a non partitioned application are:
You control the number of clients (number of transactions)
Work group or in department way
You also control the platform

Client-side business rules and system management logic are part of the visual interface
Some examples are:
Database connection logic written entirely in the event of the visual object, the business rule is in a window function or event

Two-tier partitioned application:
Client-side business rules and system management logic are coded in nonvisual objects
A simple example is that the database connection logic is written in custom class.

It's very easy to maintain, and permits the reuse of the business logic within application, it also enables the reuse of business logic for future applications. You may include some web clients, and you can port to other architectures.

The N-Tier Architecture:

Client -> User Interface
Application Server -> Business logic, transaction management, load balance, caching, data location transparency.
Database Server -> Data managment

It adds an application server between the client and the database server
Business rules are not in the client but are centrally located
You can reuse business logic in future applications
Offload some processing from database server and reduce drastically database connections, you can also enable your application to connect via web clients to access these components or wireless