java - Servlet

컨테이너가 관리하는 서블릿

1. 사용자가 서블릿에 대한 링크(URL)를 클릭합니다.
2. 컨테이너는 요청된 Request가 서블릿이라는 것을 간파하고는 다음 두 개의 객체를 생성합니다.
1. HttpServletResponse
2. HttpServletRequest
3. 접수한 요청의 URL을 분석하여 어떤 서블릿을 요청했는지 파악합니다(여기서 DD를 참조합니다). 그 다음 해당 서블릿 스레드를 생성하여 Request, Response 객체 참조를 넘깁니다.
4. 컨테이너는 서블릿 service() 메소드를 호출합니다. 브라우저에서 지정한 방식에 따라 doGet()을 호출할지, doPost()를 호출할지 결정합니다.
   클라이언트가 HTTP GET 메소드를 날렸다면, service() 메소드는 서블릿의 doGet() 메소드를 호출합니다. 호출할 때 Request와 Response 객체를 인자로 넘깁니다.
5. 서블릿은 클라이언트에게 응답을 작성(write)하기 위하여 Response 객체를 사용합니다. 이 작업을 완료하면, Response에 대한 제어는 컨테이너에게 넘어갑니다.
6. service() 메소드가 끝나면, 스레드를 소멸하거나 아니면 컨테이너가 관리하는 스레드 풀(Pool)로 돌려보냅니다. 그 다음 Request와 Response 객체는 가비지 컬렉션이 될 준비를 할 것이며, 이 객체에 대한 참조는 이제 범위를 벗어나기에 사라집니다.
   마지막으로 클라이언트는 서버로부터 응답을 받게 됩니다.

서블릿의 일생은 사실 매우 간단합니다. 왜냐하면 서블릿은 오직 하나의 중요한 상태를 가지기 때문입니다. 여기서 중요한 상태는 초기화(initialized)를 말합니다. 서블릿이 초기화되지 않았다는 말은, 초기화되는 중(생성자를 실행하거나 init()메소드를 실행하거나)이거나, 아니면 소멸되는 중(destroy() 메소드를 실행)이거나, 그것도 아니면 존재하지 않음(dose not exist) 중 하나라는 말입니다.

1. 웹 컨테이너가 클래스 로딩 후 서블릿 인스턴스화(생성자 실행)
   디폴트 생성자(인자가 없는) 실행(생성자를 코딩하지 마세요. 컴파일러가 자동으로 만들어주는 것을 사용하면 됩니다)
2. init()
   서블릿 일생 중 한번만 호출됨. init() 메소드는 service() 메소드 전에 실행되어야 합니다.
   데이터베이스에 대한 접속, 다른 객체에 서블릿을 등혹하는 것과 같은 초기화 코드가 있다면 init() 메소드를 재정의합니다. 재정의하지 않으면 GenericServlet()의 init()이 실행됩니다. 그 다음 요청이 들어오고, 컨테이너가 새로운 스레드를 만들거나 아니면 하나를 할당합니다. 그리고 service() 메소드를 호출합니다.
3. service() : 여기서 일생의 대부분을 보냅니다. 재정의하지 않았다면, 당연히 HttpServlet의 service() 메소드가 실행됩니다.
   클라이언트 요청을 핸들링함. doGet(), doPost() 등. 요청이 들어올 때마다 새로운 스레드에서 실행됨.
4. destroy()
   서블릿이 죽기 전에 가지고 있는 자원들을 깨끗이 정리할 기회를 줍니다. init() 메소드처럼 오직 한번만 호출됩니다.

메소드 상속

<인터페이스>Servlet <- GenericServlet <- HttpServlet <- MyServlet

Servlet 인터페이스

(javax.servlet.Servlet)

Servlet 인터페이스를 보면 알겠지만, 모든 서블릿은 다섯 가지 메소드를 가져야 합니다. 이 중 굵게 쓴 것 3개가 생명주기(라이프사이클) 메소드입니다.

• service(ServletRequest, ServletResponse)
• init(ServletConfig)
• destroy()
• getServletConfig()
• getServletInfo()

GenericServlet 클래스

(javax.servlet.GenericServlet)

GenericServlet은 추상 클래스입니다. 필요한 대부분의 서블릿 메소드를 구현했으며, 여기에는 Servlet 인터페이스에 정의된 것도 있습니다. 이 클래스를 상속받아 클래스를 생성할 일은 거의 없을 겁니다. 하지만 대부분 서블릿의 '서블릿 행위'라고 하는 것들이 바로 이 클래스로부터 나왔다는 것은 기억하세요.

• service(ServletRequest, ServletResponse)
• init(ServletConfig)
• init()
• destroy()
• getServletConfig()
• getServletInfo()
• getInitParameter(String)
• getInitParameterNames()
• getServletContext()
• log(String)
• log(String, Throwable)

HttpServlet 클래스

(javax.servlet.http.HttpServlet)

HttpServlet도 추상 클래스입니다. HttpServlet은 서블릿의 HTTP적인 측면을 반영하기 위하여 service() 메소드를 재정의하는 것입니다. 즉 service() 메소드는 오로지 HTTP Request와 Response만 받아들이고 다른 어떤 서블릿 Request와 Response는 받지 않는다는 말입니다.

• service(HttpServletRequest, HttpServletResponse)
• service(ServletRequest, ServletResponse)
• doGet(HttpServletRequest, HttpServletResponse)
• doPost(HttpServletRequest, HttpServletResponse)
• doHead(HttpServletRequest, HttpServletResponse)
• doOptions(HttpServletRequest, HttpServletResponse)
• doPut(HttpServletRequest, HttpServletResponse)
• doTrace(HttpServletRequest, HttpServletResponse)
• doDelete(HttpServletRequest, HttpServletResponse)
• getLastModified(HttpServletRequest)

