[Section3] [Spring MVC] API 계층 - Spring MVC 아키텍처

스프링 프레임워크란?

스프링에서 지원하는 모든 기능을 통틀어서 스프링 프레임워크라고 한다

 

스프링 웹 MVC란?

스프링에서 웹계층을 담당하는 몇가지의 모듈 중 특히 서블릿(Servlet) API를 기반으로 클라이언트의 요청을 처리하는 모듈을 지칭하는 용어이다.

 

스프링 웹 MVC = 스프링 MVC = Spring MVC 프레임워크 (웹 프레임워크 중 하나이기에)

 

서블릿이란?

만약 클라이언트와 서버가 단 한번의 HTTP 통신을 하려고만 해도 아래와 같은 통신 과정이 필요하다.그런데, 이 과정 중 반복되는 것들이 있다.초록색칸의 비즈니스 로직을 제외하고는 어떤 웹 애플리케이션이든 모두 똑같이 반복되는 내용이다.단지 비즈니스 로직만이 웹앱마다 그리고 각 요청마다 다를것이다.

그리하여 이런 반복되고, 그리고 통신부분에서 내부적인 내용들은 알아서 처리 해주는것이

바로 서블릿 기술이다. 그리고 이 서블릿은 자바의 기술이다. 그러므로 여러 클래스, 인터페이스로 이루어진 기술이다.

 

뭔가 개념이 모호할 수 있지만,쉽게 생각하면 된다.자바는 프로그래밍 언어인데, 그 자바의 기술을 표현하는데 여러 자바 객체가 있듯이서블릿도 자바의 기술 중 하나인데, 그 서블릿 기술을 표현하는데 여러 객체들이 있는것이다.

 

 

HttpServletRequest : 서블릿이 클라이언트 요청에 대한 내용을 알아서 파싱(데이터를 구분하여) 하여 담아준 클래스

HttpServletResponse : 서블릿이 클라이언트에게 전달하는 답변에 대한 내용을 편리하게 제공할 수 있도록 도와주는 클래스 

서블릿 컨테이너의 역할 : 서블릿 객체를 생성, 호출, 관리 해줌.

 

아래는 간단한 HTTP 통신 과정이다.

클라이언트가 요청을 하면 Web Application Server에서 요청을 받고, 해당 요청을 서블릿 컨테이너에게 전달하여 요청에 맞는 서블릿을 생성시킴. 그리고 서블릿에서 처리된 내용을 response에 담아 WAS에 전달, WAS(Web Application Server)는 클라이언트에게 전달함.

 

+ 아파치 톰캣은 서블릿 컨테이너 중 하나이다.

 

 

Spring MVC에서 M이란?

우선 Model의 약자이다.

일상생활에서 사용되는 모델이란 말은 패션모델, 손모델 처럼 뭔가 보여지는 결과물을 얘기한다.

MVC 패턴과 스프링 MVC에서의 M의 의미도, 클라이언트에게 보여질, 전달될, 처리된 결과를 말한다.

MVC에서 V(View)는 보여지는것 전체를 얘기한다면, Model은 그 안에서 사용자 요청에 의해서 처리된 결과 데이터라고 스스로 이해하였다.

말하자면, 웹 페이지에서 버튼, 네비게이터 항목, 페이지 단락같은것은 특정한 의미없이 존재하는 것이라면,

사용자 정보, 사용자의 새로운 피드 와 같은것은 사용자가 요청하여 서버에서 전달해준 사용자 요청과 관련된 데이터들일 것이다.

그것이 M이라고 생각한다.

 

Spring MVC에서 V란?

우선 View의 약자이다.

View는 앞에서 설명한 Model 데이터를 이용해서 웹브라우저 같은 클라이언트 애플리케이션의 화면에 보여지는 리소스(Resource)를 제공하는 역할.

 

다양한 View 기술

