Java EE는, 자바의 기본적인 기능을 정의한 Java SE에 웹 서버 역할을 추가한 것으로 자바 애플리케이션을 동작시킬 수 있는 컨테이너 등을 표준화한 스펙이다. Java EE 표준준수 웹 애플리케이션 서버는 Java EE 스펙을 수용하는 웹 애플리케이션 서버이다.

[편집]구성요소

Java EE 표준기반 웹 애플리케이션에서 동작하는 프로그램 언어는 자바이다. 일반적으로 웹 모듈은 자바 서블릿 또는 JSP(Java Server Page)로 구성하고, 비즈니스 모듈은 EJB(Enterprise Java Beans)로 구성한다.

자바 플랫폼, 엔터프라이즈 에디션(Java Platform, Enterprise Edition; Java EE)은 자바를 이용한 서버측 개발을 위한 플랫폼이다. Java EE 플랫폼은 PC에서 동작하는 표준 플랫폼인 Java SE에 부가하여, 웹 애플리케이션 서버에서 동작하는 장애복구 및 분산 멀티티어를 제공하는 자바 소프트웨어의 기능을 추가한 서버를 위한 플랫폼이다. 이전에는J2EE라 불리었으나 버전 5.0 이후로 Java EE로 개칭되었다.

이러한 Java EE 스펙에 따라 제품으로 구현한 것을 웹 애플리케이션 서버 또는 WAS라 불린다.

[편집]역사

 이 부분의 본문은 Java EE 버전의 역사입니다.

• 1999년 12월 : J2EE 1.2 SDK가 썬 마이크로시스템즈가 최초로 발표하였다.
• J2EE 1.3 스펙부터는 자바 커뮤니티 프로세스(Java Community Process;JCP)가 개발하였다.
• 2001년 6월 : J2EE 1.3 SDK의 베타버전이 발표되었다.
• 2002년 11월 : J2EE 1.4 SDK의 베타버전이 발표되었다.
• 2006년 5월 11일 : Java EE 5 스펙이 발표되었다. (J2EE에서 Java EE로 개칭)
• 2009년 12월 : Java EE 6 스펙이 발표되었다.

[편집]인증된 웹 애플리케이션 서버

[편집]Java EE 6 인증

(2010년 1월 5일 기준)

• 글래스피쉬 엔터프라이즈 서버 3, 썬 마이크로시스템즈사 제품
• 제우스 7, 오픈 소스인 글래스피쉬 기반의 티맥스소프트사 제품

[편집]Java EE 5 인증

• 썬 자바 애플리케이션 서버 9.0, 오픈 소스인 글래스피쉬 기반의 썬 마이크로시스템즈사 제품
• 제우스 6, 오픈 소스인 글래스피쉬 기반의 티맥스소프트사 제품
• 웹로직 10.0, 오라클에 인수된 BEA사 제품
• 넷위버, SAP사 제품
• 아파치 제르니모 2.0, 오픈 소스
• 웹스피어 애플리케이션 서버 커뮤니티 에디션 2.0, 오픈 소스인 아파치 제르니모 기반의 IBM사 제품
• OC4J 11, 오라클사 제품
• 글래스피쉬, 오픈 소스

[편집]같이 보기

• Java SE
• 웹 애플리케이션 서버

[편집]바깥고리

• Java Platform, Enterprise Edition (Java EE)
• Java EE 5 SDK
• Java EE 5 Technologies and JSRs
• Sun's J2EE compatibility page - Certified J2EE servers

Java Platform, Enterprise Edition ( Java EE )은 Java 의 기업용 기능 세트. Java Platform, Standard Edition (Java SE)의 확장 형태로 제공된다.

1998 년 에 발표 된, 주로 대형 시스템 (서버 용도) 용으로, Java Servlet (서블릿), JavaServer Pages (JSP), Enterprise JavaBeans (EJB), Java Naming and Directory Interface (JNDI), Java Transaction API (JTA ), Java Message Service (JMS), JavaMail, J2EE Connector Architecture (J2CA) 및 XML 관련 API (JAXP 등) 등의 기능을 세트로 제공하는 것. 다층 시스템 의 구축이 가능, EJB는 트랜잭션 관리 원격 연결 등의 자동화가있다.