MyServlet 클래스

여러분이 작성할 서블릿의 대부분 행위는 상위 클래스의 메소드를 상속받음으로써 해결됩니다. 여러분이 할 일은 필요한 HTTP 메소드를 재정의하는 일밖에 없습니다.

서블릿 일생에 있어 3번의 중요한 순간들

	호출되는 시점	목적	재정의
init()	컨테이너는 서블릿 인스턴스를 생성한 다음 init() 메소드를 호출합니다. 이 메소드는 service() 메소드 전에 실행되어야 합니다.	클라이언트의 요청을 처리하기 전에 서블릿을 초기화할 기회를 주는 것입니다.	가능합니다. 초기화할 코드가 있다면 init() 메소드를 재정의하세요(데이터베이스에 대한 접속, 다른 객체에 서블릿을 등록하는 등).
service()	최초 클라이언트의 요청을 받았을 때, 컨테이너는 새로운 스레드를 생성하거나, 아니면 스레드 풀로부터 하나를 가지고 와서 서블릿의 service() 메소드를 호출합니다.	클라이언테의 HTTP 메소드(GET, POST 등)를 참조하여 doGet()을 호출할지, doPost()를 호출할지 판단합니다.	거의 하지 않습니다. service() 메소드를 재정의할 필요는 없습니다. doPost()나 doGet()을 재정의하여 HttpServlet의 service()가 이를 실행하도록 하면 됩니다.
doGet() 또는/혹은 doPost()	service() 메소드가 클라이언트의 HTTP 메소드(GET, POST등)를 참조하여 doGet() 또는 doPost()를 호출합니다. 여기서 doGet(), doPost()만 언급하는 이유는 이것말고 나머지는 사용할 경우가 거의 없기 때문입니다.	여기에다가 코딩을 하면 됩니다. 어떤 웹 애플리케이션이든지, 무엇을 하든지 관계없이 이곳이 바로 그 작업을 하는 곳입니다. 물론 다른 객체에 있는 다른 메소드를 호출할 수 있습니다. 하지만 모두 여기에서부터 시작합니다.	항상, 둘 중 하나는 반드시(doGet()이든 doPost()든) 재정의합니다. 서비스 하고자 하는 메소드를 재정의하세요. 만약 doPost()를 재정의하지 않았다면, 컨테이너는 "이 서블릿은 HTTP POST를 지원하지 않는구나"라고 생각할 것입니다.

서블릿의 일생은 컨테이너가 서블릿 파일을 찾아서 로딩할 때부터 입니다. 이 작업은 거의 컨테이너가 시작할 때(예를 들면, 톰캣이 실행될 때) 이루어집니다. 컨테이너가 시작되면, 컨테이너는 배포된 웹 애플리케이션이 어떤 것이 있는지 체크하고, 관련 서블릿 클래스 파일을 검색합니다.

첫 번째 단계가 바로 클래스를 찾는 것이죠.

클래스를 로딩하는 것은 두 번째 단계입니다. 이 작업은 컨테이너마다 차이가 있는데 컨테이너가 시작될 때 로딩하기도 하고, 최초 클라이언트 접근 시 로딩하기도 합니다. 서블릿을 일찍 로딩하든 아니면 실행 시(Just-In-Time)에 로딩하든 관계없이, service() 메소드는 서블릿 초기화가 완전히 완료된 다음에 실행된다는 것입니다.

리뷰

• 컨테이너는 서블릿을 로딩합니다. 그 다음 디폴트 생성자를 호출하고, init() 메소드를 실행합니다.
• init() 메소드(개발자가 재정의할 수 있음)는 서블릿 일생 중 단 한번만 호출됩니다. 이 호출도 클라이언트에게 서비스를 제공하기 전(service() 메소드가 호출되기 전)에 실행됩니다.
• init() 메소드에서 ServletConfig 객체와 ServletContext 객체에 접근할 수 있습니다. 이 두 객체를 통해 서블릿 및 웹 애플리케이션 설정 정보를 파악할 수 있습니다.
• 컨테이너는 서블릿의 destroy() 메소드를 호출하여 서블릿 일생을 마감합니다.
• 서블릿은 일생의 대부분을 클라이언트 요청에 대한 응답으로 service() 메소드를 실행하는데 보냅니다.
• 서블릿에 대한 클라이언트 요청은 별개의 스레드에서 실행됩니다. 서블릿 인스턴스는 하나 밖에 없습니다.
• 서블릿 작성은 javax.servlet.http.HttpServlet을 상속 받는 것에서부터 출발합니다. HttpServletRequest와 HttpServletResponse를 인자로 하는 HttpServlet의 service() 메소드를 그대로 상속받아 사용합니다.
• HttpServlet은 대부분 기본적인 서블릿 메소드가 이미 구현된 추상 클래스인 javax.servlet.GenericServlet을 상속 받습니다.
• GenericServlet은 Servlet 인터페이스를 구현한 것입니다.
• 서블릿 클래스들은 모두(JSP 관련된 것 제외) javax.servlet과 javax.servlet.http 두 패키지에 속합니다.
• init() 메소드를 재정의하는 것도 가능합니다. 그러나 doGet()과 doPost() 중 하나는 반드시 재정의해야 합니다.

출처 - http://www.silverwolf.co.kr/9906

---

자바 서블릿(Java Servlet)은 자바를 사용하여 웹페이지를 동적으로 생성하는 서버측 프로그램 혹은 그 사양을 말하며, 흔히 "서블릿"이라 불린다.