• HTML 페이지의 출력
  - 클라이언트 애플리케이션에 보여지는 HTML 페이지를 직접 렌더링해서 클라이언트 측에 전송하는 방식입니다. 
  - 즉, 기본적인 HTML 태그로 구성된 페이지에 Model 데이터를 채워 넣은 후, 최종적인 HTML 페이지를 만들어서 클라이언트 측에 전송해줍니다.
  - Spring MVC에서 지원하는 HTML 페이지 출력 기술에는 Thymeleaf, FreeMarker, JSP + JSTL, Tiles 등이 있습니다.
  
  
• PDF, Excel 등의 문서 형태로 출력
  - Model 데이터를 가공해서 PDF 문서나 Excel 문서를 만들어서 클라이언트 측에 전송하는 방식입니다. 
  - 문서 내에서 데이터가 동적으로 변경되어야 하는 경우 사용할 수 있는 방식입니다.
  
  
• XML, JSON 등 특정 형식의 포맷으로의 변환
  - Model 데이터를 특정 프로토콜 형태로 변환해서 변환된 데이터를 클라이언트 측에 전송하는 방식입니다. 이 방식의 경우 특정 형식의 데이터만 전송하고, 프런트엔드 측에서 이 데이터를 기반으로 HTML 페이지를 만드는 방식입니다.
  - 쉽게말해, 처리된 결과만 전달해주는것인데 형식은 XML, JSON 과 같은 특정 형식으로 보내주는것을 말한다.
  - 서버는 데이터 전달만을 담당하고 클라이언트는 받은 데이터로 보여지는것만 담당하니, 백엔드와 프론트엔드의 역할 구분이 명확하다.

 

Spring MVC에서 C란?

우선 Controller의 약자이다.

Controller는 클라이언트 측의 요청을 직접적으로 전달 받는 엔드포인트(Endpoint)로써 Model과 View의 중간에서 상호 작용을 해주는 역할을 한다.

웹 개발자의 입장에서는 클라이언트의 요청을 최초로 받는 접점이며, 서버의 비즈니스 로직을 거친 뒤 클라이언트에게 전달전 마지막 접점이므로 엔드포인트라고 할 수 있겠다. (내부적으로는 서블릿이며 여러가지 접점이 있겠지만, 스프링 MVC에서 개발하는 웹 개발자 입장에서의 말이다)

 

 

웹서버 (Web Server)와 WAS (Web Application Server)

• 웹서버

웹서버란 두가지의 의미를 가질 수 있다.

1. 웹 서버 (소프트웨어): 웹 브라우저와 같은 클라이언트로부터 HTTP 요청을 받아들이고, HTML 문서와 같은 웹 페이지를 (정적인 리소스) 반환하는 컴퓨터 프로그램 (소프트웨어) ,
   APACHE 등등..
   
2. 웹 서버 (하드웨어): 위에 언급한 기능을 제공하는 컴퓨터 프로그램을 실행하는 컴퓨터

하지만 보통 1번 웹서버의 의미로써 사용된다.

소프트웨어의 관점인 웹서버도 결국 물리적인 컴퓨터란 곳에서 돌아가야 하기 때문에 2번은 당연히 따라오는 개념이다.

(WAS의 기능 또한 일부분 가지고 있다.)

 

• WAS
  

웹 애플리케이션과 서버 환경을 만들어 동작시키는 기능을 제공하는 소프트웨어 프레임워크이다. 인터넷 상에서 HTTP를 통해 사용자 컴퓨터나 장치에 애플리케이션을 수행해 주는 미들웨어(소프트웨어 엔진)로 볼 수 있다. 웹 애플리케이션 서버는 동적 서버 콘텐츠를 수행하는 것으로 일반적인 웹 서버와 구별된다. (위키백과 내용)

 

WAS의 기능

• 프로그램 실행 환경과 데이터베이스 접속 기능을 제공한다.
• 여러 개의 트랜잭션을 관리한다.
• 업무를 처리하는 비즈니스 로직을 수행한다.

쉽게 말해, 웹서버 보다 조금 더 복잡한 내용의 내부 처리로 인해 동적 리소스를 제공하는 Web (Application) Server이다.

(그리고 웹서버의 기능 또한 거의 비슷하게 가지고 있다.)

 

 

 

• 웹서버와 WAS의 관계

