JSP 정리

1. Get방식과 Post방식의 특성을 비교 설명하시오

1) Get 방식 : URL에 전달하고자 하는 정보를 포함해서 전달하는 방식으로써, URL에 파라미터 정보가 포함한다.

- 장점 : 속도가 빠르다.

- 단점 : 정보가 노출되므로 보안 취약하다. 보내는 정보의 크기가 1024바이트로 제한된다.

 

2) POST 방식 : 전달하고자 하는 정보를 첨부 파일 형태로 포함해서 전송하는 방식으로써, 전송하려는 정보가 HTTP 응답 메시지의 본문에 첨부된다.

- 장점 : URL의 주소 창에 보내는 정보에 대한 노출이 없기 때문에 보안성이 좋다. 보내는 정보의 크기에 제한이 없다.

- 단점 : 속도가 get방식보다 느리다.

 

3) POST 방식이 장점이 많지만 GET 방식이 간편하여 보통 GET 방식과 POST 방식을 적절히 혼용해서 사용한다.

 

2. JSP, Servlet컨테이너가 제공하는 기능을 설명하시오

1) JSP의 기능

- 자바언어를 기반으로 하는 스크립트 언어로서 자바의 장점을 사용할 수 있다

- HTTP와 같은 프로토콜에 따라 클라이언트의 요청을 처리하고 응답한다.

- HTML, XML등 웹 서비스와 관련된 문서를 생성하는데 주로 사용된다.

- 서블릿/EJB 등의 엔터프라이즈 기술들과 잘 융합된다.

- 표현언어, 표현식, 스크립트릿 등의 다양한 ㅅ크립트 요소와 액션 태그등을 제공함으로써 보다 쉽게 웹어플리케이션을 프로그래밍 할 수 있도록 도와준다.

- 자바언어를 기반으로 하고 있기 때문에 플랫폼에 상관없이 사용할 수 있다.

- 자바언어에 대한 깊은 이해가 없더라도 쉽게 배울 수 있다.

- 대규모 어플리케이션을 구현할 때 사용되는 EJB 기술과 완벽하게 호환된다.

 

2) Servlet Container의 기능

- 기본적으로 Servlet Container는 Servlet을 담는 그릇으로 Servlet Code를 저장하는 저장장소 역할을 한다.

- Servlet Container는 Servlet의 탑재, 인스턴스화 및 초기화 등 Servlet의 생명 주기를 관리한다.

- Servlet Container는 Web Server 혹은 Application Server 와 결합되어 요청/응답한다. (Request/Response)

- 패러다임에 따라 Network Service를 제공한다. (MIME기반 요청을 decode하고, MIME기반 응답을 구성 Format 한다.)

- Servlet Container가 자체적으로 HTTP Server(Web Server)기능을 가지고 있는 경우가 대부분이다.

- 멀티 유저 접속 시, Container에서 Thread를 발생 시켜서 동시 접속이 가능하도록 처리한다.

- 종류 : 아파치 자카르타 프로젝트의 톰캣 (Tomcat), 카우쵸(Caucho)의 레진(Resin), IBM의 웹 스피어(WebSpher), 오라클의 OC4J, BEA의 웹로직 (WebLogic) 등

 

 

3. Deployment Descriptor의 역할과 설정 내용에 대해서 설명하시오

- 웹 어플리케이션의 환경설정을 담당하며 web.xml 파일로 존재한다.

- web.xml(DD 파일)은 /server_root/appname/WEB-INF 디렉토리에 있다.

- DD(Deployment Descriptor)는 EJB(Enterprise JavaBean)보다 Portable하게 사용하기 위해 XML로 만들어진 문서이다.

- EJB를 EJB Server에 전개 시키기 직전에 이 DD에 의해 EJB의 성격이 만들어지고 전개 전에는 여러 형태로 수정이 가능하다.

- DD를 만드는 방법은 개발자가 집접  XML문서로 만들 수도 있고 EJB Server에서 제공하는 Deploytool 을 이용하여 DD를 만들어 사용한다.