자바 서블릿은 자바 EE 사양의 일부분으로, 주로 이 기능을 이용하여 쇼핑몰이나 온라인 뱅킹 등의 다양한 웹 시스템이 구현되고 있다.

비슷한 기술로는 펄 등을 이용한 CGI, PHP를 아파치 웹 서버 프로세스에서 동작하게 하는 mod_php, 마이크로소프트사의 IIS에서 동작하는 ASP 등이 있다. CGI는 요청이 있을 때마다 새로운 프로세스가 생성되어 응답하는 데 비해, 자바 서블릿은 외부 요청마다 프로세스보다 가벼운 스레드로써 응답하므로 보다 가볍다. 또한, 자바 서블릿은 자바로 구현되므로 다양한 플랫폼에서 동작한다.

[편집]버전의 역사

자바 서블릿 API 역사

서블릿 API 버전	발표	자바 플랫폼	중요한 변화
Servlet 3.0	2009년 1월	JavaEE 6	JSR 315, Ajax 대응 비동기 지원, 어노테이션에 의한 개발편의성, web.xml 없는 개발 및 배포
Servlet 2.5	2005년 9월	JavaEE 5 , J2SE 5.0	JSR 154, Requires J2SE 5.0, supports annotations
Servlet 2.4	2003년 11월	J2EE 1.4, J2SE 1.3	JSR 154, web.xml uses XML Schema
Servlet 2.3	2001년 8월	J2EE 1.3, J2SE 1.2	Addition of Filters
Servlet 2.2	1999년 8월	J2EE 1.2, J2SE 1.2	Becomes part of J2EE, introduced independent web applications in .war files
Servlet 2.1	1998년 11월	Unspecified	First official specification, added RequestDispatcher, ServletContext
Servlet 2.0		JDK 1.1	Part of Java Servlet Development Kit 2.0
Servlet 1.0	1997년 6월

[편집]아파치 톰캣 호환정보

• (영어) Apache Tomcat
• (영어) Tomcat is a free, open-source implementation of Java Servlet and JavaServer Pages technologies developed under the Jakarta project at the Apache Software Foundation. Sun adapts and integrates the Tomcat code base into the J2EE Reference Implementation. Tomcat is available for commercial use under the ASF license from the Apache web site in both binary and source versions.
• 4.X Release Build : Tomcat 4 is an implementation of the Java Servlet 2.3 specification.
• 3.3 Release Build : Tomcat 3.3 is an implementation of the Java Servlet 2.2 specification.
• (영어) Tomcat is available at the Jakarta binary downloads page.
• Tomcat 3 supports the Servlet 2.2 and JSP 1.1 specifications with minimum Java Version 1.1.
• Tomcat 4 supports the Servlet 2.3 and JSP 1.2 specifications with minimum Java Version 1.3.
• Tomcat 5 supports the Servlet 2.4 and JSP 2.0 specifications with minimum Java Version 1.4.
• Tomcat 6 supports the Servlet 2.5 and JSP 2.1 specifications with minimum Java Version 1.5.
• Tomcat 7 supports the Servlet 3.0 and JSP 2.2 specifications with minimum Java Version 1.6.

[편집]바깥 고리

• (영어) 자바 서블릿 다운로드 페이지
• (영어) JSR-000154 JavaTM Servlet 2.5 Specification

---

Java Servlet (자바 서블릿)는 서버 에서 웹 페이지 등을 동적으로 생성하고 데이터 처리를 위해, Java 로 작성된 프로그램 및 그 사양이다. 단순히 서블릿라는 것이 많다. Java EE의 한 기능이라고하는 위치 설정이되어있다. 이 기능을 이용하여 쇼핑 사이트와 온라인 뱅킹 등을 비롯한 다양한 동적 Web 사이트가 구축되어있다.

최신 사양은 Servlet3.0 (JSR-315)이다.

목차   [ 숨기기 ]  1 개요 2 서버 사이드 Java 3 역할 4 역사 5 Web.xml 정의 6 항목 7 외부 링크

개요 [ 편집 ]

Java Servlet은 서버 사이드 기술로 등장했다.

비슷한 기술 (즉 대항 기술 ^{[ 요청 출처 ]} )로 Perl 등을 이용한 CGI , PHP 프로그램의 프로세스를 Apache HTTP Server 에서 달릴 수있다 mod_php 등의 모듈, 마이크로 소프트 가 제공하는 ASP 등이있다. CGI가 클라이언트 의 요청마다 새로운 프로세스 를 시작하는 반면, 서블릿은 메모리 에 상주하여 요청마다 프로세스보다 가벼운 스레드 를 시작하기 때문에 효율이 좋다. 또한, 서블릿은 Java로 작성된 있기 때문에 다양한 플랫폼에서 사용할 수있다.

Servlet2.3에서 필터 기능이 추가되어, Servlet의 실행 전후에 처리를 さしはさむ 수있게되었다.

서블릿 기술의 연장으로 JSP 가 있지만, JSP는 서블릿을 자동 생성 해 실행하고있다. 엄밀히 말하면 서블릿과 JSP는 다른 기술이지만, 이들은 함께 사용하는 것이 일반적이기 때문에, JSP도 서블릿의 일부로 취급되는 경우가 많다.

서블릿 실행 환경 (실행하기위한 소프트웨어)는 Web 컨테이너 또는 서블릿 컨테이너라는. 이 말은별로 구별되지 않고 사용되는 경우도 많지만, 순수하게 서블릿의 처리를 실시하는 것을 서블릿 컨테이너라고 서블릿 컨테이너를 포함 JSP 나 HTTP 서버 로서의 기능도 포함되어 있기 때문에 Web 컨테이너 라고 부른다 경향 가있다.