최초에 인터넷은 단순히 클라이언트가 요청하는 HTML 파일이나 이미지 같은 것들의 정적인 파일만 넘겨주면 되었다.

그리고 그 역할을 웹서버가 담당하였다.

그러나, 인터넷이 보다 복잡해지고 다양한 기능을 제공하게 되면서, 프로그래밍이 된 동적인 내용의 전달이 필요하게 되고 WAS라는것이 생겨나게 되었다. 동적이라함은 로그인된 유저에게만 보여줘야할것이 있고, 비회원에게만 보여줘야할것이 있을것이다. 그리고 서버로 넘어온 요청 따라 다른 결과를 보여줘야 하는 경우도 있을것이다. 같은 요청이여도 서버로 넘어 온 데이터나 상황에따라 결과가 동적으로 바뀌는것을 말한다.

그러나 WAS에도 보통 자체적인 웹서버의 기능을 내장하고 있다. (어떻게 보면 당연하다, 그냥 서버에 위치한 HTML 파일을 전달하는것과 요청에따라 다른 데이터가 들어간 HTML을 제공하는것. 결국 HTML을 제공하는 기능은 같다)

그러므로, 작은 규모의 서비스에서는 그냥 WAS 만으로도 충분하지만 큰 규모에서는 웹서버와 WAS를 따로 두어서 처리한다. 

클라이언트 요청이 들어왔을때, 

만약 요청이 동적인 리소스라면 웹서버를 거쳐서 WAS까지 가고 WAS에서 처리를 하지만,

만약 요청이 단순히 정적리소스를 요청하는 경우 서버 아키텍처상에 앞단에 위치하는 웹서버에서 처리하고 그 결과를 보보내고 처리가 끝난다.

그러나 요즘은 웹서버도 WAS의 기능을 어느정도 가지고 있다.

 

 

 

• 결론

현재 시점에서는 WebServer와 WAS의 경계와 기준을 모호해졌다.

그냥 WebServer는 정적인 리소스 제공에 특화,

WAS는 동적인 리소스 제공에 특화 되어있고,

요즘은 그냥 WAS를 사용한다고 보면된다.

WAS에는 

톰캣(Tomcat) Jetty, Undertow 등이 이다.

 

 

 

 

참조 : https://0ver-grow.tistory.com/134

[웹기초 BE_Servlet] 4. 웹 서버의 기능, 종류,역할 / WAS란, 종류, 웹서버와의 차이점 / DBMS / 미들웨어

https://ko.wikipedia.org/wiki/%EC%9B%B9_%EC%95%A0%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98_%EC%84%9C%EB%B2%84

웹 애플리케이션 서버 - 위키백과, 우리 모두의 백과사전

 

https://ko.wikipedia.org/wiki/%EC%9B%B9_%EC%84%9C%EB%B2%84

 

 

 

Spring MVC의 동작 방식과 구성 요소

웹 요청 -> 웹 결과 반환 과정을 간단히 표현한 그림이다.

참고로, 갑자기 DispatcherServlet이라는 개념이 등장하는데, 아래에 설명이 있다.

(1) 먼저 클라이언트가 요청을 전송하면 DispatcherServlet이라는 클래스에 요청이 전달됩니다.

(2) DispatcherServlet은 클라이언트의 요청을 처리할 Controller에 대한 검색을 HandlerMapping 인터페이스에게 요청합니다.

(3) HandlerMapping은 클라이언트 요청과 매핑되는 핸들러 객체를 다시 DispatcherServlet에게 리턴해줍니다.

핸들러 객체는 해당 핸들러의 Handler 메서드 정보를 포함하고 있습니다. Handler 메서드는 Controller 클래스 안에 구현된 요청 처리 메서드를 의미합니다.

 

(4) 요청을 처리할 Controller 클래스를 찾았으니 이제는 실제로 클라이언트 요청을 처리할 Handler 메서드를 찾아서 호출해야 합니다. DispatcherServlet은 Handler 메서드를 직접 호출하지 않고, HandlerAdpater에게 Handler 메서드 호출을 위임합니다.

 