- 하나의 DD안에는 하나 이상의 EJB 정보가 들어갈 수 없다.

- DD안에는 다음과 같은 정보가 들어간다.

1) EJB의 구조적인 정보

Home Interface Information

Remote Interface Information

Enterprise Bean Class Information

2) Runtime 시에 참조되어지는 정보

Transaction Contol

다른 Bean에 대한 참조 정보

Database에 접근에 대한 정보

3) Security 정보

 

- DD를 이용함으로써 EJB가 Component로서 Bean을 개발할 때 Bean의 특별한 성격을 부여하는 것이 아니라 EJB를 전개하는 시점에서 다양한 형태의 특징을 EJB에 부여할 수 있다.

 

- 장점

이미 테스트된 소스코드에 대한 수정을 최소화한다.

소스 코드가 없더라도, 애플리케이션을 목적에 맞게 수정할 수 있다.

코드 변경이나 컴파일을 다시 하지 않아도 서버자원(DB 연결)을 바꿀수 있다.

접근 제어 목록, 보안역할 과 같은 보안에 관련된 업무도 쉽게 관리할 수 있다.

프로그래머가 아닌 사람이 웹 애플리케이션을 배포하고 설정을 수정할 수 있다.

 

4. 서블릿의 life cycle을 설명하시오

- HTTP에서 사용자가(클라이언트) 서버에 요청(request)을 보내면, web application server에서 servlet파일은 다음과 같은 행위를 수행하게 된다.

Life Cycle

init() -> service() -> destroy()

이것이 서블릿의 Life Cycle이다. 모든 서블릿은 이러한 행위를 프로그래머가 알던지 모르던지 수행을 하게 된다.

1) init()

- 처음에 서블릿이 메모리에 로드되면 init()메소드가 수행된다. init()메소드는 서블릿이 서비스하기 위해 필요한 초기화 작업을 수행한다. 따라서 init()메소드는 서블릿이 실행되기 위해서 필요한 각종 환경을 설정하기 위한 목적으로 사용한다. 예를 들어 데이터 베이스에 연결하기 위한 사전 작업등이 있다.

 

2) Service()

- 초기화 된후에 서블릿은 클라이언트의 요청이 있을 때마다 스레드가 생성되어 병행적으로 service()메소드를 수행한다. service()메소드에서 HTTP의 method 타입에 따라서 GET이면 doGet()를 POST이면 doPost()를 호출하게 될것이다.

 

3) destroy()

- 서블릿이 더이상 서비스를 하지 않거나 메모리가 부족하면 웹 컨테이너에 의해서 서블릿은 메모리에서 언로드된다. 이때 메모리에서 언로드 되기전에 destroy()가 수행된다. Init(), destroy()는 한번씩만 수행되고, 병행적으로 수행되지는 않는다.

 

5. JSP의 life cycle을 설명하시오

- JSP Container(TOMCAT 같은)는 클라이언트가 JSP 페이지를 요청하면 일정한 순서로 JSP 페이지를 처리한다. 이러한 처리는 미리 정의된 특별한 이름을 가진 메소드를 호출함으로써 이루어진다. 마치 c++의 생성자와 소멸자처럼 그와 상응하는 이벤트를 처리하는 jspInit() 메소드와 jspDestroy() 메소드가 존재한다.

1) jspInit() : JSP 페이지가 처음으로 로딩될 때 호출되는 메소드

 

2) jspDestroy() : JSP 페이지의 소멸 이벤트가 발생할 때 호출되는 메소드

- JSP 컨테이너는 클라이언트가 JSP 페이지는 처음으로 요청할 때, JSP 페이지를 서블릿 클래스로 변환한 후 그 서블릿 클래스의 인스턴스를 로딩한다. 이 로딩 과정에서 발생하는 이벤트가 바로 초기화 이벤트이며, 이 처리를 jspInit()이 담당한다. 그와 반대로 소멸 이벤트는 JSP 컨테이너를 셧다운하거나 JSP 컨테이너가 JSP 페이지를 변환한 서블릿 클래스의 인스턴스를 언로딩할 때 발생한다.

