IT_Programming/JSP · Servlet

컨테이너에 대해서...

JJun ™ 2007. 6. 25. 21:22
LONG
컨테이너는 요청을 어떻게 다룰까요?
 
1. 사용자가 서블릿에 대한 링크를 클릭합니다.
 
2. 컨테이너는 들어온 요청이 서블릿이라는 것을 간파하곤 다음 두 객체를 생성합니다.
    1) HttpServlerResponse
    2) HttpServletRequest
 
3. 사용자가 날린 URL을 분석하여 어떤 서블릿에 대한 요청인지 알아냅니다.
   (여기서 DD를 참조합니다.) 그 다음 해당 서블릿 스레드를 생성하여 Request/Response 객체를
   인자로 넘깁니다.
 
4. 컨테이너는 서블릿 service()메소드를 호출합니다. 요청에 지정한 방식(Method)에 따라 doGet()
   을 호출할지, doPost()를 호출할지 결정합니다. 여기서는 일단 HTTP GET 방식이라고 가정합시다.
 
5. doGet()메서드는 동적인 페이지를 생성한 다음, 이를 Response 객체에 실어 보냅니다.  보내고 난
   후에도 컨테이너는 Response 객체에 대한 참조(레퍼런스)를 가지고 있다는 것을 잊지 마세요
 
6. 스레드 작업이 끝나면, 컨테이너는 Response 객체를 HTTP Response로 전환하여 클라이언트로
   내려 보냅니다.이제 마지막으로 Request와 Response 객체를 소멸시킵니다.
 
 
코드는 어떻게 생겼을까? (무엇이 서블릿을 서블릿답게 만드는가?)
/* 서블릿에는 main() 함수가 없다는 것을 잊지 마세요. 컨테이너가 서블릿의 생명주기 관련 메소드
    (예를 들면, doGet())를 호출합니다. */
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
 
public class Ch2Servlet extends HttpServlet // 서블릿 중 99.9%는 HttpServlet을 상속받는다.
{
  public void doGet(HttpServletRequest request, HttpServletResponse response)
  throws IOException
 /*
     실제 프로젝트에서 서블릿 중 99.999%은 doGet()과 doPost() 메소드만 재정의한다.
     request, response: 여기서 바로 컨테이너가 생성한 Request와 Response 객체 참조를 넘겨 받는
     곳입니다.
 */
  {
     PrintWriter out = response.getWriter();
    /* 서블릿이 넘겨준 Response 객체안에는 PrintWriter가 들어있죠.
         Response 객체에 HTML 코드를 작성하고 싶다면 이 PrintWriter를 사용하세요.
         PrintWriter 말고도 다양한 출력 옵션이 있는데, HTML이 아닌 이미지 같은 것을 출력하고자
         할 때 사용하면 됩니다.*/    
     java.util.Date today = new java.util.Date();
     ou.println("<html>"+"<body>+"~~~~");
  }
}
ARTICLE

컨테이너, 넌 누구냐?

서블릿에는 main() 메서드가 없다는데, 서블릿은 컨테이너라 부르는 자바 애플리케이션의 지배를

받습니다. 톰캣은 컨테이너의 좋은 예제입니다. 아파치와 같은 웹 서버가 사용자로부터 서블릿에

대한 요청을 받으면, 서블릿을 바로 호출하는 것이 아니라, 서블릿을 관리하고 있는 컨테이너에게

이 요청을 넘깁니다. 여기서 컨테이너란 물론 서블릿이 배포된 컨테이너를 말하겠죠.

요청을 넘겨받은 컨테이너는 HTTP Request와 HTTP Response 객체를 만들어, 이를 인자로

서블릿 doPost()나 doGet() 메소드 중 하나를 호출합니다.

 

 

자바는 있는데 서블릿이나 컨테이너가 없다면?

아파치와 같은 웹 서버에서 사용자 요청을 동적으로 처리하기 위한 자바 프로그램을 개발하고 싶다면

어떻게 해야 할까요? 물론 톰캣과 같은 컨테이너가 있다면 이를 이용하면 되지만, 컨테이너가 없다면?

가지고 있는 것이라곤 J2SE 라이브러리 밖에 없고 서블릿이란 건  눈을 씻고 찾아봐도 없을 때 말이죠.

과연 웹 서버 환경을 적절히 설정하여 애플리케이션이 돌아 가도록 만들 수 있을까요?

컨테이너에 대한 사전 지식이 없어도 말입니다. 여기서 해볼만한 것은 서버에서 돌아가는 웹 애플리케이션을 만드는 것인데 이 애플리케이션은 서블릿이 아닌 일반 자바코드로 만든 것입니다.

 

 

컨테이너가 주는 혜택

1. 통신(커뮤니케이션) 지원

