초보의 Servlet 개발 Request, Response

그동안 Request, Response 쌩까고 만들어 왔지만 쪼꼼 짚고 넘어가는게 어떨까 싶다.

Request, Response 살짝 맛보는 김에 Scope도 맛이나 한번 보자.

 

1. Web Application Scope

 

Scope는 아래 4개의 영역으로 이루어 지는데  큰 영역의 순서대로(Application > Session > Request > Page) 하나씩 살펴보자.

 

- Application

개발하는 Application 전체에 영향을 미치는 영역이다. 마치 게임 설정과 같은 영역인데 겜을 할 때 해상도, 품질 등을 설정을 하지 않는가? 이렇게 게임 전체에 영향을 미치는 영역을 Application으로 생각하면 되는데 Application에 직접적 영향을 미치기 때문에 신중하게 접근되어야 하고 Application 영역은 서버를 끄지 않는 한 계속 영향을 미치게 된다.

 

- Session

게임 설정을 끝내고 로그인 및 캐릭터 선택을 하고 게임을 플레이하게 되는데 Session은 로그인을 하고 플레이를 하는 동안 유지되는 캐릭터라 생각하면 되겠다. 로그아웃을 하지 않는 한 유지되는 영역으로 만약 우리가 게임 계정이 2개라고 생각해보자 첫 번째 계정으로는 딜러 캐릭터를 두 번째 계정으로는 서포트 계열을 육성한다고 생각하면 딜러 키우다 로그아웃하고 서포트 들어오면 딜러 정보는 없어지지 않는가? 서포트 키운다고 딜러가 함께 성장하는 것은 아니지 않은가? 그렇다 로그아웃을 하기 전까지만 유지가 되는 거다.

 

- Request

그럼 Request는 게임에 대입해보면 스킬에 해당한다 할 수 있는데 스킬을 사용하면 스킬 효과와 함께 적에게 -10의 데이지를 입혔습니다 하고 끝나지 않는가? 쿨타임이 생기기도 하고 아니더라도 효과와 적에게 입히는 대미지라는 응답을 주게 되는데 이렇게 스킬 사용이라는 행위가 끝나면 없어지는 단발성 영역이다.

 

- Page

그럼 환경설정, 로그인 및 캐릭터 설정, 스킬 사용이 위 내용에 해당하면 Page는 아이템 강화에 해당한다. 이게 무슨 말이냐면 아이템 강화를 하려면 해당 아이템과 강화 옵션 1, 강화 옵션 2..(강화석, 게임머니 등등) 뭐 쨌든 이런 식으로 강화창에 올려놓고 아이템을 강화하게 되는데 이때 아이템과 옵션들은 서로를 공유하고 그에 맞는 결과를 도출한 후 종료(성공이든 실패든)하게 된다. 그 강화라는 영역 안에서만 서로를 공유하고 결과를 위해 벗어나면 없어지는 그런 영역인 것이다.

 

게임에 빗대어 설명을 해보았는데 사실 개념적인 측면에서 설명하기 위해 저렇게 적어놨을 뿐 실제는 다르지 않겠나?

그래서 영역별로 하나씩 개발에서 어떤 작용을 하는지 간략하게 봐보자.

 

2. Application

 

이전 글에서 web.xml에 <servlet> 태그와 <servlet-mapping> 태그를 이용해 '어이 거기 서버야 /servletSample.do 들어오면 OlDevSampleServlet.java한테 넘겨줘'라고 설정한 게 Application 영역을 설정한 거라 생각하면 되시겠다. 위에서 Application은 신중하고 조심해야 한다며? 영향을 미친다며? 어디서 미치는데? Servlet 설정이.. 영향을 미치고 있는 건데... Servlet 기껏 만들고 Application에 안 알려주면 URL에 대한 요청을 받고 응답을 줄 수 있겠는가? listener, filter 같은걸 꼭 만들어 넣어야 영향을 미치는 게 아니라 비록 하나만 만든 Servlet 조차도 영향을 미치고 있는 것이다. java 파일을 수정하면 재배포를 해야 하는데 이는 Application이 변경된 정보를 모르기 때문에 재배포를 하는 것이고 이 말은 딸랑 하나 만든 OlDevSampleServlet이 어떤 영역에서 관리 되어지는지 알 수 있는것이 아닌가? 그럼 앞으로 만들어낼 java들은 Application영역이구나 생각하면 되고 예시를 좀 더 얘기하자면 공통 코드나 메시지를 Application 영역에 올려서 사용한다고 생각해보자 이런 작업을 하는 의미가 보통은 개발 중 어디서나 똑같이 갖다 쓰고 트래픽을 줄이자는 생각일 텐데 이런 기능을 접근할 때 실수로 내용을 없애거나 엉뚱한 내용을 변경시켜 버리면 어떻겠는가? 그래서 조심하자는 거다.

 

