서블릿 (servlet)

• 서블릿 (servlet)
  • 웹프로그래밍에서 클라이언트의 요청을 처리하고 그 결과를 다시 클라이언트에게 전송하는 Servlet 클래스의 구현 규칙을 지킨 자바 프로그래밍 기술
    • 간단히 말해서, 서블릿이란 자바를 사용하여 웹을 만들기 위해 필요한 기술
    • 클라이언트가 어떠한 요청을 하면 그에 대한 결과를 다시 전송해주어야 하는데, 이러한 역할을 하는 자바 프로그램
  • 웹 어플리케이션 개발용 스펙과 API 제공
  • 한 요청을 처리할 때 마다 새로운 프로세스를 만들고 죽이는 프로세스가 아니라 한 프로세스를 공유하는 쓰레드를 만들어서 요청을 처리함
    • 때문에 기존에 사용하던 ( common gateway interface ) 보다
    • 빠르고 보안이 좋다
      • 자바 자체가 가지고 있는 보안
      • 컨테이너가 지원하는 보안과 관련된 각종 기능들..
    • 이식성, 플랫폼 독립성이 좋다
• 서블릿 엔진 또는 서블릿 컨테이너 (톰캣, 제티, 언더토우 …)
  • 서블릿 엔진(서블릿 컨테이너)이란 서블릿 스펙을 구현한 서블릿 컨테이너다.
  • 실제 서블릿을 어떻게 초기화하고 실행하고 할지 라이프 사이클을 알고있다.
  • 세션관리
  • 네트워크 서비스
  • MIME 기반 메시지 인코딩, 디코딩
  • 서블릿 생명주기 관리
• 서블릿 생명주기
  • 우리가 직접 실행 불가
  • 서블릿 컨테이너가 실행해준다.
  • 우리는 그래서 서블릿 컨테이너를 사용해야한다.
  • 서블릿 컨테이너가 서블릿을 실행하는 방법 (생명주기)
    • init()
      • 최초 요청을 받았을 때
      • 한번 초기화 하고 나면 그 다음 요청부터는 이 과정을 생략
      • 서블릿이 초기화 된 다음부터 클라이언트의 요청을 처리할 수 있다.
      • 각 요청은 별도의 쓰레드로 처리하고 이때 서블릿 인스턴스의 service() 메소드를 호출한다.
        • service() 안에서 HTTP 요청을 받고 클라이언트로 보낼 HTTP 응답을 만든다.
        • service()는 보통 HTTP Method에 따라 doGet(), doPost() 등으로 처리를 위임한다.
        • 따라서 보통 doGet(), doPost()를 구현한다.
    • doGet() / doPost() …
    • 서블릿 컨테이너 판단에 따라 해당 서블릿을 메모리에서 내려야 할 시점에 destroy()를 호출한다.
• 서블릿 리스너와 서블릿 필터
  • 서블릿 리스너 ( 서블릿 컨테이너 위에 존재하는 개념 )
    • 서블릿 컨테이너에서 발생하는 이벤트를 감지하는 것
      • 서블릿 컨텍스트 수준의 이벤트
        • 컨텍스트 라이프사이클 이벤트 (ServletContextListener)
        • 컨텍스트 애트리뷰트 변경 이벤트
      • 세션 수준의 이벤트
        • 세션 라이프사이클 이벤트
        • 세션 애트리뷰트 변경 이벤트
    • 특정한 이벤트에 특정 코드를 실행해야 할 때 사용한다.
    • 예를들면, 서블릿 컨테이너가 구동이될때 DB 커넥션을 맺는다. 그리고 그 커넥션을 각각의 서블릿에 제공을해준다.
    • 서블릿 컨텍스트라는 곳에 들어있는 어트리뷰트에 저장을 해서 사용하는게 일반적
  • 서블릿 필터 ( 서블릿 컨테이너가 요청을 받았을때 그리고 서블릿으로 보내기 전에 사이 )
    • 들어온 요청을 서블릿에 보내고, 또 서블릿이 작성한 응답을 클라이언트로 보내기 전에 특별한 처리가 필요한 경우에 사용
    • 체인 형태의 구조 (순차적)
    • 
