-
Notifications
You must be signed in to change notification settings - Fork 0
/
servlet.txt
109 lines (66 loc) · 6.47 KB
/
servlet.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
Jakarta servlet
servlet은 서버의 가용성을 확장해주는 자바 소프트웨어 컴포넌트이다.
서블릿이 다양한 유형의 리퀘스트에 리스폰드 할 수 있음에도, 그것들은 웹 컨테이너가 웹서버에서
웹 어플리케이션을 호스팅할 수 있게 하는데 주로 사용된다.
서블릿은 자바 EE의 자바 클래스를 처리하고 저장한다. 이 때 jakarta EE는 자카르타 서블릿 API를 따르는데,
이것은 레퀘스트에 리스폰드하는 자바 클래스를 수행하는 기준이다. 서블릿은 원칙적으로 모든
클라이언트-서버 프로토콜을 통해 소통할 수 있다. 그러나 가장 빈번히 함께 쓰이는 것은 HTTP이다.
그러므로 서블릿은 이따금씩 HTTP servlet의 줄임말로 사용되기도 한다.
따라서 개발자는 자바 플랫폼을 사용하는 서버에 역동적인 content를 추가하기 위해 사용한다.
이러한 방식으로 생성되는 컨텐츠는 주로 HTML이나, xml, jason 등의 다른 데이터들일 수도 있다.
서블릿은 세션 변수 속에서 state를 유지할 수 있다.
-
서블릿을 deploy하고 run하기 위해서는 반드시 웹컨테이너가 사용되어야 한다. 서블릿 컨테이너라고도 불리는
웹컨테이너는 서블릿과 상호작용하는 웹서버의 필수적인 구성품이다.
웹컨테이너는 서블릿의 생명주기를 관장하고, 특정 서블릿에 URL을 매핑하여 URL request가 올바른 접근 권한을
가지도록 만든다.
java package의 javax.servlet에 포함된 servlet API는 웹컨테이너와 서블릿의 예상되는 상호작용을
정의해 놓았다.
서블릿은 리퀘스트를 수신하고 그 요청을 기반으로 리스폰스를 만들어내는 오브젝트이다. 기본 서블릿 패키지는
서블릿 리퀘스트와 리스폰스를 표현하는 자바 오브젝트를 정의한다. 마찬가지로 그것은 서블릿의
configuration parameter와 실행 환경을 반영한다. java.servlet.https는 일반적인 서블릿 elements의
http-specific 서브 클래스를 정의한다. 이 클래스는 클라이언트와 서버 사이의 다중 request/response를
관장하는 session management object를 포함한다. 서블릿은 웹 어플리케이션으로서 WAR file로 압축될 수도 있다.
서블릿은 JSP compiler에 의해 JSP로부터 자동으로 생성된다. 서블릿과 JSP 사이의 차이점은 아래와 같다.
서블릿은 HTML을 자바 코드 속에 집어 넣는다. 반면 JSP는 자바 코드를 HTML 속으로 집어 넣는다.
HTML을 생성하기 위한 직접적인 서블릿의 사용이 드물어졌기는 하지만, JAVA EE에서 높은 레벨의 MVC 웹 프레임워크에서는
여전히 FacesServlet을 경유하여 로우 레벨에서의 request/response를 처리하기 위해 서블릿 기술을 사용한다.
서블릿과 JSP를 교차하여 사용하는 다소 오래된 방식도 있는데, MVC 관점에서 보자면 이를 Model 2 패턴이라고 한다.
---
서블릿의 생명주기
서블릿의 생명주기에 대해서는 세 가지 메소드가 중요하다.
"init()" , "service()" , "destroy()"
이 메소드들은 모든 서블릿에 대해 적용되며, 서버에 의해 특정 시간에 호출된다.
* 서블릿의 생명주기를 초기화하는 첫 단계에서, 웹 컨테이너는 "init()" 메소드를 호출하여 서블릿 인스턴스를 초기화한다.
그리고는 javax.servlet.ServletConfig 인터페이스를 구현한다. 이러한 configureation object는 서블렛으로 하여금
웹 어플리케이션의 name-value initialization parameter에 접근하도록 한다.
* 초기화 이후에는 서블릿 인스턴스는 클라이언트의 리퀘스트에 대응할 수 있다. 각각의 리퀘스트는 그것만의 분리된 스레드에서
서비스 된다. 웹컨테이너는 서블릿의 "service()" 메소드를 호출하여 모든 리퀘스트에 대응한다. 이 서비스 메소드는
리퀘스트의 종류를 결정하고 그것을 처리하기에 적합한 메소드에게 분배한다. 따라서 서블릿을 만드는 개발자는 이러한 메소드들을
반드시 구현해야 한다. 만약 리퀘스트가 서블릿에 구현되지 않은 메소드를 목적으로 만들어졌다면, 그 메소드의 부모 클래스가 호출되게 되고
이것은 요청자에게 에러로서 반환된다.
* 마지막으로 웹 컨테이너는 "destroy()" 메소드를 호출하여 서블릿을 서비스에서 빼낸다. "init()"메소드처럼,
"destory()"메소드도 서블릿의 생명주기 중 단 한 번만 호출된다.
---
유저 시나리오
1. 유저가 특정 URL에 방문하기 위해 요청한다.
- 유저의 브라우져가 URL에 대한 HTTP request를 생성한다.
- 이 리퀘스트는 적합한 서버로 보내진다.
2. (웹)서버가 HTTP리퀘스트를 받아서 그것을 웹 컨테이너(was)로 보낸다.
- 웹 컨테이거나 이 리퀘스트를 특정 서블릿에 매핑한다.
- 서블릿은 역동적으로 조회되며, 컨테이너의 address space에 올려진다(load).
3. 웹 컨테이너가 서블릿의 init() 메소드를 호출한다.
- 이 메소드는 서블릿이 메모리에 처음 올라갔을 때만 호출된다.
- 초기화 파라미터를 서블릿으로 보내서 서블릿이 스스로 configure하도록 만드는 것이 가능해진다.
4. 웹 컨테이너가 service() 메소드를 호출한다.
- 이 메소드는 HTTP 리퀘스트를 처리하기 위해 호출된다.
- 서블릿은 HTTP 리퀘스트 내에서 제공된 데이터를 읽어낸다.
- 서블릿이 클라이언트를 위한 HTTP response를 만들어낸다.
5. 서블릿이 컨테이너의 address space에 남아서 다른 HTTP request를 처리한다.
- 각각의 HTTP request에 대해서 각각의 service() 메소드가 호출된다.
6. 컨테이너가 특정 시점에, 메모리에서 서블릿을 내리기로 결정한다.
- The algorithms by which this decision is made are specific to each container.
(알고리즘에 의해 내려진 결정을 각 컨테이너마다 구체적이다)
7. 컨테이너가 destroy() 메소드를 호출하여 서블릿을 위해 배정돼 있던 모든 resource를 없앤다(포기한다. 중요 데이터는
저장될 수 있다.).
8. 서블릿에 배정돼 있던 메모리와 오브젝트가 가비지 콜렉터에 의해 처리된다.