3. Session

 

Session은 로그인을 예를 들었으나 로그인해야만 Session 생성되는 것이 아니라 이미 생성된 Session 가져다 쓴다가 더 맞는 표현 같은데 이는 browser에서 localhost:8080을 입력하고 접속하게 되면 이 접속 요청을 보낼 때 특별한 값을 하나 생성하고 browser는 생성된 값을 변수에 담아서 요청 시 함께 넘겨주며 서버는 borwser가 보낸 특별한 값을 저장하고 있다가 이후 요청이 들어오면 이 값이 일치하는지를 확인하고 Session에 접근할 때 동일한 정보를 찾을 수 있도록 도와주게 된다. 이렇게 모른척하지 않고 알려주려면 Server는 이것들을 관리해야 하기 때문에 Session에 대한 자원을 할당하고 관리하므로 중복 로그인 방지 같은 기능도 수행할 수 있다. 

 

Session은 아직 써보지 않았으니 대충 넘어가자...;;; 왜냐하면 내용도 너무 방대하고 Session에 사용자 정보나 넣지 다른 짓을 할 것은 아니기 때문에 Server에서 관리하고 있고 저런 기능을 만들 수도 있겠구나 정도만 알자.

 

4. Request

 

Request는 깊이 있게 알려고하면 http부터 살펴보아야는데 http부터 뜯고 시작하면... 현재 수명으론 좀 모자를것 같으니깐 http에 깊이있게 알고 싶다면 링크를 참조하자..;;

 

http 참고 링크 : https://developer.mozilla.org/ko/docs/Web/HTTP/Messages 

HTTP 메시지

 

링크를 따라가 보면 인증, 캐싱, 보안 등등해서 많은 내용이 있지만 우리에겐 중요한 것은 Request, Response이니 중간 이미지에 있는 Request가 이렇게 생겼구나 Response가 이렇게 생겼구나 정도와 header와 body만 봐두면 좋을 것 같고 위 글에 Application이니 Session이니 주저리주저리 써놨지만 Web 개발하면서 http 프로토콜을 사용한다는 것은 Request 보내고 Response 받는것 외에는 없다고 봐도 무방하다 할 수 있다. Session도 이야기했지만 browser가 특정값을 만들어 요청에 담아서 보내주게 되고 그 값을 서버가 관리하는 개념이라 이 요청에 담아서 보내준다는 행위가 Request인 것이다.

 

그리고 html과의 관계도 잠깐 살펴봐야는데 hyper text transfer protocol과 hyper text markup language라는 이름에서 알 수 있듯이 http와 html은 밀접한 관계를 가지고 있는 것 같지 않은가? 여기서 protocol이라는 단어가 IT 용어로 통신 규약을 뜻하므로 http는 html을 전송하기 위한 규약이라 할 수 있는데 이 규약대로 처음부터 개발하라면 죽어나지 않을까? 분명히 죽진 않아도 그에 준하는 고통을 느끼지 싶다. 그래서 그 밑바닥에서부터 개발할 수는 없으니 Tomcat을 설정한 것이고 Tomcat에서 이 통신규약에 맞는 라이브러리를 제공하므로 이를 이용해 개발을 하게 되는 것이다. 그래서 우린 Tomcat이든 weblogic이든 감사히 사용하자.

 

