Is Python fit for multi-tiEred apps?

[Steve Holden]

In distributed computing applications, the original architecture was
client/server. Typically the client was the desktop machine, which handled
the GUI and usually most of the process logic and some of the application
logic. The client would communicate across the network to a server, which
would handle the remainder of the application logic and all the data
management tasks.

Conceptually, applications therefore have four components:

Presentation (user interface) logic
Process logic
Application logic ("business rules")
Data Management

Nowadays the logic can be distributed between more than two machines, so you
might see the GUI running on the desktop along with the process logic, the
business rules being enforced by a "middle tier" server, and the data
management handled by an enterprise RDBMS. This is the "classic" three-tier
structure.

Another three-tier example is when a browser (presentation layer) is used to
drive a web server (process logic, application logic) which transacts
against an RDBMS (data management).

The advantage of these architectures is that you can centralise or
distribute the business rules as you see fit, but that you don't have to do
what traditional C/S applications did, which was to include business rule
handling on the desktop. This became a maintenance nightmare for large
organizations with hundreds or thousands of desktops: when the business
rules changed, new client software had to be rolled out to all the desktops.

regards
 Steve
--
http://www.holdenweb.com/


"François Pinard" <pinard at iro.umontreal.ca> wrote in message
news:mailman.1001606015.16060.python-list at python.org...
> [Eike Kock]
>
> > [...] scaleable enterprise systems (multi-tiered [...]
>
> Hi.  Would someone be kind enough for presenting to me what `tiered'
means?
> I never read that word, before the recent threads about it.  What is it?
>
> --
> François Pinard   http://www.iro.umontreal.ca/~pinard
>