Web 컨테이너 로는 Apache Tomcat , Jetty , BEA WebLogic Server , IBM WebSphere Application Server , Resin , JBoss 등이있다.

서버 사이드 Java [ 편집 ]

당초 Java는 Applet 등의 클라이언트 Java 프로그램을 가동시키는 클라이언트 측 기술로 주목을 받고 있었다. 그러나 서블릿의 등장 이후, 서버 측에서 Java 프로그램을 실행시키는 형태가 급속히 보급했다. 이러한 서버 측에서 Java 프로그램을 실행시키는 형태를 서버 사이드 Java라고 부른다.

역할 [ 편집 ]

JSP의 등장은 Java Servlet은 데이터의 입출력 처리 (Controller)를 담당하는 것이 권장된다. 이것은 Model View Controller (MVC)의 역할 지정이다.

역사 [ 편집 ]

Servlet의 역사

버전	출시	플랫폼	내용
1.0	1997 / 01	-	-
2.0		JDK 1.1	Java Servlet Development Kit 2.0의 일부로 출시
2.1	1998 / 11	-	공식 초판, RequestDispatcher, ServletContext를 추가
2.2	1999 / 08	J2EE 1.2, J2SE 1.2	J2EE의 일부가 될
2.3	2001 / 08	J2EE 1.3, J2SE 1.2	Filter 기능 추가
2.4	2003 / 11	J2EE 1.2, J2SE 1.2	web.xml에 XML Schema를 이용
2.5	2005 / 09	JavaEE 5, JavaSE 5	JavaSE 5 필수적인, annotation을 지원
3.0	2009 / 12	JavaEE 6, JavaSE 6	동적 인 구성 login / logout 메소드 지원 비동기 Servlet, 주석 Security, File 업로드

Web.xml 정의 [ 편집 ]

Web.xml 정의

버전	정의 내용
2.3	<? xml version = "1.0"encoding = "UTF-8"?> <! DOCTYPE web-app PUBLIC "- / / Sun Microsystems, Inc. / / DTD Web Application 2.3 / / EN" " http://java.sun.com/dtd/web-app_2_3.dtd "> <web-app> </ web-app>
2.4	<? xml version = "1.0"encoding = "UTF-8"?> <web-app xmlns = " http://java.sun.com/xml/ns/j2ee "xmlns : xsi =" http://www.w3.org/2001/XMLSchema-instance "xsi : schemaLocation =" http :/ / java.sun.com/xml/ns/j2ee/web-app_2_4.xsd "version ="2.4 "> </ web-app>

관련 항목 [ 편집 ]

위키 책에 Java 관련 해설서와 교과서가 있습니다.

• Java Platform, Enterprise Edition
• 응용 프로그램 서버
• 웹 응용 프로그램
• JavaServer Pages
• JavaBeans
• 애플릿

외부 링크 [ 편집 ]

• Servlet2.3 JSR-053
• Servlet2.4 JSR-154 Final Release
• Servlet2.5 JSR-154 Maintenance Release
• Servlet3.0 JSR-315

[ 숨기기 ] 표 · 화 · 편 · 력 Java Java 플랫폼 프로그래밍 언어 Java  · Java 가상 머신  · Java 플랫폼 에디션 Micro Edition  · Standard Edition  · Enterprise Edition 구성 프로 화ィ루 CLDC  · MIDP  · DoJa  · Java 카드 실행 환경 Java 개발 키트  · Java 실행 환경  · IKVM.NET 플랫폼 기술 애플릿  · Java Web Start  · 서블릿  · JSP  · AWT  · Swing  · JavaFX Enterprise Edition Enterprise JavaBeans  · Java Message Service  · JavaServer Faces 주요 타사 기술 JRockit  · GNU Classpath  · Kaffe  · Apache Harmony  · Apache Struts  · Spring framework  · Hibernate  · JBoss  · Tapestry VM상에서 움직이는 프로그래밍 언어 Ceylon  · Clojure  · Fortress  · Groovy  · JRuby  · Jython  · Kotlin  · Processing  · Rhino  · Scala Java 컨퍼런스 JavaOne 기타 Java에 대한 비판  · Java Community Process  · 썬 마이크로 시스템즈  · 오라클

---

A Java servlet is a Java program that extends the capabilities of a server. Although servlets can respond to any types of requests, they most commonly implement applications hosted on Web servers.^[1] Such Web servlets are the Java counterpart to other dynamic Web content technologies such as PHP and ASP.NET.

Contents

  [hide] 

• 1Introduction
• 2History
• 3Compared with other web application models
• 4Life cycle of a servlet
• 5Example
• 6Container servers
• 7References
• 8External links

Introduction[edit source]

Servlets are most often used to process or store a Java class in Java EE that conforms to the Java Servlet API,^[2] a standard for implementing Java classes that respond to requests. Servlets could in principle communicate over any client–server protocol, but they are most often used with the HTTP protocol. Thus "servlet" is often used as shorthand for "HTTP servlet".^[3] Thus, a software developer may use a servlet to add dynamic content to a web server using the Java platform. The generated content is commonly HTML, but may be other data such as XML. Servlets can maintain state in session variables across many server transactions by using HTTP cookies, or URL rewriting.

To deploy and run a servlet, a web container must be used. A web container (also known as a servlet container) is essentially the component of a web server that interacts with the servlets. The web container is responsible for managing the lifecycle of servlets, mapping a URL to a particular servlet and ensuring that the URL requester has the correct access rights.