(5) HandlerAdapter는 DispatcherServlet으로부터 전달 받은 Controller 정보를 기반으로 해당 Controller의 Handler 메서드를 호출합니다.

 

이제 전체 처리 흐름의 반환점을 돌았습니다. 이제부터는 반대로 되돌아 갑니다.

 

(6) Controller의 Handler 메서드는 비즈니스 로직 처리 후 리턴 받은 Model 데이터를 HandlerAdapter에게 전달합니다.

(7) HandlerAdapter는 전달받은 Model 데이터와 View 정보를 다시 DispatcherServlet에게 전달합니다.

(8) DispatcherServlet은 전달 받은 View 정보를 다시 ViewResolver에게 전달해서 View 검색을 요청합니다.

(9) ViewResolver는 View 정보에 해당하는 View를 찾아서 View를 다시 리턴해줍니다.

(10) DispatcherServlet은 ViewResolver로부터 전달 받은 View 객체를 통해 Model 데이터를 넘겨주면서 클라이언트에게 전달할 응답 데이터 생성을 요청합니다.

 

(11) View는 응답 데이터를 생성해서 다시 DispatcherServlet에게 전달합니다.

(12) DispatcherServlet은 View로부터 전달 받은 응답 데이터를 최종적으로 클라이언트에게 전달합니다.

 

 

서블릿 컨테이너

서블릿 객체의 생성, 관리, 종료 를 담당하는 서블릿 저장소.

 

서블릿 컨테이너의 대한 설명

• 톰캣처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 함
• 서블릿 컨테이너는 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기 관리
• 서블릿 객체는 싱글톤으로 관리
  - 고객의 요청이 올 때 마다 계속 객체를 생성하는 것은 비효율 
  - 최초 로딩 시점에 서블릿 객체를 미리 만들어두고 재활용 
  - 모든 고객 요청은 동일한 서블릿 객체 인스턴스에 접근 
  - 공유 변수 사용 주의
  - 서블릿 컨테이너 종료시 함께 종료
• JSP도 서블릿으로 변환 되어서 사용
• 동시 요청을 위한 멀티 쓰레드 처리 지원
  
  
  

DispatcherServlet이란?

밑에 그림에서 보이는 Front Controller가 DispatcherServlet이다.

즉, 일반 웹 개발자들이 개발하는 범위에 있는 Controller와 웹 요청을 맵핑 시켜주는 역할의 Front Controller인 것이다.

나는 DispatcherServlet을 서블릿 컨테이너에서 관리되는 여러 서블릿 객체중에 하나이며,  클라이언트의 요청과 실제 Controller (개발자가 추가한 Controller) 를 매핑 시켜주는 서블릭 객체라고 정의하였다.

아래는 클라이언트 요청이 들어왔을때 DispatcherServlet의 역할을 간단히 설명한 그림이다.

• 위 그림 설명

클라이언트로부터 요청이 들어온다

그러면 우선 WAS가 받게 될것이다. 그리고 서블릿 컨테이너로 전달되는데,

서블릿 컨테이너는 DispatcherServlet에게 요청 정보를 전달한다.

그래고 이때, DispatcherServlet이 요청 정보를 확인하여 HandlerMapping에게 적절한 Controller 찾으라고 검색을 위임한다.

찾은 Controller에 대한 정보를 DispatcherServlet에게 다시 리턴하고,

DispatcherServlet은 해당 Controller객체의 정보를 HandlerAdapter에게 또 전달하고,

HandlerAdapter가 해당 Controller 내에서 요청의 내용과 매핑되는 메소드를 호출하고 해당 메소드에서 비즈니스 로직으로 요청의 대한 내용을 처리한다.

 

+ 위에 적은 "Spring MVC의 동작 방식과 구성 요소" 파트의 내용, 그림과 같이 보면 이해에 도움이 될것이다.

 

참조 : https://www.geeksforgeeks.org/what-is-dispatcher-servlet-in-spring/

참조 : https://velog.io/@seculoper235/2.-DispatcherServlet-%EC%9D%B4%EB%9E%80

2. DispatcherServlet 이란?

 

 

전체 참조 :

김영한님의 "스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술"

코드스테이츠 공부내용