덧붙여서 현재 버전은 Java Platform, Enterprise Edition 6 (Java EE 6)라고 명명되었으며, Java EE 5보다 이전 버전은 Java 2 Platform, Enterprise Edition (J2EE)라고 명명되었다.

Java EE 자체는 사양이기 때문에 회사가 허가 구현, 판매 등을하고있다.

역사 [ 편집 ]

첫 번째 J2EE 사양은 Sun Microsystems 가 개발하고 1999 년 12 월에 J2EE 1.2이 출시되었다. J2EE 1.3 사양 검토는 Java Community Process 하에서 이루어졌다. Java Specification Request (JSR) 58, J2EE 1.3, JSR 151는 J2EE 1.4 사양 정의이다.

J2EE 1.3은 2001 년 4 월에 베타 버전이 Sun에 의해 출시되었다.

J2EE 1.4는 2002 년 12 월에 베타 버전이 Sun에 의해 출시되었다.

JavaEE 5는 JSR 244으로 검토되고 2006 년 5 월 11 일에 발표되었다.

JavaEE 6는 JSR 316으로 검토되고 2009 년 12 월에 출시되었다.

Java EE 구현 [ 편집 ]

JDK (Java SDK) , Enterprise Edition Reference Implementation (RI) : 개발 등의 용도로 사용 레퍼런스 구현. 실제 운용에 사용할 수 없다.

또한 Java 개발 도구의 많은도 상위 버전에서 Java EE에 대응하고있다. 또한 Java EE를 사용하여 응용 프로그램 서버 목록에 관해서는 애플리케이션 서버 의 항을 참조.

주요 API [ 편집 ]

Java EE API는 Java SE API를 바탕으로 개선 된 다양한 기술을 포함하고있다.

javax.ejb . * [ 편집 ]

EJB1하면 EJB2는 지속성 기능을 제공하는 분산 객체 컨테이너, 원격 프로 시저 호출 ( RMI , RMI-IIOP) 동시성 및 액세스 제어를 정의했다.

이 패키지는 엔터프라이즈 빈과 클라이언트 엔터프라이즈 빈과 EJB 컨테이너의 각 사이의 결정을 정의한 클래스 와 인터페이스 를 포함한다.

javax.transaction . * [ 편집 ]

이 패키지는 JTA에 대해 정의한다.

javax.xml.stream [ 편집 ]

이 패키지는 XML의 읽기 및 쓰기 기능을 포함한다.

javax.jms . * [ 편집 ]

이 패키지는 JMS API를 정의하고있다. JMS API는 Java 프로그램에 엔터프라이즈 메시지 생성, 전송, 수신, 읽기 기능을 제공한다.

javax.faces.component.html [ 편집 ]

이 패키지는 JSF API를 정의하고있다. JSF는 컴포넌트의 UI 구축 기술이다.

javax.persistence [ 편집 ]

이 패키지는 지속성 공급자 관리 클래스와 JPA 클라이언트 사이의 결정을 정의하는 클래스와 인터페이스를 포함한다.

외부 링크 [ 편집 ]

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

• Java Platform, Enterprise Edition (Java EE)

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

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 객체는 가비지 컬렉션이 될 준비를 할 것이며, 이 객체에 대한 참조는 이제 범위를 벗어나기에 사라집니다.
   마지막으로 클라이언트는 서버로부터 응답을 받게 됩니다.

Servlet 인터페이스

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

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

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

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

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

[편집]버전의 역사

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

• (영어) 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)이다.

개요 [ 편집 ]

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)의 역할 지정이다.

역사 [ 편집 ]

Web.xml 정의 [ 편집 ]

관련 항목 [ 편집 ]

위키 책에 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.

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.

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.

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]

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

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

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

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]

Spring MVC Framework Tutorial

출처 - http://www.dzone.com/tutorials/java/spring/spring-mvc-tutorial-1.html