The Servlet API, contained in the Java package hierarchy javax.servlet, defines the expected interactions of the web container and a servlet.^[3]

A Servlet is an object that receives a request and generates a response based on that request. The basic Servlet package defines Java objects to represent servlet requests and responses, as well as objects to reflect the servlet's configuration parameters and execution environment. The package javax.servlet.http defines HTTP-specific subclasses of the generic servlet elements, including session management objects that track multiple requests and responses between the web server and a client. Servlets may be packaged in a WAR file as a web application.

Servlets can be generated automatically from Java Server Pages (JSP) by the JavaServer Pages compiler. The difference between servlets and JSP is that servlets typically embed HTML inside Java code, while JSPs embed Java code in HTML. While the direct usage of servlets to generate HTML (as shown in the example below) has become rare, the higher level MVC web framework in Java EE (JSF) still explicitly uses the servlet technology for the low level request/response handling via the FacesServlet. A somewhat older usage is to use servlets in conjunction with JSPs in a pattern called "Model 2", which is a flavor of the model–view–controller.

The current version of Servlet is 3.1.

History[edit source]

The Servlet1 specification was created by Pavni Diwanji^[4] while she worked at Sun Microsystems, with version 1.0 finalized in June 1997. Starting with version 2.3, the specification was developed under the Java Community Process. JSR 53 defined both the Servlet 2.3 and JavaServer Page 1.2 specifications. JSR 154 specifies the Servlet 2.4 and 2.5 specifications. As of June 9, 2015, the current version of the Servlet specification is 3.1.

In his blog on java.net, Sun veteran and GlassFish lead Jim Driscoll details the history of servlet technology.^[5] James Gosling first thought of servlets in the early days of Java, but the concept did not become a product until Sun shipped the Java Web Server^[clarify] product. This was before what is now the Java Platform, Enterprise Edition was made into a specification.

Servlet API history

Servlet API version	Released	Platform	Important Changes
Servlet 4.0	Under development	Java EE 8	HTTP/2
Servlet 3.1	May 2013	Java EE 7	Non-blocking I/O, HTTP protocol upgrade mechanism (WebSocket)[6]
Servlet 3.0	December 2009	Java EE 6, Java SE 6	Pluggability, Ease of development, Async Servlet, Security, File Uploading
Servlet 2.5	September 2005	Java EE 5, Java SE 5	Requires Java SE 5, supports annotation
Servlet 2.4	November 2003	J2EE 1.4, J2SE 1.3	web.xml uses XML Schema
Servlet 2.3	August 2001	J2EE 1.3, J2SE 1.2	Addition of Filter
Servlet 2.2	August 1999	J2EE 1.2, J2SE 1.2	Becomes part of J2EE, introduced independent web applications in .war files
Servlet 2.1	November 1998	Unspecified	First official specification, added RequestDispatcher, ServletContext
Servlet 2.0		JDK 1.1	Part of Java Servlet Development Kit 2.0
Servlet 1.0	June 1997

Compared with other web application models[edit source]

This section relies largely or entirely upon a single source. Relevant discussion may be found on the talk page. Please help improve this article by introducing citations to additional sources. (December 2013)

The advantages of using servlets are their fast performance and ease of use combined with more power over traditional CGI (Common Gateway Interface). Traditional CGI scripts written in Java have a number of performance disadvantages:

• When an HTTP request is made, a new process is created each time the CGI script is called. The overhead associated with process creation can dominate the workload especially when the script does relatively fast operations. Thus, process creation will take more time for CGI script execution. In contrast, for servlets, each request is handled by a separate Java thread within the web server process, thereby avoiding the overhead associated with forking processes within the HTTP daemon.
• Simultaneous CGI requests will load the CGI script to be copied into memory once per request. With servlets, there is only one copy that persists across requests and is shared between threads.
• Only a single instance answers all requests concurrently. This reduces memory usage and eases the management of persistent data.
• A servlet can be run by a servlet container in a restrictive environment, called a sandbox. This is similar to an applet that runs in the sandbox of the web browser. This enables restricted use of potentially harmful servlets.^[3] CGI programs can of course also sandbox themselves, since they are simply OS processes.

Technologies like FastCGI and its derivatives (including SCGI, AJP) do not exhibit the performance disadvantages of CGI, incurred by the constant process spawning. They are, however, roughly as simple as CGI. They are therefore also in contrast with servlets which are substantially more complex.

Life cycle of a servlet[edit source]

Three methods are central to the life cycle of a servlet. These are init(), service(), and destroy(). They are implemented by every servlet and are invoked at specific times by the server.

• During initialization stage of the servlet life cycle, the web container initializes the servlet instance by calling the init() method, passing an object implementing the javax.servlet.ServletConfig interface. This configuration object allows the servlet to access name-value initialization parameters from the web application.
• After initialization, the servlet instance can service client requests. Each request is serviced in its own separate thread. The web container calls the service() method of the servlet for every request. The service() method determines the kind of request being made and dispatches it to an appropriate method to handle the request. The developer of the servlet must provide an implementation for these methods. If a request is made for a method that is not implemented by the servlet, the method of the parent class is called, typically resulting in an error being returned to the requester.
• Finally, the web container calls the destroy() method that takes the servlet out of service. The destroy() method, like init(), is called only once in the lifecycle of a servlet.

The following is a typical user scenario of these methods.

1. Assume that a user requests to visit a URL.
   • The browser then generates an HTTP request for this URL.
   • This request is then sent to the appropriate server.
