1. 태초에, Web Server가 있었다
- Client가 Web Server에 컨텐츠를 요청하면, Web Server에서는 정적 컨텐츠만 제공할 수 있었습니다.
2. WAS (Web Application Server)
정적 컨텐츠만으로는 한계가 있었다.
- Web Server만으로는 동적 컨텐츠를 제공할 수 없었기에, WAS가 등장하게 된 것입니다.
-
Web Application Server의 구성
-
Web Server : 위의 Web Server와 동일합니다.
-
Web Container : CGI(Common Gateway Interface)와 상호작용하여 동적인 컨텐츠를 생성합니다.
-
-
WAS가 있음에도 Web Server를 유지하는 이유
-
WAS 내에는 Web Server가 내장되어 있습니다.
-
그럼에도 불구하고, WAS에서 Web Server를 사용하는 것이 아니라 따로 Web Server를 두면 다음과 같은 이점들을 얻을 수 있습니다.
-
Web server와 WAS의 물리적 분리를 통한 보안 획득
-
정적 페이지에 대한 요청은 Web Server가 담당하게 하여 WAS의 부하를 줄여줄 수 있음
-
Web Server가 여러 개의 WAS를 관리하게 하여 부하 분산
-
failover(WAS 서버 장애 시, 다른 WAS에 요청 전달), failback(장애 발생한 WAS 재시동)이 가능
-
-
-
CGI란?
- CGI는 웹 서버에서 백엔드 서버의 프로그램을 사용하는 방식을 정의한 것입니다.
- 즉 이는 하나의 규약이고, 이 때문에 interface로 명명되는 것입니다.
3. Servlet
CGI 기술을 자바 언어로 작성한 것이 바로 Servlet입니다.
-
WAS는 Servlet Container를 통해 Servlet의 생명주기를 관리합니다
-
Servlet Container는 사용자의 요청에 따라 적절한 구현체를 다음과 같은 과정을 통해 관리합니다
-
생성 : init()
-
doXXX : Servlet 구현체에서 doXXX에 대해 정의된 로직을 수행하도록 함
-
파괴 : destroy()
-
-
Servlet Container가 적절한 Servlet 구현체를 매핑하는 방법
: 개발자는 직접 web.xml 파일에 다음과 같은 내용을 정의해야 합니다-
서블릿 클래스를 서블릿으로 등록
-
해당 서블릿을 참조할 때 사용할 이름
-
서블릿으로 사용할 서블릿 클래스의 FullName
-
매핑할 서블릿의 이름
-
매핑할 URL 패턴
-
4. Spring MVC의 등장
-
Servlet Container에서 바로 Servlet으로 매핑할 때는 MVC 패턴을 분리해내기가 어려웠습니다
-
Spring MVC는 위와 같은 방식으로, Dispatcher Servlet이 모든 Servlet 요청을 받아서 적절한 컨트롤러와 뷰를 매핑합니다
-
View Template
- JSP, Thymeleaf 등은 java 코드로 html을 작성하는 불편함을 덜어줍니다
- java에서 문자열 방식으로 html을 작성하면 정말 많은 오류들이 발생할텐데, 이를 뷰 템플릿을 사용함으로서 극복하는 것입니다
- 뷰 템플릿은 컨트롤러가 반환한 model(데이터, 혹은 값)과 html로 작성된 뷰를 합쳐서 사용자가 보게 될 정적 콘텐츠를 생성합니다
5. Spring Boot
- 스프링 부트는 다양한 설정들을 default로 하여 설정해줍니다
- 스프링 부트에서는 web.xml 파일을 작성하지 않고 annotation 방식으로 매핑할 수 있습니다
