03.18 학습! 백엔드 servlet! 🟥🟧🟨🟩🟦🟪🟫⬜⬛🫢🔔😎😊🤔😭⭐
servlet 🟥
웹 프로그램 🟧
비지니스 로직 (backend) + 사용자 인터페이스 (frontend)
live server -> 정적리소스 (HTML, CSS, JS)
만약 로그인을 한다면 -> 각각의 사용자에 맞춘 동적 요청 처리!
Web Application Server (WAS) (톰캣)
Business Logic(Java) -> Persistence Logic(DAO)(DB 전문가, JDBC) -> Persentation Logic (생성)
⭐ 이제 우리가 공부해야 할 것은? -> WAS, Servlet ⭐
WAS, Container, Context
물리적인 서버는 network에서 접근하기 위해서 ip 주소를 갖음 - HTTP 기반 통신
물리적인 서버에는 WAS가 설치되어 HTTP 기반의 웹 서비스 처리
WAS에 접속하기 위해서는 port 번호가 필요 일반적으로 80, 개발용으로 8080
WAS는 웹 애플리케이션이 필요한 실행환경 리소스를 담고 있어서 container라고 불림
http://192.168.0.1:8080 - ⭐container root⭐ (WAS)
WAS는 동시에 여러 가지 웹 애플리케이션이 동작 가능
각 애플리케이션의 실행 환경과 실행 정보 제공하는 것은 Context
http://192.168.0.1:8080/contextA - ⭐context root⭐ (Application)
Servlet 🟨
WAS에서 실행되는 Java Web Component - was를 servlet container라고도 한다!
장점
java의 OOP 기반으로 작성: 유지보수성 및 재활용성 우수하며 플랫폼 독립적
높은 성능과 확장성: 하나의 서블릿 객체만 생성하며 멀티스레딩을 지원하여 요청의 동시 처리가 가능
확장성: 필터를 통한 공통 모듈의 전/후 처리, 리스너를 이용한 이벤트 기반 처리 가능 및 스프링 등 다양한 프레임워크와 통합 용이
단점
business logic과 presentation login이 섞여서 나타남
-> Servlet + JSP의 Model 2 방식으로 처리
throw는 was가 호출했기 때문에 예외를 받음
URL Mapping
url-mapping 작성 방법
URL 경로 지정 : / 로 시작해서 경로 지정
확장자 매칭 : *.확장자 형태로 지정
상대경로 VS 절대 경로
절대 경로
/ 로 시작하지만
container root VS context root
주요 API🟩
extends jakarta.servlet.http.HttpServlet
Life Cycle 관리 🟦
개발자는 Servlet을 만들지만 객체를 만들거나 호출하지 않음 - Container가 life cycle에 따라 관리
init(ServletConfig config) get? doGet(), post? doPost()
destroy() : 어떤 요청이라도 처리하고 있으면 destroy는 동작하지 않음
HttpServletRequest
사용자의 Request를 분석 거의다 get 해야함 (분석이니깐!)
Request parameter
HttpServletResponse
HTTP 응답을 추상화한 인터페이스 (SET)
Http Status
2XX 3XX 4XX 5XX 왜 생겼는지 외우기! ⭐
Content_Type과 Character Encoding
Servlet 특징🟪
Servlet은 Multi Thread에 의해 공유됨
Servlet은 공유 자원으로 Thread Safe 하지 않음
Servlet이 상태 정보를 가지면 데이터 문제가 발생할 수 있음
synchronized를 통해 동기화 시키면 성능 저하!
결론적으로 Servlet에는⭐ 멤버 변수를 통해 상태를 관리하지 않는다! ⭐
😎멤버변수는 thread safe하지 않다!
Servlet에서 할일도 jdbc랑 똑같다!
🤔일이 너무 반복되는데?
Front Controller Pattern 🟫
기존 서블릿 작성 방식의 문제점
사용자의 요청과 이를 처리하는 Servlet이 1:1로 매칭됨
개별 서블릿에서 로깅, 예외 처리는 물론 인증, 비지니스 로직을 함께 처리
애플리케이션이 복잡해지면 개발생산성, 유지보수성에 문제 발생
Front Controller
전면에서 모든 요청을 받아들이는 Servlet
😊장점
단일 진입점, 공통 처리, 유연한 확장성, 코드 간결성
🤔다 main한테 요청 보내는데 어떻게 구분?
-
url에 특정 작업을 의미하는 파라미터 추가
main?action=gugudan -
와일드 카드를 이용한 URL 매핑
/main/
/board/
*.do
/
강사님 수업 ⬜ 😎🤔😊
FrontEnd - HTML, CSS, JS 와 웹 서버의 소통
request와 response로 소통함
이걸 한 쌍으로 표현하면 -> 동기
동기 : 한 쌍으로 묶여서 request를 보내면 response가 올때까지 대기
비동기 : 한 쌍으로 안묶임! 자유로움
Service
Container : Catalina (자동차)
Engine (Jasper) : HTML을 떨어트리기 목적
핸드폰도 container -> 자기 상태에 대해 자기 스스로 알아낼 수 있음
게임하다가 전화 받을 수 있음
구현이 다 되어있다!
Sevlet -> 오각형 콧구멍 두개 왜 두개일까?
request, response
Container -> Life cycle 이 있는 객체
웹에서는 생성자 프로그래밍을 하지 않는다!
jsp가 servlet으로 파싱됨
servlet이 3개월 만에 망함 ㅋㅋ 이유가 뭘까 html 3만줄 자바 200줄 이라서
멤버변수 쓰지마라 thread 땜시!
신지가 들어간 그룹 Coyote (훔쳐감) 동적을 정적으로 가져옴
FRONTEND에 DOM 모델이 있었음
INIT과 DESTROY는 한번만 불림
Service 14개가 있는데 통과하면 공인 WAS
pooling(DataSource) rock 건 Que
DB 담당 DAO 생성! -> JDBC를 이용 -> POOLING -> DB 도착
서블릿은 JAVA 위주
VIEW(JSP) DAO MODEL로 작업하고 JSP로 뿌려줌
면접거리 SI (SK,LG,KT) 😎
Servlet
Servlet의 친척 ServletConfig, 사촌 ServletContext
Servlet은 구현이 너무 빡셈;; 그래서 만들어 놓은 것이 GenericServlet(기운건 추상 클래스) (init하고 destroy 구현 안함)
GenericServlet을 상속받은 HTTPServlet 만들긴 했는데 좀 허접함 doGet하고 doPost만 돌려놓고 끝
HTTPServlet을 또 상속받음 KangsubServlet으로 상속 받기 doGet doPost 오버라이드 doGet(0,0){여기를 구현}
init()
service()
destroy()
어려운 점 Servlet하고 사귀기 위해서는
계층을 다 외워야 함 (가족 정보 다 알아야 함)
별명도 다 외워야 함 (한개 이상의 별명) (별명도 다 알아야 함) (alias 로 경로를 파악 /hello 라고 하면 아 이건 survlet 이구낭)
모든 요청을 한곳으로 받게 한다 Controller의 역할! 모든 요청을 다 파악 가능하다! but 너무 무거워지긴 함
DAO를 조합하면 Service DAO는 테이블당 1개 DTO는 테이블당 3개
Controll아 뭐 해줘 뭐 해줘
?action=해줘
🤔 웹서버의 특징이 뭔가?
stateless 기억을 못한다 붙는 사람이 많음
방대한 메모리 사용량
db는 statefull 붙는 사람이 적음 (권한 있는 사람)
붙기도 어렵고 떨어지기도 어려움
로그인 했음 근데 화면 하나 옮겼는데 로그인 또 하래;;
🤔그럼 개빡침 어떻게 할까?
웹에서 상태를 유지하기 위한 방법 session
HashMap으로 되어있음
HashMap의 아이디를 여러분의 컴퓨터에 쿠키로 줌
쿠키를 갖고 서버로 가면 쿠기번호로 세션을 사용 가능하다!
세션은 브라우저 당 하나
🤔get VS post
get 방식은 더러움 (기본) (pk 설정 한글로 하면 목졸림)
post 방식은 form 위주 (submit?)
🤔싱글톤 왜 만듬?
같은 요청 만개가 들어오면 instance 하나만 만들자!
🤔포드가 뭐고 왜 있음?
세션이 너무 무거워서
숙제
오늘의 알고리즘 숙제
백준 뱀, 통나무
시뮬레이션 연습