    : 컨테이너는 서블릿과 웹 서버가 서로 통신 할 수 있는 손쉬운 방법을 제공합니다.

      다시 말하면, 서버와 대화하기 위하여 개발자가 직접 ServerSocket을 만들고, 특정 포트에

      리스닝하고, 연결요청이 들어오면 스트림을 생성하는 등 이런 복잡한 일련의 일을 할 필요가

      없다는 것이다. 컨테이너는 어떻게 웹 서버와 통신해야 하는지 잘 알고 있으며, 이런 통신 기능을

      API로 제공합니다. 따라서 웹 서버(아파치)와 서블릿이 서로 통신하기 위한 통로인 통신 API에 대해

      개발자가 고민할 필요가 없다는 겁니다. 개발자가 신경 쓸 부분은 바로 서블릿에 구현해야 할

      비지니스 로직이죠. 예를 들자면, 온라인 상점에서 주문을 어떻게 처리할 것인가를 말할 수 있겠죠.

2. 생명주기(라이프 사이클 관리)

    : 컨테이너는 서블릿의 탄생과 죽음을 관리합니다. 개발자 관점에서 보자면, 서블릿 클래스를

      로딩하여 인스턴스화하고, 초기화 메소드를 호출하고, 요청이 들어오면 적절한 서블릿 메소드를

      호출하는 작업을 컨테이너가 한다는 말이죠. 서블릿이 생명을 다한 순간에는 적절하게 가비지

      컬렉션을 진행할 겁니다. 여러분이 이런 막강한 컨테이너를 가지고 있다면, 어떻게 서블릿 자원을

      관리할까라는 고민은 접어두어도 괜찮겠죠.

3. 멀티 쓰레딩 지원

   : 컨테이너는 요청이 들어올 때마다 새로운 자바 스레드를 하나 만듭니다. 클라이언트의 요청에 따라

     적절한 HTTP 서비스 메소드를 실행하면 그걸로 스레딩 작업은 끝이 나죠(스레드가 죽는다는 말)

     정말 이렇게 간단하나요? 스레드 안전성에 대하여 개발자가 뭔가하지 않아도 되나요?

     그렇습니다. 개발자가 할 것은 없으니 걱정 놓으세요. 서버가 다중 요청에 대한 스레드 생성 및

     운영에 대해서 알아서 해주니 개발자로서는 여간 고마운 일이 아닐 수 없지요.

4. 선언적인 보안관리

   : 컨테이너를 사용하면, 보안에 관련된 내용을 서블릿 또는 자바 클래스 코드 안에 하드코딩

     (필요한 데이터나 값, 코드 등을 직접 타이핑해서 집어넣는 일)할 필요가 없습니다.

     컨테이너가 있는 환경이라면 보안관리는 XML 배포 서술자에다가 기록하면 됩니다.

     이 말은 보안에 대해 뭔가 수정할 일이 생기더라도, 자바 소스 코드를 수정하여 다시 컴파일

     하지 않아도 보안관리가 가능하다는 말입니다.

5. JSP 지원