2. The HTTP request is received by the web server and forwarded to the servlet container.
   • The container maps this request to a particular servlet.
   • The servlet is dynamically retrieved and loaded into the address space of the container.
3. The container invokes the init() method of the servlet.
   • This method is invoked only when the servlet is first loaded into memory.
   • It is possible to pass initialization parameters to the servlet so that it may configure itself.
4. The container invokes the service() method of the servlet.
   • This method is called to process the HTTP request.
   • The servlet may read data that has been provided in the HTTP request.
   • The servlet may also formulate an HTTP response for the client.
5. The servlet remains in the container's address space and is available to process any other HTTP requests received from clients.
   • The service() method is called for each HTTP request.
6. The container may, at some point, decide to unload the servlet from its memory.
   • The algorithms by which this decision is made are specific to each container.
7. The container calls the servlet's destroy() method to relinquish any resources such as file handles that are allocated for the servlet; important data may be saved to a persistent store.
8. The memory allocated for the servlet and its objects can then be garbage collected.

Example[edit source]

The following example servlet prints how many times its service() method was called.

Note that HttpServlet is a subclass of GenericServlet, an implementation of the Servlet interface.

The service() method of HttpServlet class dispatches requests to the methods doGet(), doPost(), doPut(), doDelete(), and so on; according to the HTTP request. In the example below service() is overridden and does not distinguish which HTTP request method it serves.

import java.io.IOException;
 
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class ServletLifeCycleExample extends HttpServlet {
 
    private int count;
 
    @Override
    public void init(ServletConfig config) throws ServletException {
        super.init(config);
        getServletContext().log("init() called");
        count = 0;
    }
 
    @Override
    protected void service(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        getServletContext().log("service() called");
        count++;
        response.getWriter().write("Incrementing the count: count = " + count);
    }
 
    @Override
    public void destroy() {
        getServletContext().log("destroy() called");
    }

}

Container servers[edit source]

The specification for Servlet technology has been implemented in many products. See a list of implementations on the Web container page.

source - https://en.wikipedia.org/wiki/Java_servlet

---

JSP Model 2 is a complex design pattern used in the design of Java Web applications which separates the display of content from the logic used to obtain and manipulate the content. Since Model 2 drives a separation between logic and display, it is usually associated with the model–view–controller (MVC) paradigm. While the exact form of the MVC "Model" was never specified by the Model 2 design, a number of publications recommend a formalized layer to contain MVC Model code. The Java BluePrints, for example, originally recommended using EJBs to encapsulate the MVC Model.

In a Model 2 application, requests from the client browser are passed to the controller. The controller performs any logic necessary to obtain the correct content for display. It then places the content in the request (commonly in the form of a JavaBean or POJO) and decides which view it will pass the request to. The view then renders the content passed by the controller.

A simplified diagram of the Model 2 pattern.

Model 2 is recommended for medium- and large-sized applications.

Contents

  [hide] 

• 1History
• 2Misconceptions
• 3See also
• 4References
• 5External links

History[edit source]

In 1998, Sun Microsystems published a pre-release of the JavaServer Pages specification, version 0.92.^[1] In this specification, Sun laid out two methods by which JSP pages could be used. The first model (referred to as "model 1" due to its ordering in the document) was a simplistic model whereby JSP pages were standalone, disjointed entities. Logic could be contained within the page itself, and navigation between pages was typically achieved by way of hyperlinks. This fit with the then-common usage of template technology.

ColdFusion and Active Server Pages are examples of contemporary technologies that also implemented this model.

The second model referred to by the document ("model 2" in the ordering) was an improved method that combined servlet technology with JSP technology. The specific difference listed was that a servlet would intercept the request, place the content to render into a request attribute (typically represented by a JavaBean), then call a JSP to render the content in the desired output format. This model differed from the previous model in the fact that JSP technology was used as a pure template engine. All of the logic was separated out into a servlet, leaving the JSP with the sole responsibility of rendering the output for the content provided.

In December 1999, JavaWorld published an article by Govind Seshadri entitled Understanding JavaServer Pages Model 2 architecture.^[2] In this article, Govind accomplished two major milestones in the use of the term "Model 2". The first milestone was to formalize the term "Model 2" as an architectural pattern rather than one of two possible options. The second milestone was the claim that Model 2 provided an MVC architecture for web-based software.^[3]

Govind believed that because "Model 2" architecture separated the logic out of the JSP and placed it in a servlet, the two pieces could be seen as the "View" and the "Controller" (respectively) in an MVC architecture. The "Model" part of the MVC architecture was left open by Govind, with a suggestion that nearly any data-structure could meet the requirements. The specific example used in the article was a Vector list stored in the user's session.

In March 2000, the Apache Struts project was released. This project formalized the division between View and Controller and claimed implementation of the "Model 2" pattern.^[3] Once again, the implementation of the "Model" was left undefined with the expectation that software developers would fill in an appropriate solution. Database interaction via JDBC and EJBs were options suggested on the Struts homepage. More recently, Hibernate, iBatis, and Object Relational Bridge were listed as more modern options that could be used for a model.^[4]

Since the release of Struts, a number of competing frameworks have appeared. Many of these frameworks also claim to implement "Model 2" and "MVC". In result, the two terms have become synonymous in the minds of developers. This has led to the use of the term "MVC Model 2" or "MVC2" for short.

Misconceptions[edit source]

A common misconception is that a formalized MVC pattern is required to achieve a Model 2 implementation. However, the Java BluePrints specifically warn against this interpretation:^[5]

