|
내가 WAS(Web Application Server)에서 개발을 처음 시작한 것은 1999년이었다. 남들은 "세기말이다", "Y2K문제가 심각하다" 이러고 있을 때... 모 은행 개발실에서 열심히 ASP(Active Server Page)를 이용하여 프로그램을 작성하고 있었다.
당시에는 HTML을 사용하여 자신의 홈페이지를 만드는 데 관심이 집중되었으며, 기업의 홈페이지를 관리해 주기 위한 웹 마스터가 인기가 있었다. 컴퓨터 학원에서는 쇼핑몰을 만들기 위해서 정적인 컨테츠(Static Contents)보다는 동적인 컨텐츠(Dynamic Contents)를 만드는 Script 언어와 ASP를 사용하는 방법에 대한 강의가 많았다. 이때, IT 업계에 몇몇 스타들이 탄생했는데... ASP의 전문가로 이름을 날렸던 태요(김태형)님도 이 당시 등장했던 것 같다. http://www.taeyo.pe.kr/
ASP의 대세에 대항하기 위하여 1999년에 SUN이 JSP(Java Server Page)를 발표하였지만, http://en.wikipedia.org/wiki/JavaServer_Pages)
워낙 ASP가 강세여서, JSP나 Servlet은 별로 주목받지 못할 것이고 앞으로도 그럴 것 같았다. 하지만, 웹 애플리케이션의 적용 범위가 개인이나 소규모가 아닌 대규모 웹 애플리케이션으로 옮겨가자 Java진영이 힘을 얻기 시작했다.
이런 현상이 일어나는 근본적인 원인은, Microsoft사의 제품이 Windows만 지원하기 때문인 것 같다. 최근에는 Itanium 칩을 사용하는 High-End급 서버(HP의 Superdome 등)가 시장에서 활약하고 있지만, 이전의 RISC 칩 기반 UNIX 머신에서는 MS사의 IIS(Internet Information Service, MS의 대표적인 WAS)가 동작되지 않았고 이로 인하여 ASP를 사용할 수 없었다.
결국, UNIX 환경에서 WAS는 Java기반으로 만들어 졌으며 (이러한 WAS가 유행하기 전에 CGI 프로그램들이 있었으나, CGI가 세션을 처리할 때 프로세스(Process)로 기동하여 UNIX 머신에 과부하를 주는 바람에, 결국은 쓰레드(Thread) 기반인 WAS가 승기를 잡았다), 다양한 제품들 WebLogic, WebSphere, Jeus 등이 쏟아져 나왔다.
그렇다. 지금은 ASP가 ASP.NET으로 진화되어 왔지만, 대규모 웹 애플리케이션 개발에는 JSP나 Servlet이 더 많이 사용되고 있는 것이다.
JSP나 Servlet에 관련된 수많은 책들이 출간되었다. 그럼에도 불구하고, 이번에도 Head First 시리즈를 기반으로 리뷰를 하고자 한다. Head First 시리즈는 개념을 잡는데 큰 도움을 주는 책이다. 하지만 실전에서 필요한 내용을 바로 찾아서 보려면 다소 부족한 부분들이 많다. 따라서 Head First 시리즈는 개념을 잡는데 주로 사용하고, 보다 자세한 내부 작동원리는 Budi Kurniawan 의 "톰캣 최종분석" 을 읽어보기 바란다.
다음은 HeadFirst 책의 내용을 간략히 요약한 것이다.
--------------------------
원래 이 책은 J2EE 1.4 SCWCD 시험을 대비하여 출간된 것이지만, 여기서는 이러한 시험에 대해서는 언급하지 않겠다.
1. 먼저 간략히 알아 봅시다 - 서블릿과 JSP믄 어디에 쓰는 물건인고?
Head First의 책에서 제일 마음에 드는 부분은 그림이 많다는 것이다. 이 장에서도 클라이언트가 요청(Request)를 하면 서버가 응답(Response)하는 내용에 대해서 그림을 그려서 알기 쉽게 설명하고 있다. 여기서 요청(Request)과 응답(Response)라는 개념에 대해서 잘 알아 두어야 한다. 왜냐하면, JSP던지 Servlet이던지 Request는 클라이언트측에서 요청한 정보를 포함하고 있고, Response는 서버에서 처리된 결과를 클라이언트 측에 반환하기 위한 용도로 사용되기 때문이다.
HTML(Hyper Text Markup Language)에 대한 간략한 설명이 있다. HTML에 대해서 자세히 알고 싶다면 다른 책을 참조하는 것이 좋을 것이다. IE(Internet Explorer) 9.0에서는 HTML 5를 지원한다고 하니 HTML5와 CSS3에 관련된 책을 읽어보기를 권장한다.
HTTP(HyperText Transfer Protocol)에 관하여 설명하고 있다. TCP/IP 기반에서 HTTP이 수행된다는 이야기를 하고 있다. HTTP 프로토콜에 대해서 깊이 들어가면 다뤄야 할 내용들이 많다. 일단 HTTPSession에 대해서는 http://tobewiseys.tistory.com/72 을 참조하자.
실제로 브라우저 - client socket - server socket - WAS의 연결을 통하여 Request와 Response가 이루어지는 내용에 대해서는 "톰캣 최종분석" 1장과 2장을 보면 프로그램 레벨에서 상세하게 이해할 수 있다.
웹브라우저에서 HTTP로 서버에 요청을 할 때 URL을 이용하는 GET방식과 메시지 몸체(body)에 요청정보를 저장하는 POST방식에 대해서 설명하고 있다. GET방식은 보안이슈나 제한된 길이 때문에 가급적 사용을 자제하는 편이어서 POST방식을 주로 사용한다고 이해하면 되겠다.
MIME(Multi-Purpose Internet Mail Extensions)에 대해서 설명하고 있는데, 이는 서버가 보낸 HTTP 응답을 웹브라우저가 어떤 형식으로 해석할 것이지 알려주는 정보라고 이해하면 되겠다. MIME의 이름에서 알 수 있듯이 원래는 이메일에서 텍스트가 아닌 다양한 컨테츠를 보내기 위해서 메일전송 프로토콜을 확장한 것이다. MIME 타입을 잘못 지정하거나 웹부라우저에서 처리할 수 있는 plugin이 없는 경우의 기본 동작은 내려받기(download)이다. 특정 프로젝트에서 특정한 형식의 파일에 대해서 download 여부를 묻는 창이 나타나지 않게 해달라고 해서 고생했었던 적이 있었다.
IT에서 영어 약자가 3자이하이면 의사소통을 명확히 하기 위해서 철자를 그대로 발음해 준다. 예를 들어 ASP는 "에이 에스 피"로 JSP는 "제이 에스 피"와 같이 읽는다. 같은 이유로 SOA는 "에스 오 에이"라고 읽어야 하는데, 다양한 분야의 사람들이 접하다 보니 "소아", "쏘아" 등으로 발음하기도 한다. URL 역시 "얼" 이라고 하면 다른 사람이 못알아 들을 확률이 크므로 "유 알 엘"이라고 발음해 주는 것이 좋다고 이야기하고 있다.
URL(Uniform Resource Locators)의 구조가 프로토콜://서버주소:포트번호/자원경로/자원명 와 같은 구조로 이루어져 있다는 것을 설명하고 있다. 여기서 서버주소는 서버의 DNS 명이나 IP주소를 사용하면된다. localhost 또는 127.0.0.1이면 자기가 사용하고 있는 컴퓨터를 의미한다고 이해하면 되겠다.
포트번호를 설명하기 위하여 TCP 포트에 대해서 설명하고 있다. 사실 포트번호하면 예전에는 마우스나 키보드를 연결하기 위한 Serial Port를 생각하기 쉬운데, TCP포트는 특정 서버 내의 특정 애플리케이션(서비스, 소프트웨어)와 연결을 위한 논리적으로 구분되는 번호로 이해해야 한다. 일반적으로 1023번 이하는 이미 널리 알려진 서비스들을 위해서 예약되어 있다. 80번 포트가 HTTP를 위하여 예약되어 있고... 톰캣 같은 경우에는 8080 포트번호를 사용한다. 오라클은 1521번, MS SQL Server는 1433번을 디폴트 포트번호로 사용한다.
즉, 외부에서 특정한 클라이언트 소켓이 1433번 포트번호로 연결하면 해당 서버의 MS SQL Server와 통신하는 것을 기대하는 것이고, 클라이언트 소켓이 1521번 포트번호로 연결하면, 해당 서버의 Oracle과 통신하는 것을 기대하게 된다.
어떤 서버에 특정 port번호로 특정 서비스가 제공되는지 확인하는 간단한 방법은 telnet을 이용하는 것이다.
예를 들어 192.168.1.1이라는 서버에서 오라클이 정상적으로 서비스가 되고 있는지 확인하는 방법은
첫 번째 ping을 이용하여 해당 서버가 살아 있는지 확인하고,
ping 192.168.1.1
두 번째는 telnet을 이용하여 해당 서비스가 정상작동하는지 호출해 본다.
telnet 192.168.1.1 1521
위와 같이 텔넷으로 1521번 서비스(Oracle)를 호출했을 때 연결된 상태에서 커서가 깜박이고 있다면 서비스가 정상적으로 기동되고 있는 것이다.
다음으로 자원경로와 자원명은 디렉토리 구조와 함께 설명되고 있다. 처음 웹 애플리케이션을 접하는 개발자들이 가장 혼란스러워 하는 부분이 이 부분이다. Context Root, Web Root 등의 용어로도 사용되는데, 여하튼 URL에서 나오는 자원 경로의 시작점과 서버의 실제 파일시스템 디렉토리의 특정지점과 일치시키는 작업이 필요하다. 대부분의 WAS에서는 웹루트의 디폴트 위치가 지정되어 있다. 이 위치는 환경설정파일을 수정해서 바꿀 수 있다. IIS에서는 자원경로를 Virtual Directory라고 이야기한다.
웹서버 단독으로는 동적인 컨테츠를 만들거나, 서버에 데이터를 저장할 수 없으며, 이러한 동작을 하기 위해서는 CGI(Common Gateway Interface)나 서블릿의 도움을 받아야 하며, CGI가 프로세스로 기동하면 너무 무겁다는 이야기를 하고 있다.
마지막으로 서블릿을 작성, 배포, 실행하는 부분에 대해서 설명하고 있다. 아마도 이 부분이 처음개발하는 개발자에게 헷갈릴 것이다. 일단 개발환경과 운영환경으로 구분해서 이해하고
1) 개발환경의 디렉토리는 프로젝트명 폴더아래 src, classes, etc와 같이 3개의 하위 폴더가 존재하며,
2) 개발자는 src 디렉토리에서 서블릿 코드를 java 파일로 만들고
3) 컴파일하여 classes 폴더에 .class 파일 생기게 할 것이다.
4) 또한, etc 폴더에서 web.xml 파일내에서 환경을 설정할 것이다 (2가지 매핑을 해야 한다. 서블릿명과 class명, 서블릿명과 URL패턴)
위와 같이 개발이 끝나면 위의 결과를 운영환경에 배포해야 한다.
1) 디폴트 웹루트 위치가 tomcat/webapp 라면, 이 폴더 아래 웹 애플리케이션 폴더명이 존재할 것이고 그 아래 WEB-INF폴더를 생성한다.
2) 개발환경에서 생성된 .class 파일들을 운영환경 WEB-INF/classes 폴더 아래로 복사
3) 개발환경의 etc 폴더아래 web.xml 파일을 운영환경 WEB-INF로 복사
실행은
1) 톰캣을 실행하고
2) 웹 브라우저에서 URL을 이용하여 호출하면 된다.
마지막으로, 서블릿과 같이 Java 프로그램안에서 HTML 코드를 작성하면은 컴파일 오류가 발생하기 쉽고 관리가 어렵기 때문에, JSP와 같이 HTML안에 자바코르를 작성하는 방식이 필요하다는 것을 이야기하고 있다.
----------------
1장만 이야기했는데도 글이 길어지고 있다. 2장 이후는 다른 글에서 올리도록 하겠다.
|