Spring의 Dispatcher Servlet

🎀Dispatcher Servlet🎀

매번 서블릿 관련이 나오면 아ㅏ... 음... 그래 서블릿 너무 많이 들어봤는데... 근데 정확하게 뭔지를 모르겠다!!! 답답허다!!!!싶었다. 

그래 오늘이 바로 그날이다....

서블릿을 조져버리는날~..~

간단한 걸 매일 미뤄버려 오늘은 꼭 흩어져있는 지식들을 헤쳐모여 시켜서 합체시켜서 이해해야겠다.

 

 

1. what's Dispatcher Servlet?

: HTTP 프로토콜로 들어오는 모든 요청을 가장 먼저 받아 적합한 컨트롤러에 위임해주는 프론트 컨트롤러이다. 

 

만약, 클라이언트로부터 요청이 오면 > 톰캣과 같은 서블릿 컨테이너가 요청을 받는다. > 이 모든 요청을 디스패처 서블릿이 가장 먼저 받게 된다 > 이친구가 공통적인 작업을 먼저 처리한 후, 해당 요청을 처리해야 하는 컨트롤러를 찾아 작업을 위임한다. 

 

음 쉽게 생각하면 

선생님이 >> 반장에게 요청 (우리반 누구누구 설문조사 해와라) >> 하면 반장은 >> 우리반 누구누구에게 가서 그 요청을 전달하고 >> 다시 설문조사 받아와서 >> 다시 선생님께 전달.

이런 과정에서 반장이 바로 Dispatcher Servlet이다. 

 

그렇다면 모든 요청을 처리할 때 어떻게 정적 자원 요청(V)과 애플리케이션 요청(C)을 구분할까? 

Dispatcher Servlet이 요청을 처리할 컨트롤러를 먼저 찾아보는데, 이 요청에 대한 컨트롤러가 없는 경우 > 2차로 Resource 경로를 탐색하여 정적 자원을 탐색하게 된다. 

 

 

- 발전 과정

1) 각 요청에 따른 서블릿 등록 및 매핑

원래 과거에는 요청에 따른 서블릿이 존재했고, 이 서블릿을 모두 web.xml에 url 매핑하여 등록해주어야 했다. 

ex) /myurl 로 들어오는 요청을 처리하는 서블릿 등록 및 매핑    + 만약 다른 url이다? 그럼 또 새로 매핑해주어야 함. ㅠㅡㅠ 귀찮아!!

<!-- web.xml -->

<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
                             http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
         version="3.1">

    <display-name>MyWebApp</display-name>

    <!-- Servlet Configuration -->
    <servlet>
        <servlet-name>myServlet</servlet-name>
        <servlet-class>com.example.MyServlet</servlet-class>
    </servlet>

    <!-- Servlet Mapping -->
    <servlet-mapping>
        <servlet-name>myServlet</servlet-name>
        <url-pattern>/myurl</url-pattern>
    </servlet-mapping>

</web-app>

 

2) Spring MVC의 Dispatcher Servlet 등장 & web.xml에 매핑

이러한 불편함을 해결한 것이 "dispatcher servlet"이다. (얘가 모든 요청을 핸들링하고, 공통 작업을 처리해주고, 요청을 나눠주는 역할인 것!!!) 

ex) dispatcher를 설정 및 매핑

// web.xml

<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
                             http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
         version="3.1">

    <display-name>MySpringApp</display-name>

    <!-- Configuring the Dispatcher Servlet -->
    <servlet>
        <servlet-name>dispatcher</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <init-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>/WEB-INF/spring-mvc-servlet.xml</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>dispatcher</servlet-name>
        <url-pattern>/</url-pattern>
    </servlet-mapping>

</web-app>

 

3) 스프링 부트 등장 & 자동으로 Dispatcher Servlet 등록

그리고 스프링 부트에서는 이러한 "web.xml" 파일 없이도 자동으로 Dispatcher Servlet이 설정되게 되었다. @SpringBootApplication 어노테이션이 붙은 메인 클래스에서 자동으로 설정된다!! 

 

 

