Three Physical Tiers

102 views
Skip to first unread message

ruffeo

unread,
Mar 4, 2009, 3:21:20 PM3/4/09
to Django users
Does anyone know how to develop a complex django project in a 3 tiered
network environment, still using the MCV architecture?

I.E. Web Server (view and control code), App Server (model code), and
Database Server



Ishwor Gurung

unread,
Mar 4, 2009, 7:58:03 PM3/4/09
to django...@googlegroups.com
Hi

model- representation that needs to be modeled into the db (data model
e.g models.py)

template- your user-facing code so it differentiates how your data is
presented (e.g templates/*)

view- maps your uri specific code to callback functions (e.g in
views.py) which should be resolvable by the URLResolver (to be defined
in URLConf)

MTV - this is what Django calls MVC (in that order)

DB - Django's "python manage.py syncdb" pulls the class definition from
the Model (e.g. models.py) and then inserts them into the DB. This ORM
design is really powerful as we get db<->application_code mapping
essentially for free. A DB can be another tier here that exists seperately.

Web server - Apache, FastCGI, any WSGI-compliant server etc.. (Django
provides lightweight devel server too)

On the topic of Application server, Djangobook.com puts it really nicely -
"At its core, the philosophy of shared nothing is really just the
application of loose coupling to the entire software stack. This
architecture arose in direct response to what was at the time the
prevailing architecture: a monolithic Web application server that
encapsulates the language, database, and Web server — even parts of the
operating system — into a single process (e.g., Java)."[1]

Others could possibly add more to your query (because I've yet to learn
Django properly myself) but from what I've understood Django does not
need a app server!

Cheers,
Ishwor

[1] http://www.djangobook.com/en/1.0/chapter20/

ruffeo

unread,
Mar 4, 2009, 8:43:41 PM3/4/09
to Django users
This was extremely helpful. What about the need to protect the
database from intrusion? Since there is only one hop from the
webserver to the database server (2 tiers). At my job, the school of
thought is that the middle tier is the only server that can access the
database (ip restriction) which is exposed through webservices.That
way there are 3 physical tiers (web, app code, data). I am trying to
apply the same concepts using Django framework.
>  smime.p7s
> 3KViewDownload

Mike Ramirez

unread,
Mar 4, 2009, 9:46:33 PM3/4/09
to django...@googlegroups.com
On Wednesday 04 March 2009 05:43:41 pm ruffeo wrote:
> This was extremely helpful. What about the need to protect the
> database from intrusion? Since there is only one hop from the
> webserver to the database server (2 tiers). At my job, the school of
> thought is that the middle tier is the only server that can access the
> database (ip restriction) which is exposed through webservices.That
> way there are 3 physical tiers (web, app code, data). I am trying to
> apply the same concepts using Django framework.
>

It sounds like you're trying to stop outside direct connections to the
database server. Which can be accomplished in a 2 or more tier configuration.
By having the database server (to clarify, database server refers to the
software, ie. MySQL, postgres, etc...) configured to listen for incoming
request from a white list of ip's (webservers, dba's, etc...). It is that
simple, in addition to configuring the rest of the server correctly. Though
it is probably better to have the actual database server only on the lan and
never directly on the internet.

In a 3 tier system, you want the first tier to be the web server proxy/load
balancer, where you have apache configured with mod_evasive, mod_security
and mod_proxy. mod_proxy sends/recieves (as a reverse proxy) the request
to/from your 'app server', which holds your django+project+httpd server
configuration, the middle tier. The middle tier is only configured like the
database with a white list of ips and should not reside on the internet, only
in a lan that the proxy handles connections for. The third tier of course is
the database configured with it's whitelist.

Here is an article on configuring the first tier server:

http://linuxadministration.wordpress.com/2007/09/06/advance-apache-security-mod_proxymod_securitymod_evasive/

You should also make the first tier server your media server for website in
addition to the security proxy. Serving your css/js/image files as per the
django docs (see MEDIA_URL && MEDIA_ROOT in the django settings, in addition
to serving static files and handling file uploads).

The idea of it having to be a 3 tier system is really not that important. The
two tier system can work the same way, and be just as secure with the correct
server configurations.

Mike

--
Magically turning people's old scalar contexts into list contexts is a
recipe for several kinds of disaster.
-- Larry Wall in <1997092916...@wall.org>

signature.asc

Kevin Teague

unread,
Mar 5, 2009, 5:14:55 PM3/5/09
to Django users
You have to distinguish between "architecture" as it applies to
different types of objects within a single process (also often called
the MVC "pattern") and architecture as it applies to individual
processes and how they communicate with each other. MVC isn't meant to
describe the architecture between individual processes and how they
communicate.

If you want three physical tiers, each tier can have it's own MVC
pattern (or each one can use a totally different pattern). If the "App
Server" is a representation of the model and is only accessible by web
services, then you need Django Models to represent the database model,
and Django Views to expose those models via HTTP.

Then the "Web Server" would have it's own Django Views which consult
Django Models that are backed by web service calls. Finally you'd use
Django Templates for most views to make it easier to separate the
Python from the HTML. Finally the Views and Templates may themselves
contain JavaScript, and that JavaScript code may organize itself into
some MVC pattern ...

Except Django tightly couples it's schema descriptions of models to a
specific persistance layer. If you wanted to re-use the data
description part of the model between relational database backed model
classes and web service backed model classes, I'm not sure if it's
possible - maybe it can be done with a little (or a lot) of
metaclassery? Most likely you'd want to use an external package such
as zope.schema to allow this further seperation of concerns.

Except I'd say that both the MVC pattern and the Three teired
architecture are both very simplisitic ways of modeling a web
application. They tend to fall apart as you start to tailor them to
what you are actually trying to build, the idea of separating the "Web
Server" and "App Server" onto separate physical servers is kind of a
clunky idea that was popular in the dot com era when you had to deploy
onto 200 Mhz boxes. Today servers are fast enough that it's usually
not an issue to deploy the whole stack on a single server ... but it
all depends upon how big you want to scale up to - for example,
Amazon.com makes this split between "Web/presentation" servers (using
Perl/Mason) and "App/web-service-as-model" servers (using Java/SOAP),
and that type of complexity is probably justified for the scale of
their business.

ruffeo

unread,
Mar 6, 2009, 5:50:25 PM3/6/09
to Django users
I guess my question is how do you call a remote model object on a
different web server using Django MTV framework.



On Mar 5, 5:14 pm, Kevin Teague <ke...@bud.ca> wrote:
> On Mar 4, 12:21 pm, ruffeo <timdenni...@gmail.com> wrote:
>
> > Does anyone know how to develop a complex django project in a3tiered
> > network environment, still using the MCV architecture?
>
> > I.E. Web Server (view and control code), App Server (model code), and
> > Database Server
>
> You have to distinguish between "architecture" as it applies to
> different types of objects within a single process (also often called
> the MVC "pattern") and architecture as it applies to individual
> processes and how they communicate with each other. MVC isn't meant to
> describe the architecture between individual processes and how they
> communicate.
>
> If you want threephysicaltiers, each tier can have it's own MVC
> pattern (or each one can use a totally different pattern). If the "App
> Server" is a representation of the model and is only accessible by web
> services, then you need Django Models to represent the database model,
> and Django Views to expose those models via HTTP.
>
> Then the "Web Server" would have it's own Django Views which consult
> Django Models that are backed by web service calls. Finally you'd use
> Django Templates for most views to make it easier to separate the
> Python from the HTML. Finally the Views and Templates may themselves
> contain JavaScript, and that JavaScript code may organize itself into
> some MVC pattern ...
>
> Except Django tightly couples it's schema descriptions of models to a
> specific persistance layer. If you wanted to re-use the data
> description part of the model between relational database backed model
> classes and web service backed model classes, I'm not sure if it's
> possible - maybe it can be done with a little (or a lot) of
> metaclassery? Most likely you'd want to use an external package such
> as zope.schema to allow this further seperation of concerns.
>
> Except I'd say that both the MVC pattern and the Three teired
> architecture are both very simplisitic ways of modeling a web
> application. They tend to fall apart as you start to tailor them to
> what you are actually trying to build, the idea of separating the "Web
> Server" and "App Server" onto separatephysicalservers is kind of a

Ishwor Gurung

unread,
Mar 6, 2009, 6:08:38 PM3/6/09
to django...@googlegroups.com

ruffeo wrote:
> I guess my question is how do you call a remote model object on a
> different web server using Django MTV framework.

I reckon you'd have to use some sort of RPC that translates the call
to/from the remote model but I am not sure if Django provides such
primitive.

Cheers,
Ishwor

Reply all
Reply to author
Forward
0 new messages