Wednesday, March 12, 2008

Two, Three, N-tier which one should I pick?

Jeff asked me (in the Post How to pass SCEA 5) about the following:
  • Explain the advantages and disadvantages of two-tier architectures when examined under the following topics: scalability, maintainability, reliability, availability, extensibility, performance, manageability, and security.
  • Explain the advantages and disadvantages of three-tier architectures when examined under the following topics: scalability, maintainability, reliability, availability, extensibility, performance, manageability, and security
  • Explain the advantages and disadvantages of multi-tier architectures when examined under the following topics: scalability, maintainability, reliability, availability, extensibility, performance, manageability, and security.
I will try to put my thoughts in here about this and I will use the following example to illustrate the case of study: Your assignment is to create a check in application for a counter in an airport. so it will show the current flights, allowing you to pick one, then lists the customers for that flight and assign the passenger's seat. (use your imagination here)

Two Tiers:

First a brief description of the situation, a two tier application its mainly a client application which has everything in one layer and connects to a repository (a database if you prefer), this is also known as Client-server architecture. (this is just a brief introduction, you could go client-server architecture to get more detail.

Lets ask first, if all the code is in one place (the client... like a swing application) the client will have all the power force and everything depends on its machine, is it an scalable solution? what will happen if you add new clients? the network overload will be a problem, because these type of application uses it a lot.

In the example the work flow will be as follows:

1. Executes a SQL to get all the current flights (between some date range)
2. shows the flights, and select the one using the ticket information
3. Executes a SQL to get the customers on that flight
4. Shows the list and select the passenger
5. Executes a SQL to verify the status of the ticket.
6. and so on.

The DB connections are very expensive and very slow, so, if you put new customers your application will have serious problems in bandwidth, overload, etc. So your application is not easily scalable. But... if you have only 3 clients (maybe three counters) this will be a very fast solution, the client application will do all the work and will be very effective. The troubles will come if you want to export this to Internet, because the clients will not have access to your internal network, you will need to spread the user and password for the db, etc.

Is this application maintainable? Think of this, if all the code is in the client will be easy to find an error? I don't think so.

What about reliability? the reliability states: "the ability of a system or component to perform its required functions under stated conditions for a specified period of time." so will the client-server be reliability? its hard to figure it out. If the system could be easily break down (because the code is in the client side) someone could change its reliability changing a part of the code. If the network configuration change the client might have problems to establish the connection to the DB, so the reliability will be affected, but as the definition states, everything depends on the conditions not the architecture.

The system will have a high availability? because all the code will run on the client this configuration will not react to a fail over problems, because everything is in one machine if that machine fails the system will not work, so the availability will decrease with this architecture.

Extensibility, mmm... I think no, its hard to maintain and extend a Client-server application, just because everything is in one place.

Performance, ok, here is the big question, the performance in a Client-server application relies on how it will work, if it has several calculations everything depends on the client, there's no way to distribute the work between several machines, all the work will be running in one PC, but... the client-server applications runs fast if you do some tricks. In the example above the performance could be an issue in here, just because it has a lot of DB queries dependencies.

Manageability, think if you are able to change some parameters and your application will run fast or will have a better reliability, the answer will be no, just because everything runs in the client and you will have absolutely no control over it.

In general I would say that increasing the tiers will ensure extensibility, maintainability, security but will decrease performance.

Remember, tiers refers to the layers in which your system could split off, if your application have a lot of classes but works in a single machine which connects to a DB then it's a client-server application.

Three Tiers

In the three tiers your application will have some logic in the client (usually the presentation and some validations), the business tier will have the 80% of the application logic (lets say this will have most of the business code) and the DB which could have some Stored Procedures in it.

What will be different from the previous approach? you will have a lot of things running in one machine, so its easier to maintain, you will increase security because the client will not have the user/password pair to access to the DB, and will be more extensible than the client-server application. But what will you gain or lose? the answer is not easy, I would say It's relative, If the application is a calculation centric then you might lose performance (because the server will do a lot of work for several clients at the same time) or you could gain performance if the application is mainly a db application, just because you could place the DB server near (referring to the network topology not the physical distance) to the business server in order to avoid the network overload.

In comparison with the Client-server you will have:

- better scalability, you could increase the hardware in the business machine and could have more clients.
- better maintainability, everything is in one place so you can replace a component and fix a bug quickly
- better reliability, because you have a better control of the environment in which the business code runs.
- better availability, if the business machine has problems you can easily replace it by a new machine a your client will be running in a blink of an eye
- better extensibility, you could add new functionality in a better way
- decrease or increase in performance, this depends on the application, if its a db application its 90% to get a better performance.
- Better manageability, its easy to control the environment in the business tier, so you can change configuration settings, improve connections etc
- Better security (I think this does not need further explanation...)


I think N-tier and 3-tier are pretty much the same thing, if you have a good security in 3-tier you will have even better security with N-tier and this applies to all the statements. (Even to the performance thing, a bad decision could lead to a poor performance if you choose N-Tier over the others and you don't pay attention on the specific requirements)

Why will you prefer N-Tier over 3-tier, you could distribute the work in several machines, so if you are working in a collaborative application (I loan application which will need a CRM, ERP etc then will be distribute its responsabilities over several machines and will have a better performance because of it)

In JEE you could easily use some patterns like Service Locator to change a N-Tier to a 3-Tier application (or, at least, behave as a 3-tier application), just changing the uses of the EJBs from Remote to Local. So if I need a tiered application I will choose N-tier over 3-tier every day of the week (and twice in Sunday)

(Please let me know if you need further explanation and I will add more information on N-Tiers)


Cyc0.M4nt1s said...

Like they say, "It Depends" :)

It's always a matter of choice, when you're designing the architecture for a new project you need to be fully aware of the environment in which your project is going to be held, if you are working for a small company with a few clients you won't need all the infraestructure and costs that involves having a N-Tier solution, on the other hand, if you are working for a big company for who expending thousands of dollar in servers, stations, software, dogs, cats, etc is not a problem, you can easily think of a bigger solution.

By the way, nice work here Cross it's good to see that you're willing to share your knowledge and experiencie with the world, and we know that you have a lot of that :D

penguin said...

Thanks, that was helpful.

I need a help too for

Explain and contrast the following persistence strategies: container-managed persistence (CMP) BMP, JDO, JPA, ORM and using DAOs (Data Access Objects) and direct JDBC technology-based persistence under the following headings: ease of development, performance, scalability, extensibility, and security.


Cross said...

Hi Penguin, thx for commenting, I will create a new article tonight and I hope to post it tomorrow about your question, I'll do my best to solve it properly.

Rodrigo said...

Hi Cross,
I don't quite agree with your post when you mention.. "Manageability, think if you are able to change some parameters and your application will run fast or will have a better reliability, the answer will be no, just because everything runs in the client and you will have absolutely no control over it."

What do you mean by having no control over it? Every piece of book I read about manageability says that increasing tiers gives you less manageability. Please advise what your point is here.

Cross said...

Hi Rodrigo, let me copy the Mark Cade's definition:

Manageability is the ability to manage the system to ensure the continued health of a system with respect to scalability, reliability, availability, performance, and security. Manageability deals with system monitoring of the QoS requirements and the ability to change the system configuration to improve the QoS dynamically without changing the system. Your architecture must have the ability to monitor the system and allow for dynamic system configuration."

from this perspective your application will be less manageable if you have everything in the client (If we talk about a swing application with some DB Stored Procedures), in this case the application will be less manageability because you cannot change something in the client to solve or improve the quality of your system. that's my point... I think (in terms of the SCEA) that the answers depends on "Are we talking about a Web application or a Swing application?",

if we're talking about a Web application then 1 Tier will be more manageable than 2, 3 or n Tiers, just because everything will run in a single instance. if we're talking about a swing application then 1 Tier will be less manageable than a 2 Tier and 3 Tier. So I think everything is a big "depends", you must do a good analysis of your requirements in order to answer the question: "Is this XXXX more manageable than YYYY?"

I hope this solve your questions, and clarifies the disagreement.

btw, I will use all the people's feedbacks to improve the blogs and give an accurate perspective of what to expect in the SCEA. thx for your comment.

Cross said...

Rodrigo, this is taken from the Interactive Osbourne Training tools (Sun Certified Architect for J2EE Study Guide) from McGrawn-Hill:

"Three-tier architecture is used
when an effective distributed design is needed to provide (when compared to client-server) increased performance,
flexibility, maintainability, reusability, and scalability, while masking the complexity of distributed processing from the user."

but, again... I think we should put this in context.

Rodrigo said...

Thank you for your reply. I guess see your point now. If we go by the definition, it states that manageability should take other nonfunctional skills (such as scalability) into consideration. And those apply differently to each scenario/context such as swing vs. web.
The thing is, by the definition when I hear "manageability", I think "monitoring" (maybe because this definition fits to more scenarios). And thinking of monitoring an application, I believe it's more complex to monitor distributed applications compared to monolithic ones.
But again, we need to keep in mind it's all about scenarios, oh well!

RoNaK said...
This comment has been removed by the author.
RoNaK said...
This comment has been removed by the author.