1편에서 태초의 웹이 탄생한 배경과 태초의 웹이 가진 한계에 대해서 설명하였습니다. 그리고 이를 극복하기 위해 CGI가 등장하였습니다. 그러나 CGI 또한 단점이 있었기에 이를 보완하고 java로 웹을 구동하는 서블릿이 등장한 것까지 설명하였습니다.
2편에서는 서블릿과 항상 함께 등장하는 JSP(Java Server Page)부터 알아보겠습니다.
JSP는 서블릿(Servlet)의 단점을 보완한 결과물이지만 결과적으로 하는일은 동일합니다. 왜냐하면 JSP로 작성된 프로그램은 서버로 요청시 서블릿 파일로 변환되어 결국 서블릿이 하는 일을 똑같이 하기 때문입니다.
그래서 같은 동작을 하는데도 과정이 하나 더 추가된 JSP를 사용하는 것은 비합리적으로 보이기도 합니다. 하지만, JSP의 목적은 바로 개발자(사람)가 코딩을 하기 더 쉽도록 하는데 있습니다.
1편에서 설명했던 서블릿(Servlet)은 자바코드 안에 HTML 코드가 들어가있었습니다.
@WebServlet("/loginServlet")
public class LoginServlet extends HttpServlet {
protected void doPost(HttpServletRequest request,HttpServletResponse response) throws ServletException, IOException {
// HTML 코드 작성
String htmlRespone = "<html>";
htmlRespone += "<h2>Your username is: " + username + "<br/>";
htmlRespone += "Your password is: " + password + "</h2>";
htmlRespone += "</html>";
// return response
writer.println(htmlRespone);
}
}
보시다시피 HTML 코드 작성을 String 을 더해가면서 전부 해야해야 했고 이는 매우 비효율적이었습니다.
그래서 자바코드 안에 HTML을 넣는게 힘들면, HTML 코드 안에 자바코드를 넣자는 생각으로 JSP가 등장하였습니다.
따라서 JSP의 정의는 HTML 소스코드 속에 자바 소스코드가 들어가는 구조를 갖는 웹어플리케이션 프로그래밍 기술입니다. HTML속에서 자바코드는 <% 자바코드 %> 또는 <%= 자바코드 =%>형태로 들어갑니다. 자바 소스코드로 작성된 이 부분은 html 처럼 바로 웹 브라우저로 보내는 것이아니라 웹 서버에서 실행이 됩니다.
서블릿의 동작과정을 알고있다면 JSP의 동작 방식을 이해하는 것은 쉽습니다.
📢 Jsp의 요소
JSP는 다양한 태그와 스크립트 요소를 통해 자바 코드를 포함할 수 있습니다.
- 스크립트 요소: 자바 코드를 직접 JSP에 작성하여 서버에서 실행할 수 있는 코드입니다.
- <% 자바 코드 %>: JSP 페이지 내에서 자바 코드를 실행합니다.
- <%= 표현식 %>: 값을 계산하여 클라이언트에 출력합니다.
- <%! 선언 %>: 클래스 수준에서 변수를 선언하거나 메서드를 정의합니다.
- 표준 태그 라이브러리 (JSTL): JSP는 자바 코드의 사용을 줄이고 표준화된 태그를 통해 데이터를 처리하는 데 집중할 수 있도록 JSTL을 제공합니다. 예를 들어, forEach, if 태그 등을 사용해 조건문이나 반복문을 처리할 수 있습니다.
- 디렉티브: JSP 페이지의 전역 설정을 지정하는 태그로, 주로 페이지의 메타데이터나 서블릿과의 연동을 설정하는 데 사용됩니다.
- %@ page ... %>: 페이지의 속성을 설정합니다. 예를 들어, import로 자바 클래스를 불러올 수 있습니다.
- <%@ include ... %>: 다른 JSP 파일이나 HTML 파일을 현재 페이지에 포함시킬 수 있습니다.
- JSP 액션 태그: JSP에서 자주 사용되는 작업을 쉽게 수행할 수 있는 태그입니다.
- <jsp:include>: 다른 JSP 파일을 포함합니다.
- <jsp:forward>: 다른 페이지로 요청을 전달합니다.
- <jsp:param>: 파라미터를 전달할 때 사용합니다.
JSP가 요청을 처리하는 과정은 클라이언트 요청 -> JSP 컴파일 -> HTTP 응답으로 나뉩니다
jsp를 통해 html을 중심으로 java코드를 통합하여 편리하게 동적 웹 페이지를 만들 수 있었습니다. 그러나 여전히 html과 같이 작성되었으므로 java 코드가 많이 들어가게 되면 가독성이 떨어지고 유지보수가 어렵다는 한계가 있었습니다.
초창기에 자바 진영의 서블릿, JSP는 성능이 구렸습니다. 초창기 자바의 데이터베이스 연결에 대한 기반 기술인 JDBC의 성능은 좋지 않기로 악명이 높았습니다.
또한, 당시 JVM의 성능 또한 너무 안좋았습니다. 버전이 올라가면서 조금씩 나아지긴 했지만 그래도 나머지 두 기술(PHP, ASP)에 비하면 별로였습니다.
그런데 역설적으로 좋지 않는 DB접속 성능 때문에 자바는 새로운 기회를 잡게 됩니다. PHP나ASP가 하는 방식으로는 이길 수 없었던 자바 진영의 사용자들은 Connection Pool 이란 개념을 도입하였습니다.
DB연결은 상당히 비싼(High Cost) 작업입니다. 기존 프로그램에서는 필요할 때 연결하고 필요 없으면 끊는 식으로 사용했습니다. 여기서 자바는 일정한 숫자의 DB연결을 미리 해놓고 사용하면서 그 연결들을 다시 돌려쓰는 방식을 웹 프로그램의 기본 아키텍쳐로 도입합니다. 일정 숫자의 연결은 해제하지 않고 계속 사용하여웹 프로그램의 성능을 드라마틱하게 향상시킵니다.
이 시기를 기점으로 자바 진영은 프레임워크의 시초격인 J2EE 스펙을 발표합니다
J2EE는 자바로 기업 환경의 어플리케이션을 만드는데 필요한 스펙들을 모아둔 스펙 집합입니다. 썬 마이크로시스템즈(Sun Microsystems)사 에서 만들었고 스펙을 시범적으로 구현했습니다. 하지만 IBM, BEA, Oracle, HP, Iona등 여러 벤더들도 그 스펙을 구현할 수 있어서 사실상 SUN의 독점적인 기술이라기 보다는 Java 진영으로 불리는 여러 개발자들이 같이 만들어가고 공유하는 기술이라고 볼 수 있습니다
이 J2EE의 출시로 인해서 자바가 엔터프라이즈급, 즉 전사 레벨의 시스템을 구축할 수 있는 프로그래밍 언어가 되고자 하는 야욕을 드러냈다고 할 수 있습니다. 전사 레벨의 시스템을 구축할 수 있는 프로그래밍 언어란, 그냥 언어가 아니라 아주 다양하고 복잡한 요구사항을 소화할 수 있는 기술 스펙이라 할 수 있습니다.스프링(Spring) 프레임워크도 J2EE 애플리케이션 입니다.
J2EE는 웹과 서버 환경을 위한 API 및 서비스 세트를 통해 웹 애플리케이션, 분산 트랜잭션 관리, 멀티티어 아키텍처를 지원했습니다. 또한, 검증됐다면 누구나 기여하고 만들어갈 수 있는 특성때문에 J2EE는 매우 방대한 범위를 다루었습니다. 대표적인 구성은 다음과 같습니다.
J2EE의 다음 버전인 Java EE 5가 출시될 때 명칭이 J2EE에서 Java EE로 변경되었습니다. 이 명칭 변경은 2006년에 이루어졌고, Java EE 5에서는 이전보다 더 경량화된 API와 편리한 어노테이션 기반의 기능이 도입되었습니다.
특징
명칭 변경 이후
Java EE는 오라클에 의해 관리되다가 2017년 Eclipse 재단으로 넘어가면서 다시 Jakarta EE로 명칭이 변경되었습니다. Jakarta EE는 Java EE의 최신 버전으로, 더 빠르게 개선된 자바 엔터프라이즈 표준을 제공합니다.
자세히 보면 Jave EE에서는 EJB를 간소화하고 POJO기반으로 비즈니스 로직을 바꾸게 되었는데 이 이유는 EJB가 가진 비효율성 때문이었습니다. 다음 시간에는 EJB가 가진 비효율성과 이를 극복하는 과정에서 등장한 Spring에 대해서 설명하겠습니다.