- 예시

<%!

       public void jspInit () {

        // put your custom code here

       }

%>

<%!

     public void jspDestory () {

      // put your custom code here

      // to clean up resource

    }

%>

 

6. JSP 내장 객체명과 원형 클래스를 모두 기술하시오

1) request

- HTML Form을 통해 전달되는 값을 가지고 올때 사용

- HTML Form 요소 선택 값과 같은 사용자 입력 정보를 읽어올 때 사용

- javax.servlet.http.HttpServletRequest

 

2) response

- 사용자 요청에 대한 응답을 처리

- 사용자 요청에 대한 응답을 처리할 때 사용

- javax.servlet.http.HttpServletResponse

 

3) out

- 스크립트릿에서 출력하는데 사용

- 사용자에게 전달하기 위한 output 스트림 처리하기 위해 사용

- javax.servlet.jsp.JspWriter

 

4) session

- 한 사용자가 로그인 ~ 로그아웃 까지 보관해야 할 정보를 관리(서버)

- 클라이언트 세션 정보를 처리하기 위해 사용

- javax.servlet.http.HttpSession

 

5) config

- 서블릿이 최초로 메모리에 적재될 때 컨테이너는 서블릿 초기화와 관련된 정보를 읽는다. 이때 설정되는 초기화 정보는 소스에 노출되지 않는데, 수시로 변경되는 공통된 정보 등을 설정할때 사용한다. 초기화 값은 web.xml파일로 작성한다.

- 현재 JSP에 대한 초기화 환경을 처리하기 위해 사용

- javax.servlet.ServletConfig

 

6) application

- 컨테이너와 관련된 여러 정보를 제공, 서블릿이 실행되는 황경이나 서버 자원과 관련한 정보를 얻거나 로그 파일을 기록하는 작업 수행

- 웹 서버의 애플리케이션 처리와 관련된 정보를 참조하기 위해 사용

- javax.servlet.ServletContext

 

7) page

- 서블릿 인스턴스 객체를  참조, 자기자신을 참조할 때 사용

- 현재 JSP 페이지에 대한 클래스 정보

- java.lang.Object type

 

8) pageContext

- 다른 내장 객체에 대한 프로그램적인 접근 방법을 제공 / HTTP 요청을 처리하는 제어권을 다른 페이지로 넘길 때 사용

- 현재 JSP 실행에 대한 context 정보를 참조하기 위해 사용

- javax.servlet.jsp.PageContext

 

9) exception

- page지시어에서 오류 페이지로 지정된 jsp 페이지에서의 예외 처리

- 예외 처리를 위해 사용

- java.lang.Throwable

 

7. RequestDispatcher 방식과 sendRedirect방식의 차이점을 설명하시오

1) RequestDispatcher

- RequestDispatcher는 바인딩을 하여 데이터까지 주소로 넘김.

- 방식

RequestDispatcher rd = request.getRequestDispatcher("주소");

rd.forward(request, response);

- request 전달 가능

- 브라우저 URL 바뀌지 않음

- 주소루트는 컨텍스트 루트

 

2) sendRedirect

- sendRedirect는 페이지를 이동시키기는 하지만 바인딩을 하지 않기 때문에 데이터는 가져 가지않는다.

- session을 통해 데이터를 기억할때는 sendRedirect를 쓰지만 거의 RequestDispatcher가 사용된다.

- 방식

response.sendRedirect("주소");

- request 전달 불가능

- 브라우저 URL 바뀜

- 주소루트의 주소 지정 가능

 

8. MVC 패턴의 특성을 설명하시오

- 모델-뷰-컨트롤러(Model–View–Controller, MVC)는 소프트웨어 공학에서 사용되는 아키텍처 패턴이다. 이 패턴을 성공적으로 사용하면, 사용자 인터페이스로부터 비즈니스 로직을 분리하여 애플리케이션의 시각적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있는 애플리케이션을 만들 수 있다. MVC에서 모델은 애플리케이션의 정보(데이터)를 나타내며, 뷰는 텍스트, 체크박스 항목 등과 같은 사용자 인터페이스 요소를 나타내고, 컨트롤러는 데이터와 비즈니스 로직 사이의 상호동작을 관리한다.

 

