connection:Keep-Alive: [Servlet/Jsp] headFirst - Ch2 - 웹 어플리케이션 아키텍쳐

0. 환경

macbook-pro 13” 2012 mid / 10GB
tomcat7
교재: Head First Servlet/Jsp, 한빛미디어, 2012

1. 학습목표

Http method

1) 각각의 사용 목적
2) Http method protocal의 기술적 특징
3) 각 method에 대응되는 HttpServlet method

Servlet

1) 생명주기 이벤트
2) 위 이벤트의 각각의 목적

Web Application 디렉토리 구조

배포 서술자

1) 문법
2) 사용 목적

2. Container

Tomcat은 Web Container로 Servlet의 좋은 예제
Servlet을 실행하고 관리

실행흐름

사용자는 웹 서버(Apache-httpd)에게 Servlet에 대한 요청
웹 서버는 Servlet을 관리하는 Container에게 http요청을 넘김
- Container는 Servlet이 배포(deploy)된 Container
Container는 HttpServletResponse, HttpServletRequest 객체를 만듦
Container는 url분석하여 DD(Deploy Descriptor, 배포 서술자)를 바탕으로 어떤 서블릿에 대한 요청인지 파악
Container는 해당 서블릿 스레드를 생성하여 HttpServletResponse / HttpServletRequest 객체를 인자로 전달
Container는 서블릿 service() 메소드를 호출
Service()메소드는 doGet() 혹은 doPost()를 호출할지 결정
위 method는 동적인 페이지 생성 후 HttpServletReponse 객체에 내용을 실어 보냄
- 보낸 후에도 Container는 HttpServletResponse 객체에 대한 참조를 유지함
스레드 작업 완료시, Container는 HttpServletResponse 객체를 Http 응답으로 전환하여 사용자에게 전달
Conatiner는 Request / Response 객체를 소멸

Container가 주는 혜택

통신 지원
- Servlet과 웹 서버가 서로 통신할 수 방법을 구현하여 API로 제공
- 개발자는 Servlet에서 구현해야할 비지니스 로직에 집중 가능
생명주기 관리
- 서블릿 로딩, 인스턴스화, 초기화 메소드 호출
- 웹 서버로부터 요청시 적절한 서블릿 메소드 호출
- 서블릿 사용 완료 후 가비지 컬렉션 진행
멀티스레딩 지원
- 요청이 들어올 때마다 새로운 스레드 생성
- http 서비스 종료 후 스레스 소멸
선언적 보안 관리
- XML 배포 서술자에 기록
- 서블릿 내부에 보안에 관련된 내용을 하드코딩할 필요없음
JSP 지원
- JSP 코드를 Java 코드로 변환

Servlet을 찾는 방법

클라이언트가 보낸 요청에 들어있는 url을 이용해 서블릿을 찾음
url과 servlet을 맵핑하는 방법은 몇 가지가 있음

3. Servlet

기본 코드

// head first servlet/jsp chapter2, servlet code 예제

import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;

public class Ch2Servlet extends HttpServlet {
    public void doGet (HttpServletRequest request, HttpServletResponse response) throws IOException {
        PrintWriter out = response.getWriter();
        java.util.Date today = new java.util.Date();
        out.println(“<html> “ + “<body>” + “<h1 style=”text-align:center>” + “HF\’s Chapter2 Servlet</h1>” + “<br>” + today + “</body>” + “</html>”);
    }
}

servlet의 대부분은 HttpServlet을 상속 받음
main() method가 없음
웹 브라우져가 요청한 메소드에 따라 호출될 doGet()이나 doPost()를 재정의

이름

url이름
내부적인 이름
실제 파일명
- 파일 위치명
- 디렉토리 구조가 패키지에 대한 정보를 가짐

서블릿의 이름을 다른 이름으로 맵핑하면 어플리케이션의 유연성, 보안성이 좋아짐
디렉토리 구조가 변경되어도 code는 변경할 필요 없음
디렉토리 구조를 외부에서 알 수 없음

4. 배포 서술자

Web Container도 Servlet을 배포하기 위해 배포 서술자 (DD, Deployment Descriptor)라는 XML 파일을 먼저 만들어야 함

장점

이미 테스트된 소스코드에 대한 수정 최소화
소스코드 없더라도 어플리케이션을 목적에 맞게 수정 가능

DD가 할 수 있는 일

보안 역할 설정
오류페이지 설정
항목 라이브러리
초기화 구성
관련정보 설정
etc…

web.xml

<!-- head first servlet/jsp chapter2, DD 예제 -->

<!-- web-app 뒤에는 설정해야할 속성이 첨부됨 -->
<web-app ...>
    <servlet>
        <servlet-name>Internal name 1</servlet-name>

        <!-- 패키지 이름까지 포함된 서블릿 이름 기입 -->
        <servlet-class>foo.Servlet1</servlet-class>
    </servlet>
    <servlet>
        <servlet-name>Internal name 2</servlet-name>
        <servlet-class>foo.Servlet2</servlet-class>
    </servlet>

    <servlet-mapping>
        <servlet-name>Internal name 1</servlet-name>

        <!-- 클라이언크가 사용하는 서블릿 이름 -->
        <url-pattern>/Public1</url-pattern>
    </servlet-mapping>
    <servlet-mapping>
        <servlet-name>Internal name 2</servlet-name>
        <url-pattern>/Public2</url-pattern>
    </servlet-mapping>
</web-app>

서블릿 검색 과정

런타임시 요청이 들어오면

Container는 DD에서 항목을 검색

요청된 url을 바탕으로 servlet-name이 동등한 servlet을 찾아 실행

servlet-class 항목에 패키지 명과 클래스 명만 존재
정확한 경로가 없는 이유는 컨테이너는 정해진 위치에서만 서블릿을 찾기 때문
사실 파일시스템 상의 서블릿 파일을 찾는 과정엔 좀 복잡한 매커니즘이 존재함

5. J2EE

Web Container

Web Component(Servlet, JSP)

EJB Container

Business Component (Session Bean, Entity Bean, Message-Driven Bean)

Tomcat

Web Component만 구현되어있고, Business Component는 구현되어있지 않음
따라서 완벽한 J2EE Application Server가 아님

Written with Dec7.

connection:Keep-Alive

2014년 4월 5일 토요일

[Servlet/Jsp] headFirst - Ch2 - 웹 어플리케이션 아키텍쳐