Definition for 'Multi-tier' application

Definition for 'Multi-tier' application

Post by Danie » Tue, 02 Sep 2003 08:22:37


Sorry to waste people's time, but before I start aimlessly asking questions
in this group can someone clarify what a 'multi-tier' application would be -
just so I know I'm asking relevant questions.

Is a multi-tier application simply an application where multiple users are
simultaneously accessing the same database over a LAN?

Thanks Dan
 
 
 

Definition for 'Multi-tier' application

Post by daniel via » Tue, 02 Sep 2003 09:06:24


daniel,

a multi-tier application is an application divided in tiers, for example, a 3 tier application :

the first tier is the client application. usually this application contains only the graphical interface for the user, such screens for input data etc.

the second tier is the application server, which has all the business rules, such validation of data. the app server can be a DLL or EXE file, which is called by the client application.

finally, the third tier is the proper RDBMS, such as interbase or oracle.

so, a multi-tier application isn't just an application that
acess the same database over the LAN ; the application is divided in logical and physical parts. in this 3-tier example, client connects to app server and app server connects to database.

hugs.

 
 
 

Definition for 'Multi-tier' application

Post by Sriram A N » Tue, 02 Sep 2003 23:18:35

ost of the times I prefer to answer this question by giving a little
history on the evolution of databased applications on DOS/Windows
environment.

With the evolution of Network or a group of computers able to communicate
between themselves, application development saw a good deal of progress and
the primary one was - One computer was made to hold all the data and all the
other computers to hold the application that access this common data. The
computer that holds the data was only a File server - which means to say, it
did not do anything with regards to the data as such - but performed one
operation which was transferring the requested files to the requesting
clients. The clients modify data in their memory space and then 'flush' the
changes and update the database file. A simple example for this would be
opening a text file using notepad from a networked machine and then saving
the data. This stage can be called the "Age of Multi-user environment".

Then came the "Age of Client/Server" - or as we call it today 2 - tiered
applications. As it has always been the case in the computer arena, a
continous progress was taking place parallely and technicians saw that it is
better to have designated computers for doing designated jobs mainly with
regards to Database. Some RDBMS like Oracle (for Windows) etc., started off
by accepting commands from the clients and then processing it on the
computer it is running and then giving back the results. A Select statement
for instance, in the earlier age would mean that the table is loaded on the
client first and then filtered with appropriate where conditions - This is
more time consuming and would defeat the purpose of Select statment itself.
In the Client/server age what happens is the Select command reaches the
'Server' and the 'Server' running on Computer 'A' would use the resources of
Computer 'A' and give the 'Result' to the requested client. Also, with the
evolution of Client/Server technolgy based operating system - Windows NT,
Microsoft made the development of server applications more stable and
managable. At this stage as you can see 'Processes' got seggregated - as in
the earlier stage it was only 'Data'.

After this - a more rapid development was taking place with Internet based
applications - This resulted in the same piece of 'code' or 'process' being
requested from different clients under different data accepting environment.
For instance, data was being accepted from an Internet explorer browser for
a web user, to let us say, create a Sales Order and the same data being
accepted in Applications developed using RAD's like Delphi for regular
users. This meant that the process of validating the data were common
between the two and the operations with the database also the same. This led
to the inclusion of one more 'layer' called the 'Application layer'. In this
layer all those common details - what we can call - Business rules and Data
rules exists. Now this would not make the application a 3 - tier - what
should happen is this Application layer must run independently on the
Computer it is installed. That would mean an 'Application server' being
introduced into the picture - The Application server would now accept
'Commands' and relating 'data' associcated with the command - process it and
then give back the details.

This is now a 3-tiered application where in a tier would simply mean a
particular set of designated processes bundled
 
 
 

Definition for 'Multi-tier' application

Post by Alessandro » Wed, 03 Sep 2003 07:17:25

D> Is a multi-tier application simply an application where multiple users
D> are simultaneously accessing the same database over a LAN?

I will answer to this the loooong way :-)

Multi-tier (per-se) means "divided in different tiers" (or layers).

The fact there is (or there isn't a database) and how/where these tiers are
located is secondary althought in practice most examples and documentation
you will find out there refer to 3 tiers running on different machines (of
which the last one is ultimately a database).
Something like this:

Client(s) <---> Application Server <---> Data storage (whatever that is)

Theoretically speaking, multi tier "design" could be applied to pretty much
anything, even client / server applications or an application like notepad.
The most important thing IMO is the separation of responsibilities and
contract-based access to each of the tiers.

For instance, you could have a form which displays a list box and has two
buttons: GetData and UpdateData.
You could have an object called for instance MessageManager implementing the
following interface:

IMessageManager = interface
function GetData(aClientID : string) : string;
procedure UpdateData((aClientID : string; Value : string);
end;

Finally you could have an either (1) and INI file which contains a list of
messages to which MessageManager writes and reads to or (2) an additional
class which interacts with the MessageManager and has an interface like this
one:

IINIReaderWriter = interface
function ReadLine(LineNo) : string;
procedure WriteLine(Value);
procedure UpdateLine(LineNo, NewValue);
end;

The core concept here is that each tier only knows of the closest one and
nothing about the implementation of its functionality.
The form only accesses a MessageManager via an interface, MessageManager
then talks to either IINIReaderWriter or does direct access. Point is that
regardless of that, the client still works.

My 2c

--
Regards,
Alessandro Federici

RemObjects Software, Inc.
http://www.yqcomputer.com/