9. 세션과 쿠키의 특성과 차이점을 설명하시오

1) Cookie

- 상태 지속의 중요한 방법론으로 쿠키 기법을 이용한다. 쿠키는 처음 Netscape 사에서 정보의 지속성을 위해 고안한 방법으로 HTTP 프로토콜 상에서 클라이언트의 상태 정보를 클라이언트의 하드 디스크 상에 저장한 후 재사용할 수 있다는 방식이다. 여기서 쿠키란 이름 자체는 서버가 클라이언트에 전송하여 저장하는 텍스트 조각을 가리키는 것으로, 이 간단한 텍스트에 클라이언트를 구분할 정보를 담아 전송하는 것이다.

- 웹 프로토콜인 HTTP는 클라이언트에서 어떠한 정보를 요청할 때 접속이 시작되고 요청한 정보의 전송이 끝나면 접속이 끊어지는 형태의 프로토콜이다. 이러한 특징 때문에 서버 상의 부하나, 네트워크의 부하에 대해서는 상당히 효율적이 되지만, 서버에서 사용자가 이전에 어떠한 일을 했는지, 사용자에 대한 정보를 유지할 수 없다는 단점이 있다. 이와 같은 경우에 따라 지속적인 정보의 보존이 필요할 때가 있었기 때문에 쿠키라는 것이 HTTP 프로토콜 사양에 도입되었고, Netscape 2.0에서 먼저 지원을 하기 시작했다.

- 우선 클라이언트는 일반적인 request를 통해서 HTTP 서버에 접속하게 된다. 그리고 서버가 필요하다고 생각되면 쿠키를 생성한 후 response의 헤더를 통해서 Cookie를 클라이언트의 하드디스크 공간에 저장하게 된다. 클라이언트에 저장된 쿠키 정보는 지속적으로 일정한 시간 동안 유지되며 클라이언트가 재접속했을 때 서버의 요청으로 쿠키 정보를 HTTP Request 헤더에 포함시켜서 서버에 로딩할 수 있다.

- 쿠키는 서버 쪽 인터페이스에서 클라이언트에 상태 정보를 저장하고 추출할 수 있는 시스템이다. 쿠키는 매 요청마다 브라우저로부터 서버에게 전송되는 정보 패킷의 일종이며 HTTP 헤더에 포함되어 같이 전송이 된다.

 

2) Session

- 클라이언트와 서버간의 상태를 유지하기 위한 일반적인 방법으로 세션이라는 개념을 이용한다. 클라이어트가 처음 접속했을 때 클라이언트에 유일한 세션 ID를 부여하게 되고 클라이언트는 이 ID를 자동으로 쿠키에 임시 저장하거나, 쿠키가 지원되지 않을 경우에 URL 끝에 붙여 가지고 다니게 된다. 따라서, 이 세션 ID는 클라이언트가 재접속 했을 때 해당 클라이언트를 구분할 수 있는 수단이 된다.

- 당연히 서버에서도 같은 세션 ID를 보관하고 있어야 하며 클라이언트는 서버에 요청을 할 때 부여 받은 세션 ID를 가지고 요청함으로써 서버는 클라이언트를 구분하게 된다. 그리고 서버에 보관된 세션 ID 하나당 메모리를 사용할 수 있게 되며 이 세션 메모리에는 ‘변수=값’의 형식으로 데이터를 보관할 수 있다.

- 서버 입장에서 세션을 생각해 보면 클라이언트가 언제 재접속할 지 모르기 때문에 서버는 클라이언트에게 부여한 세션 ID를 버릴 수도 없는 상황이 된다. 그래서 서버의 세션은 Time 한계를 두어 시간이 만료되면 스스로 세션을 소멸하는 동작을 하게 된다.

