그래서, 서블릿(Servlet)이 뭔데?

그래서, 서블릿(Servlet)이 뭔데?

그래서, 서블릿(Servlet)이 뭔데?

자바, 스프링 프레임워크를 사용하면서 기존에 개발되어 있는 프로젝트를 그대로 사용했다. 이미 누군가가 잘 만들어놓았고 새로운 프로젝트를 구성할 때에도 기존에 있는 프로젝트를 그대로 사용하면 문제가 없었다. 새로운 기능을 추가하거나 기존에 로직을 변경할 때에도 문제가 없었다. 기능을 구현하기에 어떻게 하는지는 이미 누군가가 만들어 놓았기 때문에 그대로 따라하면 되기 때문이다. 그런데 그러면 나는 개발자라고 할 수 있을까?

적어도 지금까지는 큰 문제가 없었다. 아니 있어도 문제라고 해주는 사람이 없다. 이렇게 고이고 고여 썩은 물이 되어 나중에는 어느 치킨 프랜차이즈가 더 좋을지 고민 하겠지.

누군가가 서블릿에 대해 물었을 때 ‘그게 뭐지’라고 되물어었는데, 이러면 안될 것 같아 정리를 해보았다.

서블릿

‘사용자가 데이터베이스에 있는 데이터를 가져오고 싶어한다.’라고 생각해보자.

서블릿은 사용자로부터 요청을 받고 필요한 일련의 작업을 한 다음, 사용자가 필요로한 데이터를 반환한다. 한마디로 서블릿은 사용자의 요청을 처리하고 응답한다.

서블릿은 앞서 말했듯이 사용자의 요청을 처리하고 사용자에게 응답하는 구조를 가진 하나의 인터페이스이다. 웹 프로그래밍을 통해 개발자는 서블릿의 인터페이스를 이용하여 각각의 요구 사항에 맞는 로직을 구현한다. 구현한 여러 서블릿을 이용하여 사용자가 요청하는 다양한 데이터를 처리 및 응답한다.

구현한 서블릿은 오롯이 혼자 동작하지 않는다. 서블릿은 서블릿 엔진에서 실행된다.

Reference

서블릿 컨테이너

앞서 말했듯이 서블릿은 서블릿 엔진을 통해 관리된다. 그렇다면 서블릿 컨테이너는 무엇일까?

지금까지 찾아본 바로는 서블릿 엔진과 서블릿 컨데이터는 동일한 개념으로 생각해도 무방할 듯 싶다. 내가 여태 사용하고 있었던 톰캣이 이 역할을 담당한다.

서블릿 컨테이너는 사용자의 요청이 들어오면 요청에 맞는 서블릿을 생성 및 할당을 한다. 그리고 요청을 처리한 다음에는 생성한 서블릿을 제거해주고 있다. 전반적인 서블릿 관리를 담당한다.

한 가지 유의할 점은 서블릿을 생성할 때마다 프로세스를 만드는 것이 아니라 쓰레드 단위로 생성한다는 점이다. 프로세스보다 쓰레드의 리소스 측면에서 장점이 있다. 이 부분에 대해서는 더 깊이 찾아봐야 한다.

한 가지 궁금한 부분이 있다. 웹 서버와 웹 애플리케이션 서버는 다른 의미일까?

웹 서버는 간단히 말하면 사용자의 요청에 따라 응답을 해준다.

웹 애플리케이션 서버는 웹 서버와 같은 역할을 한다고 볼 수 있는데, 필요에 따라 요청에 맞는 서블릿을 호출하여 데이터를 처리한 다음 응답을 할 수 있다. 다시 생각해보면 웹 애플리케이션 서버는 위에서 말했던 서블릿 컨테이너이다.

Reference

Spring MVC의 서블릿

스프링 MVC 구성된 프로젝트를 빌드하면 war파일이 나온다. 이 war파일을 톰캣에 올려 웹 애플리케이션 서버를 구성했다. 서블릿 컨테이너인 톰캣에 스프링 MVC로 구현한 서블릿을 넣어 사용자의 요청을 처리한다.

스프링 MVC는 DispatcherServlet 가 있는데, 이를 통해 사용자의 요청을 받아들인다.

이후 HandlerMapping 을 거쳐 요청에 따라 컨트롤러에 매핑하여 요청을 처리한 다음 응답한다.

필요에 따라 Interceptor 를 거치고 exception을 처리한다.

Reference

Spring Boot의 서블릿

스프링 부트는 스프링 MVC 처럼 서블릿을 내장된 서블릿 컨테이너에 등록한다.

Reference

from http://spearkkk.dev/22 by ccl(A) rewrite - 2021-12-30 16:01:35