The literature on Web-tier technology in the J2EE platform frequently uses the terms "Model 1" and "Model 2" without explanation. This terminology stems from early drafts of the JSP specification, which described two basic usage patterns for JSP pages. While the terms have disappeared from the specification document, they remain in common use. Model 1 and Model 2 simply refer to the absence or presence (respectively) of a controller servlet that dispatches requests from the client tier and selects views.

Furthermore, the term "MVC2" has led many to a mistaken belief that Model 2 represents a next-generation MVC pattern. In fact, MVC2 is simply a shortening of the term "MVC Model 2".^[6]

The confusion over the term "MVC2" has led to additional confusion over Model 1 code, resulting in common usage of the nonexistent term "MVC1".

See also[edit source]

• Apache Struts is an open-source framework for implementing web-applications based on a Model 2 architecture.

References[edit source]

1. Jump up^ JSP 0.92 Specification
2. Jump up^ Understanding JavaServer Pages Model 2 architecture by Govind Seshadri (JavaWorld)
3. ^ Jump up to:^a b How Struts Implements Model 2 (The Origins of Model 1/Model 2)
4. Jump up^ Struts 1.x Homepage
5. Jump up^ Java BluePrints 4.4.1: Structuring the Web Tier
6. Jump up^ Struts, an open-source MVC implementation

External links[edit source]

• Understanding JavaServer Pages Model 2 architecture by Govind Seshadri (JavaWorld)
• A History of MVC, Including Model 2
• ASP.NET Presentation Patterns - In this article Dino Esposito discusses how Model2 is also used in ASP.NET MVC.

source - https://en.wikipedia.org/wiki/JSP_model_2_architecture

---

javax.servlet

Interface Servlet

• All Known Implementing Classes:

  GenericServlet, HttpServlet

  ---

  
  

  public interface Servlet

  Defines methods that all servlets must implement.

  A servlet is a small Java program that runs within a Web server. Servlets receive and respond to requests from Web clients, usually across HTTP, the HyperText Transfer Protocol.

  To implement this interface, you can write a generic servlet that extends javax.servlet.GenericServlet or an HTTP servlet that extends javax.servlet.http.HttpServlet.

  This interface defines methods to initialize a servlet, to service requests, and to remove a servlet from the server. These are known as life-cycle methods and are called in the following sequence:

  1. The servlet is constructed, then initialized with the init method.
  2. Any calls from clients to the service method are handled.
  3. The servlet is taken out of service, then destroyed with the destroy method, then garbage collected and finalized.

  In addition to the life-cycle methods, this interface provides the getServletConfig method, which the servlet can use to get any startup information, and the getServletInfo method, which allows the servlet to return basic information about itself, such as author, version, and copyright.

source - https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/Servlet.html

---

javax.servlet

Class GenericServlet

• java.lang.Object
• • javax.servlet.GenericServlet

• All Implemented Interfaces:

  java.io.Serializable, Servlet, ServletConfig

  Direct Known Subclasses:

  HttpServlet

  ---

  
  

  public abstract class GenericServlet
  extends java.lang.Object
  implements Servlet, ServletConfig, java.io.Serializable

  Defines a generic, protocol-independent servlet. To write an HTTP servlet for use on the Web, extend HttpServlet instead.

  GenericServlet implements the Servlet and ServletConfig interfaces. GenericServlet may be directly extended by a servlet, although it's more common to extend a protocol-specific subclass such as HttpServlet.

  GenericServlet makes writing servlets easier. It provides simple versions of the lifecycle methods init and destroy and of the methods in the ServletConfig interface. GenericServlet also implements the log method, declared in the ServletContext interface.

  To write a generic servlet, you need only override the abstract service method.

source - https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/GenericServlet.html

---

javax.servlet.http

Class HttpServlet

• java.lang.Object
• • javax.servlet.GenericServlet
  • • javax.servlet.http.HttpServlet

• All Implemented Interfaces:

  java.io.Serializable, Servlet, ServletConfig

  ---

  
  

  public abstract class HttpServlet
  extends GenericServlet

  Provides an abstract class to be subclassed to create an HTTP servlet suitable for a Web site. A subclass of HttpServlet must override at least one method, usually one of these:

  • doGet, if the servlet supports HTTP GET requests
  • doPost, for HTTP POST requests
  • doPut, for HTTP PUT requests
  • doDelete, for HTTP DELETE requests
  • init and destroy, to manage resources that are held for the life of the servlet
  • getServletInfo, which the servlet uses to provide information about itself

  There's almost no reason to override the service method. service handles standard HTTP requests by dispatching them to the handler methods for each HTTP request type (the doMethod methods listed above).

  Likewise, there's almost no reason to override the doOptions and doTrace methods.

  Servlets typically run on multithreaded servers, so be aware that a servlet must handle concurrent requests and be careful to synchronize access to shared resources. Shared resources include in-memory data such as instance or class variables and external objects such as files, database connections, and network connections. See the Java Tutorial on Multithreaded Programming for more information on handling multiple threads in a Java program.

source - https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/http/HttpServlet.html

---

Framework 의 늪

웹 기술을 공부하지 않았던 나에게 항상 JSP, PHP, ASP 이런 것들은 탐험 가능하지만 재미없을 것 같은 그런 곳 ㅠ 그러다 올해 8월부터 갑자기 1년 반동안 하지 않던 코딩을 다시 시작하고 웹 기술을 공부하면서, Java를 다시 손에 쥐니 눈앞에 있는게 JSP 

다들 아시겠지만 JSP 를 공부하다 보면 항상 처음에 마주치는 관문이 있습니다. Servlet 은 무엇인가, JSP랑 뭐가 다르지? 어? 인터넷 뒤져보면 같이 쓴다는데, Servlet 만으로도 페이지를 만들고, JSP 만으로도 되네. 응? 근데 Model 1은 뭐고 Model 2 는 무엇이지? MVC? Spring이 좋다던데 이건 또 뭐냐. 