- 이러한 방법은 일반적으로 가장 많이 사용하는 방법이며 이 세션의 동작원리는 전자상거래의 login된 상태의 구분이나 클라이언트의 보유 정보등을 동적으로 관리하는 곳에 주로 사용된다.

 

3) Cookie와 Session의 비교

1) 저장되는 곳

- 쿠키는 클라이언트의 웹 브라우저가 지정하는 메모리 또는 하드디스크에 저장된다. 하지만 세션은 생성된 후 서버의 메모리에 저장된다. 그렇지만 클라이언트 측에서 쿠키사용을 하지 않도록 브라우저를 세팅해 놓으면 쿠키는 저장되지 않는다.

 

2) 만료시점

- 쿠키는 저장할 때 expires 속성을 정의해서 무효화 되어 삭제될 날짜를 정확히 지정할 수 있다. 하지만 세션은 클라이언트측에서 로그아웃 하거나, 설정한 시간동안 클라이언트측의 반응이 없을 경우에만 무효화되므로 정확한 만료시점은 알 수 없다.

 

3) 리소스

- 쿠키는 클라이언트 측에 저장되고 클라이언트의 메모리를 사용하기 때문에 서버상의 자원을 쓰지 않는다. 하지만 쿠키는 서버에 저장되고, 서버의 메모리로 로딩되기 때문에 세션이 생성될 때마다 그만큼의 리소스를 차지하게 된다.

 

4) 용량 제한

- 쿠키는 클라이언트도 모르게 접속되는 사이트에 의하여 설정될 수 있다. 따라서 쿠키로 인하여 문제가 발생하지 않도록 하기 위하여 한 도메인당 20개, 총 300개, 그리고 하나의 쿠키당 4kb로 저장 용량을 제한해 놓는다.  하지만 세션은 클라이언트가 접속하면 서버에 의해서 생성되므로 그 개수나 용량에 제한이 없다.

 

10. JSP의 구성 요소들에 대해서 설명하시오

1) 디렉티브

- JSP 페이지에 대한 설정 정보를 지정할 때 사용된다.

- JSP가 제공하는 디렉티브는 page, taglib, include가 있다

- 형식

<%@ 디렉티브이름 속성1="값1" 속성2="값2" @>

<%@ page contentType = "text/html; charset=euc-kr" @>

 

2) 스크립트 : 스크립트릿, 표현식, 선언부

- 스크립트 요소는 사용자가 입력한 정보를 DB에 저장할 수 있으며 읽어와 출력도 가능하다.

- 스크립트 요소에는 스크립트릿(자바코드를 실행한다.), 표현식(갑을 출력한다), 선언부(자바 메소드를 만든다)가 있다.

- 스크립트릿 : 소스 코드 실행할 때 사용.

예시 : <% int c = add(3,5) %>

- 표현식 : 값을 출력할 때 사용.

예시 : <%= c %>

- 선언부 : 자바 메소드, 변수 선언할 때 사용.

예시 : <%! public int add(int a, int b){ return a+b; } %>

 

3) 표현언어

- JSP페이지 내부에서 사용되는 간단한 스크립트 언어이다.

- JSP2.0 버전부터 추가된 것으로 스크립트릿과 표현식 대신에 쉽고 간단하게 사용할 수 있다.

 

4) 기본객체(내장객체)

- jsp에서 기본적으로 제공해주는 객체.

- 앞서 설명

 

5) 정적인 데이터

 

6) 표준 액션 태그

- 액션 태그는 XML의 태그와 같은 모양을 취하며 <jsp:액션태그이름> 형식이다.

- 예시 : <jsp:forward page = "form.jsp"/>

 

7) 커스텀 태크

- 사용자가 직접 정의 하여 사용하는 태그.

- JSP를 확장시켜 주는 기능

- 액션 태그와 마찬가지로 태그 형태로 기능을 제공

- 액션 태그와 차이점 : 개발자가 직접 개발하여 주어야 함

8) 표준 태그 라이브러리