• 서블릿 프로젝트에 spring을 사용해볼까?
  • 스프링이 사용하는 IOC 컨테이너 기능을 사용하고 싶다?
    • (완전 정확한건 아니지만) Spring 컨테이너 == 어플리케이션 컨텍스트 == ApplicationContext (BeanFactory)
    • 리스너를 사용해서 한다.
      • 스프링 같은 경우에는 spring이 제공해주는 ContextLoaderLisenter 가 있고
        • 참고로 ContextLoaderLisenter는 설정파일이 필요하다 ( context-param )
      • Spring 컨터이너를 서블릿 생명주기에 맞춰서 서블릿들이 사용할 수 있도록 ApplicationContext를 서블릿 컨텍스트에 등록을 해준다.
      • 그래서 빈들을 관리하고 빈을 주입하는 ApplicationContext를 각각의 서블릿들이 사용할 수 있게 된다.
  • 스프링이 제공하는 Web MVC 기능을 사용하고 싶다?..
• Front Controller 패턴
  • 순서 : 리스너 → 서블릿 컨테이너
  • 컨트롤러 하나가 모든 요청을 받아서 각각의 컨트롤러에게 분배(dispatch)해주는 패턴
    • 매번 서블릿을 만들 수 없으니깐 필요.
    • 서블릿 마다 공통적으로 처리할 내용들이 있으니깐 필요.
    • 
  • 스프링이 front controller(dispatch) 역할을 하는 서블릿을 이미 구현을 해둠
    • **이것이 바로 DispatcherServlet ← spring web mvc의 핵심 **
    • DispatcherServlet이 front controller 역할로 각각의 서블릿을 만들지만 그렇게 만들어진 서블릿들의 상위에는 RootWebApplicationContext가 상속구조로 존재한다.
      • DispatcherServlet을 통해 만들어진 서블릿들은 또 다른 디스패쳐 서블릿을 통해 만들어진 다른 디스패쳐 서블릿에 등록되어 있는 빈들을 공유할 수 없다. 다른 어플리케이션 컨텍스트 스코프 이기 때문이다.
      • 그 빈을 공유하고 싶은 경우가 있기에 그런 경우를 커버하기 위해서 상속구조로 만들어져 있다.
      • 그래서 RootWebApplicationContext에는 주로 웹과 관련된 빈은 등록되어있지 않는다.
      • 
      • 그림을 보면 RootWebApplicationContext 쪽에서는 service와 repository 빈들이 있는데 이유는 다른 웹과 관련된 디스패쳐 서블릿에서도 공유해야 하기 때문에
• DispatcherServlet 동작 원리
  • DispatcherServlet 초기화
    • 다음의 특별한 타입의 빈들을 찾거나, 기본 전략에 해당하는 빈들을 등록한다.
    • HandlerMapping: 핸들러를 찾아주는 인터페이스
    • HandlerAdapter: 핸들러를 실행하는 인터페이스
    • HandlerExceptionResolver
    • ViewResolver
    • ….
  • DispatcherServlet 동작 순서
    1. 요청을 분석한다. (locale, theme, multipart 등)
    2. (핸들러 맵핑에게 위임하여) 요청을 처리할 핸들러를 찾는다.
    3. (등록되어 있는 핸들러 어댑터 중에) 해당 핸들러를 실행할 수 있는 핸들러 어댑터를 찾는다.
    4. 찾아낸 핸들러 어댑터를 사용해서 핸들러의 응답을 처리한다. - 핸들러의 리턴값을 보고 어떻게 처리할지 판단한다. - 뷰 이름에 해당하는 뷰를 찾아서 모델 데이터를 랜더링한다. - @ResponseEntity가 있다면 Converter를 사용해서 응답 본문을 만들고.
    5. (부가적으로) 예외가 발생했다면, 예외 처리 핸들러에 요청 처리를 위임한다.
    6. 최종적으로 응답을 보낸다.

백기선님의 스프링MVC 강의를 들으면서.. 메모한 내용입니다. :pray: