웹 어플리케이션이 나오기까지

이번 시간엔 웹 어플리케이션이 나오게 되기까지 과정을 알아보자.

데스크톱 애플리케이션

1. PC에 설치되어 실행되 웹 애플리케이션 보다 실행속도가 빠름.
    - office, 컴퓨터 게임 등등...
2. 문제점
  - 배포의 번거로움.
  - 보안에 취약 : 데이터 베이스에 접근할 때 취약 가능성
  - 애플리케이션 실행할 때 먼저 서버에 갱신된 버전이 있는지 조회 후 실행하면 어느정도 해결됨.
  - 단 보안에 취약...
 

클라이언트'서버 애플리케이션

  - 애플리케이션의 기능을 서버와 클라이언트로 분리.
  - 장점
    - 새로 프로그램이 수정 되도 서버 쪽만 변경하면 됨.
    - 기능 변경/추가에 유연하게 대처가 됨.
  - 문제점 개선 방안
    - 한번에 하나의 클라이언트 하고만 연결 됨.
    - 멀티 프로세스와 멀티 스레드로 위 문제를 해결한다.
  - 멀티 프로세스와 멀티 스레드
    - 멀티 프로세스는 원본 프로세스의 메모리를 모두 복제해 자원 낭비가 심함.
    - 멀티 쓰레드는 전체 메모리를 복제할 필요가 없음.
   

다중 클라이언트 요청 처리

  - 클라이언트의 요청 처리 부분을 별도의 작업으로 분리
  - 분리된 작업은 스레드에 정의
  - 다중 클라리언트 요청이 병행 처리됨.
  - C/S 환경의 프로그래밍이 복잡해지는 문제가 생김.
 

클라이언트'서버 아키텍처의 진화

1. 전통적인 클라이언트'서버 아키텍처
    - 서버는 데이터 처리를 맡고 클라이언트는 UI와 비즈니스를 처리했다.
    - 단점
        - 프로그램이 변경되면 PC에 다시 설치해야됨...
        - 클라이언트가 DBMS로 바로 접속해 보안 문제 발생.
       
2. 개선된 클라이언트'서버 아키텍처
    - 클라이언트의 업무 처리부분은 서버로 이관.
    - 클라이언트는 오직 UI만 담당.
    - 서버로부터 결과를 받으면 클라이언트에서 화면을 꾸며 뿌려줌.
    - 애플리케이션 서버?
        - 업무를 전담하게된 서버를 애플리케이션 서버라 부른다.
        - 클라이언트로부터 요청을 받으면 업무 로직에 따라 DBMS 서버를 사용해 데이터를 처리.
        - 클라이언트 접근제어도 함꼐 처리.
    - 서버에 기능이 변경 되도 바로 클라이언트에 적용할 수 있다.

웹 애플리케이션 아키텍처

1. 특징
    - 클라이언트와 통신은 웹 서버가 전담
    - 애플리케이션 서버는 애플리케이션 서버 실행 및 관리에 집중.
    - 비즈니스 로직과 UI 로직을 모두 서버에 배치되 추가 변경되도 서버만 바꾸믄 된다.
    - 단 웹 환경에선 애플리케이션 실행할 때마다 UI로직을 내려받기 때문에 오버헤드 발생.
    - 멀티 스레드 부분을 웹 브라우저와 웹 서버가 알아서 해줌.
   
2. 서버쪽
    - HttpServlet 클래스르르 상속받고 있다.
    - doGet() / doPost()를 재정의 한다.
   
3. 화면관련 오버헤드는 어떻게 극복할까?
    - AJAX
        - 같은 화면에서 데이터만 바뀔 때 서버에 UI 전체를 받아오기 보다, 데이터만 받아온다.
         
웹 처음 시작할 때 보았던 부분인데, 웹을 처음 시작할 당시 아 이렇구나.. 라는 감만 있었다.
양파껍질 스터디를 하고, 또 여러 프로젝트를 진행한 결과 웹 애플리케이션의 흐름이 한눈에 들어오기 시작했다.
 결론은 프로젝트도 많이 하고 책도 많이 읽고, 시간 지나고나서 느낌 좋았던책 다시 읽어보자!

끝~!!