http는 그렇다 치고 이제 Request를 이야기해보면 Request는 Response와 세트로 되어있다고 했었는데 이는 요청한 대상에 반드시 응답을 주어야 한다. 다시 이야기하자면 A browser에서 요청이 왔다면 서버는 A borwser로 응답을 반드시 주어야 한다. 이때 A browser에서 B browser로 응답은 줄 수 없다. 즉 Chrome에서 요청하고 Internet Explorer에 응답을 보낼 수는 없다는 이야기이고 동일한 internet browser라도 다른 페이지에 전달해줄순 없다. browser tab을 여러개 열어둔다고 내가 요청한 화면으로 돌아오지 2번 탭으로 가지는 것은 아닌것 처럼. 뭐 그런 게 가능한 설루션이 있는지는 모르겠다만 요청한 클라이언트에 반드시 응답을 주어야 한다는 건 잊지 말자. 그리고 홍길동.com, 김길동.com으로 동시에 두 개의 domain에 접근하는 것은 지양하도록 하자. 이는 cross domain이라 하는데 불가피하게 사용해야 한다면 필요할 때 찾아보자.

 

말한 대로 요청받으면 응답 줄 테니깐 Request를 어떻게 쓰는지나 보자. 이전에 개발해본 JSP는 코딩 시 Request 객체를 내장 객체로 특별한 작업 없이 접근이 가능했는데 이를 java에서 한다고 생각해보면 HttpServlet을 상속하여 사용해야 하고 이는 부모의 doGet method를 overring 하면서 HttpServletRequest와 HttpServletResponse를 aguments로 넘겨 받아 Request를 사용하겠다는 의미가 되는데 이렇게 Reqeust, Response를 받게 되면 JSP 내장 객체를 사용하는거랑 뭐가 다른가? 즉 이제 저 받아낸 Request, Response를 입맛에 맞게끔 사용만 하면 된다. 

 

HttpServlet에서 사용하는 Request 객체와 Response 객체는 수많은 method들을 지원하는데 이 method를 나열해봐야 API 한번 보는만 못하니 forward, redirect, dispatcher (이걸 설명하는게 맞을것 같지만 기분탓이려니...)등등 개념들과 같이 만들어보면서 이해해보자.

 

5. Page (JSP)

 

게임을 빗대어 강화와 비슷하다고 풀어 설명했는데 내용을 다시 풀어보면 아이템 강화를 한다면 대상 아이템과 강화 관련 내용을 알아야 강화를 시킬 수 있을 것이다. 이 말은 그 행위를 하는 정보들이 어떤 것이 있고 어떻게 작용하는 것인가를 알고 있다는 것이고 이렇게 이미 알고 있는 영역의 정보를 손쉽게 접근할 수 있도록 처리를 해두면 어떻겠는가? 즉 아이템 정보 주어봐 할 땐 item.getItemInfo 쯤? 옵션은 item.getItemOption 쯤? 만들어 둘 수도 있지 않겠는가? 이렇게 사용되어야 할 객체를 미리 만들어두고 제공하는것을 내장 객체라 하는데 JSP에서 사용되는 내장 객체들을 관리하고 화면에서 사용할 수 있도록 도와주는 영역이 Scope의 page 영역인 것이다.

 

JSP 내장 객체들 역시 여러 가지가 있지만 JSP 만들면서 사용하게 되는 객체들은 아 내장 객체가 관리해주는 애들이구나 정도로 넘어가면 되겠다.

 

참고로 JSP 개발 할때나 Page 영역이 있는것이지 UI 솔루션이 도입되면 그 솔루션이 제공하는 내장 객체를 사용해야한다.

 

Web Application Scope의 각 영역을 한번 알아보았는데 이런 개념적인건 아 이렇게 영역이 분리되어 관리가 되는구나 정도만 이해하자. 이론이 바탕이 되어야 실무에서 더 잘하는게 아니겠냐만은 내용이 너무 많다... 진짜 많다... 그래서 깊이있게 다루어야 할 때 찾아 볼 수 있도록 이런 영역이 존재하는구나 정도만 이해하고 개발하다보면 소스 레벨에서 이해가 되어지는 부분도 있기 때문에 넘어가자....