public class DispatcherServlet 
	extends FrameworkServlet {...}

public abstract class FrameworkServlet 
	extends HttpServletBean 
    	implements ApplicationContextAware {...}

public abstract class HttpServletBean 
	extends HttpServlet 
    	implements EnvironmentCapable, EnvironmentAware {...}
        
public abstract class HttpServlet 
	extends GenericServlet {...}

>> 상속 구조를 보면 DispatcherServlet은 결국 타고타고 들어가면 HttpServlet을 상속받는다. 

 

2. Dispatcher Servlet의 동작 과정

1) 클라이언트 요청을 디스패처 서블릿이 받는다.

- 서블릿 컨텍스트(웹 컨텍스트)에서 ~ 필터들을 지나 ~ 스프링 컨텍스트에서 디스패처 서블릿이 요청을 받게 된다. (실제로는 인터셉터가 컨트롤러로 요청을 위임하지는 않는다. 그림은 처리 순서를 도식화한 것)

 

2) 요청 정보를 통해 요청을 위임할 컨트롤러를 찾는다.

- 이때 가장 먼저 어느 컨트롤러가 요청을 처리할 수 있는지 찾아야 하는데, 이 역할을 HandlerMapping이 해준다. 그래서 스프링은 HandlerMapping 인터페이스를 만들고, 다양한 구현 방법에 따라 요청을 처리할 대상을 찾도록 되어있다.

- 이 HandlerMapping 인터페이스를 구현한 것이 RequestMappingHandlerMapping이다.

: 컨트롤러 클래스에서 @RequestMapping 어노테이션이 달려있는 메서드의 RequestMappingInfo 인스턴스를 만든다.

 

그리고 얘를 타고타고 들어가다보면 AbstractHandlerMapping이 나오는데, 여기에서 given request에 대한 Handler를 찾는 메서드가 있다. 

 

- 여기서 HandlerExecutionChain으로 감싸서 반환하게 된다. (이유는 컨트롤러로 요청을 넘겨주기 전에 처리해야하는 인터셉터 등을 포함하기 위해서)

 

3) 요청을 컨트롤러로 위임할 핸들러 어댑터를 찾아서 전달한다.

이제 요청을 바로 컨트롤러로 위임하는 것이 아니라 HandlerAdapter를 통해 위임하게 된다. 

- 이친구가 각 요청에 따라 implementation되게 된다. 어떤 코드 방식이든 상관없이! 

 

4) 핸들러 어댑터가 컨트롤러로 요청을 위임한다.

: 요청을 위임한 전/후에 공통적인 전/후처리가 필요하다. 

 

5) 컨트롤러에서 비즈니스 로직을 처리한 후 반환값을 반환한다.

: 컨트롤러는 서비스를 호출하고 개발자가 작성한 비즈니스 로직들을 진행하고 처리 이후 반환값을 반환한다.

주로 ResponseEntity로 반환하고, 응답 페이지는 String으로 View의 이름을 반환하기도 한다. 

 

6) 핸들러 어댑터가 반환값을 처리한다.

- 만약 ResponseEntity가 반환되었다면 HttpEntityMethodProcessor가 MessageConverter를 사용해 응답 객체를 직렬화하고, 응답 상태를 설정한다.

- 만약 View가 반환되었다면 ViewResolver를 통해 View를 반환한다. 

 

7)  디스패처 서블릿이 서버의 응답을 클라이언트로 반환한다. 

- 다시 필터들을 거쳐 클라이언트에게 반환된다. 

 

 

---

 

드디어 뭔가 어떤 방식으로 요청을 받고 처리하는지 알 것 같기도.............. 또 헤쳐모여 하는 구간이 오겠지!? ㅎㅅㅎ 

 

 

일단 오늘 기억할 것은!

🌟디스패처 서블릿은 반장같은 역할 ! 모든 요청을 처리하고 위임한다.

그 끝에는 HttpServlet이 있다! 

 

HandlerMapping은 어떤 핸들러로 요청을 처리할까? 결정

HandlerAdapter는 요청을 맞는 컨트롤러로 위임해주는 역할