even before the web (!),
there were interactive applications using databases...
*   people discussed the basic components of such systems;

    *   presentation component - what the users
        see and interact with

    *   application component - business logic/domain logic;
        the software parts that implement business rules

    *   database software component - usually provided
        by a commercial database product, by a DBMS

*   1-tier applications - monolithic;
    *   all of these components done on a single
        processor (combined, essentially);

    *   not really a concept of these components
        being logically separated

*   2-tier applications - using the classic
    client-server architecture;

    for these, TYPICALLY, servers are typically file and
    database servers (application servers aren't in play yet)

    *   presentation component is typically on the
        client

    *   database software component is typically on
        the database server

    *   WHERE does the application component go?
        COULD go on the client side,
	COULD go on the database server side,
	COULD be bits and pieces on both sides,

	BUT, in practice (I'm told) it tended to
	mostly be on the client side

	(I believe this is a so-called
	"fat client" architecture)

        *   harder to maintain than desired
	    (ALL application and presentation
	    components on EACH client --
	    imagine when different OSs are
	    involved, or business rules or
	    application assumptions change, etc.)

        *   can be harder to secure

        *   can be harder to update

	*   can (potentially) lead to increased network
	    load

3-tier and n-tier and 3+-tier and multitier architectures
try to IMPROVE on this;
*   have one or more application servers
    BETWEEN the client, with the presentation 
    component,
    and the data server, with the DBMS

    ...and (ideally!! not always in reality)
    you put the application logic/business rules support
    on the application tier(s)

    [NOTE: with n-tier applications - in this class -
    don't just say "server" <-- multiple servers are
    	       	   	        involved!

    need to specify at least "application server" or
    "data server" or...]

    *   moving the application logic TO on or more
        "application" servers (at least logivally)
	separate and distinct from the data server

*   SO - in this approach, ideally:
    *   client tier - is responsible for presentation
        of data, receiving user events and
	controlling the user interface

    *   application tier(s) - business-objects that implement
        the business rules "live" here, and are AVAILABLE to
	the client tier, BUT this tier protects the data
	from DIRECT access by the clients;

    *   data tier - your DBMS is here

*   advantages and disadvantages of n-tier architecture:
    *   might be easier to design, debug, and maintain
        systems with a clean logical separation
	of presentation, application, and data components;

    *   can modify the application component without
        necessarily having to modify the presentation
	and data components

    *   might be easier to protect/secute application
        data and application logic on their tier
	(than it would be if these were distributed
	amongst the clients)
	
    *   but data tier is a single source of failure,
        as is the application tier(s);

    *   AND you have the time it takes to communicate
        BETWEEN the tiers

*   (middleware - defined is different ways in different
    sub-areas of CS --
    software connecting these tiers...)

*   PL/SQL