=====
CS 328 - Week 1 Lecture "2" - 2026-01-21
=====

TODAY WE WILL:
*   intros/seeing whose here
*   intro CS 328's "big idea"
*   SOME syllabus highlights
*   public course site/Canvas site
*   basic course structure
*   clickers!
*   emergency preparedness
*   if time: n-tier architecture for
    interactive applications
*   prep for next class

=====
current reading assignment:
=====
*   read through the COURSE SYLLABUS (posted from several locations
    on both the course Canvas site and the public course web site)
    *   be prepared to answer Canvas questions about it as part
        of Homework 1

*   in the course Canvas site,
    click on "Modules" on the left-hand-side,
    go to the "zyBooks activities" section,
    and CLICK on the "Chapter 01 - HTML Fundamentals" link
    to BOTH:
    *   SUBSCRIBE to the course zyBooks text
    *   reach the first zyBooks assigned reading and activities,
        for Chapter 01

    *   (do NOT go to the zyBooks website and create a new account!)
    
=====
Software architecture
=====
*   from Jalote, "A Concise Intro to Software Engineering", p. 95:

    software architecture:

    "...the subsystems that should compose [a complex software]
    system, the interfaces of these subsystems, and the rules for
    interaction between the subsystems"

*   an n-tier (or 3-tier, or n+-tier) is ONE of
    several common options for the software architecture
    for web applications that make use of database(s)

=====
n-tier architectures for interactive applications
====
*   leading up to these:

*   traditional components of an interactive application
    using a database (even pre-web...!):
    1.  Presentation component - what user sees, interacts
        with

    2.  Application component - the business logic - the
        software component that implements a scenario's business
	rules

    3.  Database component - the database software; usually/typically
        a DBMS (database management system)

*   1-tier architecture for such an application:
    all of these components are combined, perhaps without clear
    separation, typically "in one place"
    (frequently on a single processor, frequently not very logically
    separated)

*   2-tier architecture for such an application:
    classic client-server architecture!

    *   in general, a client-server architecture has a
        client tier and a server tier --
	where the server is frequently providing some
	service useful to be shared
	(a print server, a file server, a database server,
	a web server, etc.!)
	*   a process on the client tier may want and request a service
	    by sending a request to the server tier

        *   and a process on the server tier responds to
	    that request, and performs desired action(s)
	    as a result

    *   so: consider a 2-tier, client-server architecture
        approach to an interactive application that
	happens to use a database...

        for classic client-server,
        *   typically put the presentation components on
	    the client tier

        *   typically put the database components -- for example,
	    a DBMS -- on its own tier, as the server tier

        *   ...but where do the application components go,
	    if you use a classic 2-tier client-server architecture
	    for an interactive application involving a database?
	    
	    ...not as neat and obvious a choice for application
	    component parts!

            client                  server
        ----------------       ------------------
        | presentation | <---> | database       |
	| component    |       | component      |
        ----------------       ------------------

                  ^       ^       ^
		  |       |       |
		  application component??

                  ...could be on either tier, could be on both...!

                  ...not as neat and obvious a choice for where these
		     should go, using a 2-tier/client-server software
		     architecture;

*   issues with 2-tier (and 1-tier) architectures for
    these interactice applications making use of a database
    helped lead to development of 3-tier/n-tier/n+-tier architectures
    for these systems as a possible improvement.

          client tier          application tier(s)          data tier
        ----------------       ------------------        ----------------
        | presentation | <---> | application    | <--->  |  database    |
	| component    |       | component(s)   |        |  component   |
        ----------------       ------------------        ----------------

    *   client tier - has the presentation component;
        *   is responsible for presentation of data
        *   receives user events
	*   controls the user interface

    *   application tier(s) - has the application component(s)
        *   the business object(s) that implement the
	    business rules go here;
	    application logic/business rules reside here
	*   (so might software components that monage that logic
	    and manage the interaction between the tiers)
        *   and also protects the data tier from direct access
            by the client tier;

    *   data tier - has the database component
        *   your DBMS is here

*   over time and experience, the actual software architecture
    for such interactive applications, now frequently web
    applications or browser-based applications, that use
    database(s) might not be QUITE so neat/clear-cut;
    *   might be security or performance or other reasons that
        SOME application logic might still creep onto the
	client tier,

        or that SOME application logic might still creep onto
	the data tier,

	as we'll discuss as the semester proceeds.