Servlet VS. Spring

✏️ Servlet

Web Application 을 만들 때 필요한 인터페이스이다.

📍 Spring Web MVC

• Spring Framework 가 제공하는 MVC 패턴을 사용한 Web Service 제작기능
• Spring Web MVC 는 Swervlet 을 사용해 Web Application 을 제작한다.
• Spring Web MVC 는 Dispatcher Servlet 프레임워크를 사용하고 있다.
  • 🔗 Dispatcher Servlet

📍 Servlet 의 역사

• 초기 웹 서버
  • 초기의 웹 서버는 정적 HTML 만을 전달하는 기능만 있었다.
  • 따라서 클라이언트를 식별할 수 있는 기능도 없었다.
• CGI 인터페이스의 등장
  • CGI 구현체는 동적 Data 를 처리하는 인터페이스이다.
  • 동적 data 를 구현하기 위해 C 언어, PHP 등 다양한 언어가 사용되었다.
    • 다양한 언어를 처리하기 위해 Web Server 와 프로그램들 사이에 규약이 필요했고,
      문제를 해결하기 위해 CGI 인터페이스 (규약) 이 등장하게 됬다.
  • 클라이언트의 식별이 가능하게 되었다.
• CGI 의 문제점
  • 요청이 들어올 때 마다 Process 가 만들어졌다.
    • 이 문제점은 Thread 로 대체해서 해결했다.
    • 🔗 Process VS. Thread
  • 같은 구현체를 사용해도 요청 (Thread) 이 다르면 새로운 구현체가 생성되었다.
• Servlet 인터페이스의 등장
  • CGI 의 문제점을 해결하기 위해서 Servlet 이 등장하게 되었다.
    • Servlet 은 Singtone 패턴을 사용하기 때문에 불필요한 구현체가 생성되지 않는다.
  • Servlet 과 함께 Web Application Server 도 같이 등장했다.
    • 🔗 Web Server VS. Web Application Server
    • 클라이언트의 요청이 정적 data 면 Web Server 가 응답한다.
    • 동적 data 라면 WAS (Web Application server) 가 응답한다.
    • WAS 의 Web Container 는 요청마다 Thread 를 만들고,
      Thread 와 Servlet 구현체를 연결시켜 주었다.
  • Servlet 인터페이스에 정의된 Method
    • Init - Servlet 인스턴스 생성
    • Service - 실제 기능이 수행
    • Destroy - Servlet 인터페이스를 종료

✏️ Spring Web MVC 의 역할

📍 Spring Web MVC 가 없을 때

• url 마다 서블릿이 하나씩 필요했다.
• 하나의 요청을 처리하기 위해서 그 method 를 담당하는 Servlet 만 만들고 싶어도
  하나의 서블릿 인스턴스가 필요했었다.
• 서블릿 구현부터 View 에서 응답하는 작업까지 전부 구현해야 했다.

📍 Spring Web MVC

• 하나의 서블릿에서 모든 요청을 받고,
  핸들러 매핑과 어댑터 를 분석해
  필요한 Controller 만 생성할 수 있게 바뀌었다.
• 개발자는 Controller 만 구현하면 응답을 포함한 나머지 모든 작업을 MVC 가 대신 해준다.