▶ 서블릿
자바에서 웹 어플리케이션 개발을 위해 만들어진 표준.
▶ 서블릿 요청 처리과정
매핑 url에 맞는 요청 발생 -> 서블릿 컨테이너에서 매핑 서블릿의 인스턴스 검색
있다면 : 해당 서블릿의 콜백 메서드 호출
없다면 : 해당 서블릿의 인스턴스 생성 -> 서블릿의 콜백 메소드 호출
▶ 서블릿 등록 및 매핑
서블릿을 등록하는 과정에 설정된 모든 정보는 서블릿의 콜백 메소드내에서 ServletConfig 객체를 통해 접근이 가능하다.
1. web.xml에 직접 등록 및 매핑
2. @WebServlet을 사용한 자동 등록과 매
▶서블릿의 callback메서드 종류
- lifeCycle 관련 메소드 : 생명주기 내에서 단 한번 호출되는 메서드(init, destroy)
- request 처리 관련 메소드 : 요청 발생시마다 각 쓰레드 내에서 반복 호출되는 메소드(service, do계열 메소드)
· 각 콜백 메소드의 호출 순서
객체 생성 직후 init호출 → request 발생시 service 호출 → service 메서드 내에서 현재 리퀘스트의 http method 구분 후 해당 do00메서드 호출 → 객체 소멸 직전 destroy 호출
∞ 객체는 언제 소멸되나??
▶ 서블릿 스펙이 있는데 왜 jsp를 써야하나? 서블릿 단점
1. 스크립트 방식에 비해 구현 후 반드시 컴파일을 해야한다.
2. 등록과 매핑과정을 거쳐야 한다.
3. 서블릿 리로딩 기능이 없는 WAS의 경우에 등록 후 웹 리퀘스트를 받기 위해서는 컨테이너를 재시작 해야한다.
-> 소스 고칠때마다 재컴파일 해줘야한다.
4. 어플리케이션 구현 소스 내에 UI구성 스크립트 소스가 들어가 웹 디자이너와 웹개발자 사이에 협업이 어렵다.
▶ 컴파일이란?
인간의 언어로 되어있는 소스를 이진수(바이너리)로 바꾸는 것
▶ 클래스패스란?
클래스를 찾을 때 시작점이 되는 위치
▶ xml과 json을 사용하는 이유?
xml은 언어를 타지 않아서 c로 만들어도 설정파일은 xml로 할 수 있다.
요청하는쪽(자바스크립트)과 받는쪽(자바)의 객체 표현 방식이 다름
-> 영어 역할을 하는게 xml, json.
xml보다 json이 더 가벼워서 더 많이 사용한다.
▶ ip와 port
ip는 물리적 주소체계이고 port는 논리적 주소체계이다.
ip 주소를 통해 서버를 찾고 port번호로 서버 안의 특정 서비스를 찾는다.
(우리가 했던 거에는 2가지 서비스-톰캣 80, 데이터베이스 1521)
▶ 톰캣
was, 서블릿 컨테이너, jsp 컨테이너, 미들티어
▶ 서블릿 컨테이너의 역할?
서블릿의 라이프사이클을 관리한다.
▶서버의 역할? 서버가 왜 필요한가
1. 클라이언트의 요청을 대기
2. 미들티어의 역할
서버는 요청이 들어오는지 계속 리스닝하고 있어야 한다. 80포트 24시간 감시하고 있어야됨. 요청이 들어오면 톰캣 서버가 잡아서 포트번호를 감지한다.(미들티어)
▶ 서버의 종류
1. W.S - 정적인 요청을 처리하기 위한 서버
2. W.A.S - 동적인 요청 처리
- 정적 요청 : 요청한 파일이 서버에 미리 있음. (IMG, MP3, video,..)
- 동적 요청 : 오늘 날짜, 오늘 멜론 차트, 이번달 베스트셀러..와 같이 동적으로 변하는 요청
☞ 요청을 처리할 수 있는 방식을 미리 놓는 방식 / 미리 놓을 수 없는 방식
▶ 자바의 장점
- 이식성. os를 안타고 jvm만 있으면 어떤 os에서든 실행가능
- 개발시 필요한 자료(api)들을 찾기가 쉽다.(map 안만들어도 쓸 수 있었음)
▶ W.A.S 역할
1. 웹 어플리케이션을 운영한다.(미들티어)
▶ Web Container
웹 어플리케이션을 관리하고 실행할 수 있는 컨테이너
servlet Container : 서블릿의 라이프사이클을 관리하는 경우
JSP Container : JSP의 라이프사이클을 관리하는 경우
Web Container - 두 컨테이너를 통칭.
종류 - Tomcat, Jeus, WebLogic 등
▶ MIME(Multipurpose Internet Mail Extensions)
HTTP 등의 프로토콜에서 응답 데이터의 타입을 설명하기 위한 것.
▶ HTTP Request Message 구조
- Request Line : method, url, protocol version
- Request Header : 메타데이터. 요청을 구분하기 위한 클라이언트의 부가정보
- Request Body(Message Body) : 내용. POST 방식인 경우만 형성됨.
▶ 인코딩
서버로 전달되는 파라미터들은 URLEncoding 방식으로 인코딩되어 전달된다.
-> 서버에서 파라미터를 확보하기 전 디코딩 방식을 결정해줘야 함
- POST : Message body를 통한 파라미터 전달
-> request.setCharacter Encoding - GET : Request-line의 Request-URL을 통한 파라미터 전달
-> 서버의 설정을 통한 디코딩 방식 설정. 톰캣(server.xml)
URIEncoding="encodingName"
useBodyEncodingForURI="true"
