Java: Servlet #1 개념
Servlet & JSP
Spring 및 Spring MVC Pattern을 공부하기에 앞서 Servlet을 선행하기로 함.
스터디 진행순서 설명
- 자바 언어에 Servlet API을 더해 ‘자바 웹 프로그램’을 개발
- Servlet만으로 웹문서(html)를 출력하는데 비효율적인 문제점을 파악하고 문서의 출력을 간편하게 해줄 수 있는 JSP 필요성 확인.
- JSP로 웹 문서 출력에 대한 편의는 확인했으나 스파게티코드 문제발생 확인
- 코드의 일정 규칙을 가지는 JSP MVC 진행
위와 같이 Servlet -> JSP -> MVC 순서로 진행하며 이후 Spring MVC 추가 진행
웹 서버 프로그램이란?
‘웹 서버 프로그램’이 뭔지 알고 만드는 겁니까?
과거 ‘프로그램’이란 이름으로 ‘프로그램’을 실행시켜 사용자의 로컬 컴퓨터로 입출력의 결과를 받았다. 그 프로그램을 껍데기에 따라 윈도우 프로그램, 콘솔 프로그램으로 나눠 불렀고, 사용자 컴퓨터 내에서 연산하고 DB를 콜해서 리스폰하는 방식이다.
*윈도우 프로그램은 옛날 아이콘 클릭해서 응용 프로그램 실행하는 방식, 콘솔 프로그램은 옛날 도스창(DOS, 지금의 윈도우 CMD)
시간이 지나 ‘프로그램’의 모습은 클라이언트(요청자) 프로그램과 서버(제공자)프로그램(DB구조)으로 나뉘어졌다. 이때 클라이언트와 서버간 문제가 있었는데 그것은 동기화였다. 서버프로그램에 변경이 생기면 클라이언트 프로그램도 변경돼야 하는데 당시에는 변경 될 때마다 클라이언트 쪽에 매번 재설치를 했어야 했다. 자동 업데이트 기능은 없었으며 이를 개선하고자 데이터를 주고받는 네트워크 기반의 방식이 생겼다. 그 방식에는 소켓, RPC 등이 존재했으나 맨땅에 데이터 전송기능을 개발해야했고 데이터 안전성에 대한 불안요소가 많았다. 이러한 이슈 해소를 위해 웹을 ‘이용’하게 되었다.(웹을 만든게 아니고 존재하던 것을 ‘이용’한것)
웹을 이용하게 된 배경은 무엇인가? 웹을 살펴보니 웹은 브라우저라는 것이 있었고 요청환경을 가졌으며 요청에 대한 응답이 가능했다.
*웹, 브라우저, 인터넷은 용어의 의미가 다르다.
- WWW : world wide web의 줄임말 : 웹
- 브라우저 : 웹 서버에 접속하여 웹 페이지, 이미지 등 다양한 데이터를 보여주는 소프트웨어
- 인터넷 : 4개의 숫자로 이루어진 IP주소를 부여받아 주소를 통해 서로를 연결하는 통신 기본 체계
과거 ‘CS프로그램’이라 불리며 클라이언트 프로그램과 서버프로그램으로 두 분류로 나뉘었다. 이런 환경에 웹을 이용하여 클라이언트가 ‘페이지’를 요청하면 웹서버에서 데이터를 문서화하여 클라이언트가 요청한 페이지 내용을 리스폰해주면 웹 페이지에 출력되었고 이로써 클라이언트 ‘프로그램’이 사라지게 되었다. 그래서 당시 ‘웹 개발자’ 라고하면 대부분 ‘웹 서버 프로그래머’라고 했다.
*현재는 자바스크립트 등장으로 인해 ‘페이지’를 요청하지 않고 데이터를 요청하게 되면서 브라우저단에 자바스크립트를 이용해서 윈도우 프로그램을 만드는 시대가 도래했고,클라이언트단을 웹의 프론트(Front), 서버쪽을 웹의 서버 단이라하여 백(Back)이라고 부르게 되었다.
웹 서버 프로그램과 Servlet
위와 같이 웹을 ‘이용’해서 프로그램을 만들었지만 새로운 이슈가 발생하게 된다. 웹을 통해 사용자가 회원목록(list)을 요청하면 회원목록을 찾아 웹문서로 전달해줬다. 하지만 회원목록이라는 특징은 어제 혹은 1분 전, 누군가 가입을 했다면 추가된 데이터로 변경됐을 것이며, 실시간 회원목록은 웹문서로 저장되어있지 않고 코드형태로 있기 때문에 웹 서버가 리스폰해주는 정적인 웹문서는 무의미했다.
따라서 요청한 코드를 찾아 해당 코드로 DB에서 회원목록을 문서화해서 돌려줘야 할 필요성을 느꼈다. 이를 위해 코드를 실행할 수 있는 환경이 추가적으로 필요했고 이러한 실행환경을 위해 등장한 것이 WAS(web application server)였다. 이때 동적으로 문서를 만들기 위한 코드들을 ‘Server Application’ 이라 한다.
즉, Server Application을 실행할 수 있게 해주는 환경에는 첫번째 웹서버, 두번째 코드를 찾아 실행해주는 WAS가 필요하다.
Servlet 명칭의 유래는 정확하지 않지만 추측하건데 아래와 같다. 사용자는 GET list / reg / edit / del 의 요청을 하는데 이는 각각 부분적으로 실행 후 수행이 완료되면 삭제된다. 이러한 요청의 구분을 쪼개어 표현해서 ‘SeverApplication’ ‘Let(조각)’, ‘Serv’ + ‘Let’ = ‘Servlet’으로 명한것은 아닐까.
Tomcat 설치 (Web server + WAS)
(추가작성)톰캣설치 및 환경설정
Tomcat에 웹문서 추가하여 출력하기.
톰캣 바이너리 폴더를 보면 실행 배치파일이 있다. 실행하면 뛻뗣땗 이런 한글이 깨지면서 라인이 올라감. 브라우저에 localhost:8080 입력하면 고양인지 호랑인지 나온다.(호랑이 같이 생겼는데 톰캣이니까 고양이겠지 뭐.) 단순히 localhost:8080만을 입력했는데 왜 저런 페이지가 뜨는거냐면 기본 페이지로 index.jsp를 호출하기 때문임. 그럼 다른 웹문서를 출력하려면 홈 디렉터리에 원하는 웹 문서를 넣으면 된다. 여기서 홈 디렉터리란 설치 드라이브/설치폴더/webapps/ROOT를 의미함. 만일 betoru.txt 파일을 생성해서 안에 아무 내용을 입력하고, 실행배치파일을 다시 구동한 뒤 localhost:8080/추가된웹문서 를 입력하면 정상출력 될 것 이다. 여기서는 톰캣의 디렉터리 구조에 대해서 잘 알아두면 된다.
Context 사이트
웹 사이트를 운영하다보면 네이버처럼 점점 규모가 커질 것인데 그렇게되면 개발 인원도 증가하고 하나의 홈 디렉터리로는 형상관리가 어렵게 된다. 그래서 이것을 관리하기 용이하도록 Context 방식이란걸 쓰게된다.(다른 말로는 가상경로, 가상사이트 등으로 표현한다.) context 사이트는 예를 들면 네이버라는 큰 틀은 하나인데 그 안에 부동산, 증권, 웹툰 등등 여러 사이트가 모여있는 것을 볼 수 있다. 마치 하나인 것 같지만 사실은 물리적, 구조적으로는 분리되어 있다. 다시 말해 context site는 앞서 톰캣의 홈 디렉터리 구조처럼 root 하위에 각 사이트를 담당하는 폴더들이 있는 것 같지만 실제로는 없는걸 의미해. 그 각각의 사이트를 context 사이트라고 부른다. localhost:8080/context/resources (context에 해당하지)
이해를 돕기 위해 테스트를 해보면 webapps/root 에 it라는 폴더를 만들고 그 안에 news.txt 라는 텍스트 파일을 만들자. 내용은 아무거나 입력해도 된다. 그리고 localhost:8080/it/news.txt 를 호출하면 웹문서를 확인할 수 있다. 해당 서비스가 너무 커져서 분리시키려고 가정하고 어느 위치든 상관없으나 root 상위 폴더에 옮겨보자. root 하위에는 이제 it 폴더가 없으니 위의 주소를 호출하면 404가 확인된다.
webapps에 conf 디렉터리를 가면 server.xml를 열어 host 태그 내에 context 태그를 추가한다.
<Context path="it" docBase="옮긴폴더위치" privileged="true" />
server.xml을 수정 후 톰캣서버 재시작하여 localhost:8080/it/news.txt 호출하면 노출된다. 이런식으로 컨텍스트를 활용할 수 있다.
*참고 server.xml 수정방식은 톰캣의 버전이 업그레이드 되면서 ‘지양’하라는 공지가 있다. 이유는 server.xml 를 수정시 반드시 서버 재기동을 요구한다. 서비스 중 서버재기동은 치명적이다. 그래서 각 어플리케이션마다 meta-info에 설정할 수 있는데 이건 나중에 알아보자. 지금은 이런 컨텍스트 사이트의 개념을 알고자한 것이니까