이렇게 제대로 공부하지도 못하고 끝 없이 이어져 나오는 프레임워크의 늪에 빠져 방황하다가 다시 정신차리고 보니 눈앞엔 JSP가 있었습니다... 

Back to the basics

그래서 다시 기본부터 시작하기로 했습니다. JSP는 무엇이고, Servlet 은 무엇인가? 

Servlet

servlet은 톰캣 위에서 동작하는 java 프로그램입니다. 더 정확히 말하자면 servlet 이 초기화 되는 과정을 보면 됩니다. 여기 에 의하면, 서블릿 초기화는 다음과 같은 과정을 거칩니다. 

 


톰캣과 같은 WAS 가 java 파일을 컴파일해서 Class로 만들고 메모리에 올려 Servlet 객체를 만들게 되고 이 Servlet 객체는 doPost, doGet을 통해 요청에 응답합니다. 초기화 과정을 더 자세히 보면 

 

init, Service, destory 이런 콜백이 각 시점에 불리는걸 볼 수 있지요. init은 서블릿이 메모리에 로드 될때 실행됩니다. destory는 마찬가지로 언로드되기 전에 수행되는 콜백이구요. service 메소드는 HTTP Method 타입에 따라 doGet 혹은 doPost를 호출합니다. 

기억해야 할 점은, 초기화된 서블릿이 클라이언트의 요청이 있을 때 마다 Thread를 생성해서 병렬적으로 service를 수행한다는 것. 서블릿 객체는 여러개 생성되지 않습니다. 생명주기 까지 길게 왔는데, 요약하면 

WAS 를 통해 컴파일 된 후 메모리에 적재되어 클라이언트의 HTTP Get, Post 등의요청을 처리하는 자바 프로그램임.

Servlet 샘플 코드를 보시면 알겠지만, HTML 을 넣기 굉장히 불편합니다. 

public class HelloServlet extends HttpServlet {

	public void doGet(HttpServletRequest req,HttpServletResponse res)

			throws ServletException,IOException {

    

		res.setContentType("text/html;charset=UTF-8");

		PrintWriter out = res.getWriter();

		

		out.println("<HTML>");

		out.println("<BODY>");

		out.println("Hello World!!");

		out.println("</BODY>");

		out.println("</HTML>");

		out.close();

	}

}

JSP

그래서 JSP가 나왔답니다. HTML을 코딩하기 너무 불편해서, HTML 내부에 Java 코드를 삽입하는 형식의 JSP!! 샘플 코드를 보시겠습니다. 여기서 펌 

<%@page import="java.util.Calendar" %>
<%@ page contentType="text/html; charset=UTF-8"%>
<%
 String str=String.format("%tF",Calendar.getInstance());
%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Insert title here</title>
</head>
<body>
오늘은 <%=str%><br/>
한시간만 참으면 점심....
</body>
</html>

보시면 알겠지만, HTML 내부에 Java 코드가 있어 HTML 코드를 작성하기 쉽습니다. 단, 로직과 디자인이 한 파일내에 섞여있어 유지보수가 어렵답니다. 클래스 단위로 분해해서 OOP적으로 코드를 짜기도 어렵구. 하나가 편한대신, 다른 불편한 점들이 온 것이지요. 

JSP 라는 새로운 개발 방법이 나왔지만, 사실 이 JSP 도 내부적으로는 Tomcat 이 Servlet 으로 바꾸어서 돌립니다. 그림을 보시지요. 

 


결국엔 java 클래스 파일로 변환되어 메모리 상에 적재되지만, 개발자들이 HTML 부분을 편하게 코딩할 수 있게 만든건가봐요. 그리고 사람들이 이런 JSP를 이용해서 코딩을 하다보니 다음과 같이 하게 되더랍니다. 

Model 1

여기 에 의하면, 사용자로부터 요청을 JSP가 받아(더 정확히는 JSP 에서 사용자가 요청을 합니다.) Java Bean(DTO, DAO)을 호출해 처리합니다. 이런 방식을 Model1 이라고 한답니다. 

- 개발 속도가 빠르고 
- 배우기 쉽지만 
- 프레젠테이션 로직과 비즈니스 로직이 혼재 
- JSP 코드가 복잡해져 유지 보수가 어려워집니다.

Model 2

 

단순히 JSP 만 사용하거나, Servlet만 사용하는 것이 아니라 두개의 장단점을 모두 취해 View 는 JSP로, Controller 는 Servlet 을 사용한 것이 바로 Model2 지요. 보여지는 부분은 HTML이 중심이 되는 JSP, 다른 자바 클래스에게 데이터를 넘겨주는 부분은 Java 코드가 중심이 되는 Servlet 이 담당하게 됩니다. 그리고 Model 영역 에서는 DTO, DAO를 통해 Mysql 과 같은 Data Storage 에 접근합니다. 

익스프레션, 스크립틀릿 등 탐구할 영역이 많이 남았지만, 그것 이외에 공부하면서 얻을 수 있는 부분이 다른 Backend 와는 조금 다를 것 같다는 생각이 들어요. 

Java 웹 서비스 진영의 디자인패턴이나 OOP적 노하우가 축적되면서 Spring 나왔고, 이것이 의미하는 바는 제가 '경험적'인 부분을 배울게 많다는 뜻이겠지요 ^^; 다른 Backend-language 보다 더요. 가장 잘나가니까. 

출처: http://anster.tistory.com/128 [Old Lisper]