🚩 1.1 자바 웹 개발 환경 만들기

🏁 웹 프로젝트의 기본 구조

3 tier architecture

• 3 tier architecture
  docs.aws - 3 tier architecture

• ① Client(브라우저) : 일반 사용자가 화면을 조작하여 서버에 데이터를 요청(Request), 응답(response)

  • 관련 : HTML, CSS, 자바스크립트
  • Presentation Tier 라고도 한다.

• ② 웹 서버 혹은 WAS(Web Application Server) :
  
  ❶ 웹 서버(Web Server) : 이미지와 같은 고정된 데이터 제공 (웹 서버)
  ❷ WAS (Web Application Server) : 동적으로 비즈니스 로직을 처리해 매번 새로운 데이터 제작

  • 대부분의 WAS는 웹 서버 기능도 겸한다. ( 정적이미지 + 동적 비즈니스 로직 실행 )
  • 📷 그렇다면 Web Server는 WAS의 하위호환인가? No!
    - 책임 분할을 통한 서버 부하 방지 / 로드밸런싱 , WAS 헬스 체크 / 보안 (DB노출 방지) 등
    웹 서버와 WAS를 함께 사용하는 것이 일반적!

• ③ 데이터베이스(DB) :
  영구적으로 데이터를 보관하고 운영하기 위한 프로그램. 기본적으로 Relational DB 사용

정적 데이터와 동적 데이터

• 클라이언트와 서버의 데이터 교환 구조
  출처: [JSP/Servlet] Servlet에 관한 모든 것

• 서버는 클라이언트가 요청한 데이터가 정적 데이터인지 동적 데이터인지에 따라 다르게 처리한다.

  • 정적(static) 데이터 : 항상 동일하게 고정된 데이터를 전송하는 방식
    - 주로 파일로 고정된 HTML, CSS, 이미지 파일
  • 동적(dynamic) 데이터 : 필요에 따라 다른 데이터를 동적으로 구성하여 전송하는 방식
    - Server Side Programming : 서버에서 비즈니스 로직을 처리하여 데이터 보내기
    - ex) 메일함.

• 웹 서버 : 항상 같은 정적(static) 데이터를 보내는 역할만을 수행하는 서버

• 웹 애플리케이션 서버 : 동적(dynamic) 데이터를 만들어 보내는 경우

  • 톰캣의 경우 WAS의 한 종류이지만, 사실상 대부분의 WAS는 웹 서버의 기능도 같이 포함하므로 이미지, CSS/JS와 같은 정적인 자원과 서블릿/JSP 같은 동적 자원 모두 처리 가능!

🏁사용 스펙

• IDE : intelliJ Ultimate
• Java : JDK 11
• WAS : Tomcat 9.0.75

톰캣(Tomcat)설정과 웹 프로젝트 생성

• Tomcat 9.0.75

Jakarta EE 프로젝트 생성

• 다른 점 : JDK가 Amazone Corretto version이 아닌 zulu-11이다.
  VM option이 기존에 수정되어 있었다.

프로젝트 경로 설정

• 주소 경로가 지나치게 복잡하므로 수정한다.
  

변경된 코드의 반영

• 톰캣의 재시작을 최소화하기 위해서 Edit Configurations - On Update action과 On frame deactivation 설정 조정. (톰캣 한글 설정도 VM options를 이용하여 조정)이제 jsp 파일을 변경 후 가동 서버를 새로고침하면 별도의 작업 없이도 변경된 코드가 반영된 것을 확인 가능

• 단, HelloServlet과 같은 자바 코드의 변경은 조금 다르게 처리됨.
  

---

🚩 1.2 웹 기본 동작 방식 이해하기

🏁 Request(요청) / Response (응답)

HTTP(S), 웹 데이터의 요청과 응답에 사용되는 규약

1) 3 티어 아키텍처의 요청과 응답

• 3티어 아키텍처에서 이뤄지는 요청(Request)과 응답(Response)
  

• 요청 : 클라이언트 (사용자의 브라우저)가 서버에 리소스를 요청하는 것

• 응답 : 서버가 리소스를 클라이언트의 요청에 알맞은 형태로 제공하는 것

  서버는 클라이언트가 요청하는 정보를 제공해야 한다!

• 어떻게?

  • HTTP(S)라는 통신 규약을 통해서!

2) HTTP(S) 라는 약속

• 브라우저의 요청과 서버 응답 사이에는 데이터 교환을 위한 약속이 필요하다.
  이를, 프로토콜(Protocol)⭐이라고 한다.

• 웹에서는 HTTP(Hyper Text Transfer Protocol)⭐ 라는 통신 규약을 사용한다.
  URL, URI의 가장 처음 주소로는 클라이언트와 서버의 데이터 교환을 어떤 프로토콜을 할 것인지 그 스키마가 명기되어 있다.

• HTTPS는 HTTP에 보안성이 강화된 프로토콜으로, 브라우저와 서버가 데이터를 전송하기 전에 안전하고 암호화된 연결을 설정한다.

3) HTTP 메서드 [참고]

• HTTP 메서드⭐ : 클라이언트와 서버 사이에 이루어지는 요청(Request)⚡과 응답(Response)⚡ 데이터를 전송하는 방식
  

• 주요 HTTP 메서드

  • GET 방식 : 특정 리소스 조회
    - 주소창에 직접 원하는 데이터를 적거나 링크를 클릭해서 호출
    - 주소와 필요한 데이터를 한번에 같이 보낸다. 특정 정보를 조회. (body 가 없다.)
    - 서버에 전달하고 싶은 데이터는 ?와 &, = 등의 쿼리 스트링을 통해서 전달 한다.
    - GET /members/100?username=inpa&height=200
    - 조회는 POST도 가능하지만 캐싱이 가능한 GET을 권장
    
    
  • POST 방식 : 요청 데이터 처리, 주로 등록에 사용
    - 입력 화면에서 필요한 내용을 작성한 후에 '전송'과 같은 버튼 등을 클릭, 호출
    - 주소와 데이터를 따로 보내는 방식
    - 웹 화면을 통해서 실제 처리가 필요한 작업을 함.
    
    
  • PUT 방식 : 목적 리소스를 대체(덮어쓰기), 해당 리소스가 없으면 생성
    - 목적 리소스 모든 현재 표시를 요청 payload로 바꾼다.
    - 멱등성(Idempotent : 여러 번 연산을 적용하더라도 결과가 달라지지 않는 성질)을 가짐
    (GET, PUT, DELETE)
    
    
  • PATCH 방식 : 리소스 부분 변경(PUT이 전체 변경, PATCH는 일부 변경)
    - 리소스의 부분만을 수정한다.
    
    
  • DELETE 방식 : 특정 리소스를 삭제

• 기타 메서드

  • HEAD : GET과 동일하지만 메시지 부분(body 부분)을 제외하고, 상태 줄과 헤더만 반환
  • OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
  • CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
  • TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

• HTTP 메서드의 특성

  • 안정성(Safe) : 호출해도 리소스 변경이 일어나지 않는 속성 (GET, HEAD)
  • 멱등성(Idempotent) : 동일한 요청을 여러 번 보내도 한 번 보낸 것과 같은 것 (GET, PUT, DELETE )
  • 캐시 가능(Cacheable) : 응답 결과를 캐시해 사용할 수 있는 속성 (GET, HEAD)
    - POST, PATCH 도 캐시 가능하나, Message Body 캐시 키 복잡성 문제로 사용 X

4) HTTP 메시지 구성 [참고]

• HTTP 메시지는 ❶start-line 시작 라인 ❷header 헤더 ❸ empty line(공백 라인, CRLF) ❹ message body로 구성된다.
  

  • 공백 라인은 HTTP 메세지 값 구분을 하기 위한 라인이므로, 단순히 보기 편하게 넣는 것을 넘어서 반드시 있어야 한다. 만약 보낼 메세지 바디가 없다면 공백만 넣고 끝내면 된다.
    HTTP 요청 종류에 따라 Message Body가 포함될 수도 있고 아닐 수도 있다.

• HTTP 요청 메시지와 응답 메시지 [출처: 인파 블로그]
  

• 개발자 도구([F12])
  왼쪽(232 requests)은 현재까지 몇 번이나 서버를 호출했는지 보여주며, 각 항목 하나당 요청과 응답이 하나의 단위로 처리된다.

5) HTTP의 특징 : 무상태성(Stateless)와 비연결성(Connectionless)

• 무상태(Stateless) : 클라이언트와 서버 사이의 상태를 유지하지 않는다.

  • 서버는 단순히 요청이 오면 응답을 보내는 역할만 수행한다.
    통신에 필요한 모든 상태 정보들은 클라이언트에서 가지고 있다가 서버와 통신할 때 데이터를 실어 보낸다.
  • 장점 : 서버 상태 유지에 대한 부하가 현저히 적다. / 서버 확장성 높다. (스케일 아웃)
    수평 확장에 유리하다.
  • 단점 : 클라이언트가 추가 데이터 전송 (메모리) / 로그인 상태 유지 X
  • UDP와 HTTP가 Stateless한 프로토콜이다.
    
    참고 : 무상태와 상태 유지
  • 상태 유지(Stateful) : 서버가 클라이언트 상태를 보존한다.

    • 로그인 상태 유지 등 클라이언트 상태를 보존해야 할 필요성이 있다.
    • Stateful한 프로토콜 : TCP의 3-way handshaking

• 비연결성(Connectionless) : 서버와 클라이언트의 Connection 연결을 지속하지 않는다.
  (하나의 요청과 응답을 처리한 후에 연결을 종료한다.)

  • 1시간동안 수천명 이상이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 적다.
    예를들어 웹 브라우저 검색페이지에서 검색버튼만 연타하면서 이용하지는 않는듯이 말이다.
  • 장점 : 이러한 비연결성 특성 때문에 서버 자원을 매우 효율적으로 이용할 수 있다.
  • 한계 : 단기 커넥션 - HTTP 초기에는 모든 연결, 종료에 TCP Handshake가 발생함.
  • 극복 : HTTP 지속 연결(Persistent Connections) - 클라이언트는 서버와 소켓 연결을 한 다음 필요한 자원을 요청/응답으로 다운로드 받는다. 소켓 연결을 일정 시간 동안 더 유지함으로써, 필요한 자원들을 모두 다운 받을 때까지 연결이 종료되지 않고 요청/응답이 반복된 뒤 종료됨.

자바 서버 사이드 프로그래밍

• 서버 사이드 프로그래밍 : 서버 쪽에서 프로그래밍을 통해 데이터를 처리할 수 있도록 구성하는 것

  • 고려점:
    
    

  1. 동시에 여러 요청(Request)이 들어온다면 어떻게 처리해야 하는가
  2. 서버에서 문제가 생기면 이를 어떻게 처리해야 하는가?
  3. 어떤 방법으로 데이터 전송을 최적화할 수 있을까?
  4. 분산 환경이나 분산 처리와 같은 문제들은?

• JavaEE라는 기술 스펙으로 위와 같은 고려점 보완
  

- 1) 서블릿(Servlet) 기술

• 서블릿 기술 : 서버에서 동적으로 요청과 응답을 처리할 수 있는 API

  • 서블릿에서 제공하는 API를 이용해서 코드를 작성하고 이를 설정하는 방식으로 서블릿 프로그램을 작성하게 된다.[출처: 자바 웹 개발 워크북 35p]
    
  • 서블릿과 JSP는 근본적으로 같은 원리이지만,
    JSP는 HTML을 좀 더 쉽게 이용할 수 있는 방식으로 코드를 작성할 수 있기 때문에 '서블릿으로는 코드를 이용한 처리, JSP로는 화면개발'과 같이 역할을 분담해서 개발하는 것이 일반적이다.
    
    
  • 서블릿의 실행은 톰캣과 같이 서블릿을 실행할 수 있는 환경에서 실행 가능한데
    이를 서블릿 컨테이너(Servlet Container)⭐라고 하며 과거에는 서블릿 엔진(Servlet Engine)이라는 용어를 사용했다.

• 웹 컨테이너(Web Container): 웹 상의 동적인 데이터들을 처리하여 정적인 페이지로 생성해주는 소프트웨어 모듈
  (동적 데이터들을 대신 처리하여 웹 서버에 정적인 파일로 만들어서 보내준다.)

  • 웹컨테이너의 작동
    
    1) 클라이언트는 웹서버로 request(요청)을 보낸다.
    2) 서블릿을 포함하는 WAS는 컨테이너로 요청을 보낸다.
    3) 컨테이너가 요청을 각 서블릿에게 전달한다.
    4) 서블릿 메서드가 로드된다.
    5) 서블릿은 컨테이너에 관련 response(응답)을 넘겨준다.
    6) 컨테이너는 이를 서버에 전달한다. 서버는 응답을 클라이언트에게 전달한다.

• 서블릿 코드를 실행하는 주체는 톰캣과 같은 서블릿 컨테이너이므로, 일반 자바 프로그램과 비교했을 때 다음과 같은 점이 다르다.

  • 객체를 생성하거나 호출하는 주체는 사용자가 아닌 서블릿 컨테이너가 하게 된다.
  • 서블릿 클래스에서 생성하는 객체의 관리 자체가 서블릿 컨테이너에 이해서 관리된다.
  • 서블릿/JSP 코드 개발은 기본적인 자바 API와 더불어 서블릿 API도 같이 사용하게 된다.
    (🤔 Spring 삼각형 중 POJO의 원칙을 어기게 되는 것 아닌가?)

• import의 경우 javax로 시작하는 서블릿 관련 API를 사용하고 있음을 확인할 수 있다.
  또한, HelloServlet 클래스의 선언이 HttpServlet이라는 부모 클래스를 상속받는다.
  내부에는 init(), doGet(), destroy()가 작성되어 있는데 이는 서블릿 API에서 지정된 메서드이다.

• init(), doGet(), destroy()의 호출 주체는 개발자가 아닌 서블릿 컨테이너가 서블릿을 관리하며 호출한다. 일반적으로 이러한 메서드를 서블릿의 라이프 사이클(life cycle)이라고 한다.

- 2) JSP 기술

• JSP는 자바 서버 페이지(JavaServer Pages)의 약자로서, 서블릿 기술과 동일하게 서버에서 동적으로 데이터를 구성하는 기술이다.
  ✔️서블릿과 JSP는 기능의 차이는 없고 역할의 차이만 존재한다.

  1. Servlet
  ⦁ Java 코드 안에 HTML 코드를 넣는다.
  ⦁ Data Processing(Controller)에 좋다.
  ⦁ 즉 DB와의 통신, 비즈니스 로직 호출, 데이터를 읽고 확인하는 작업 등에 유용하다.
  ⦁ Servlet이 수정된 경우 Java 코드를 컴파일한 후 동적인 페이지를 처리하기 때문에
  전체 코드를 업데이트하고 다시 컴파일한 후 재배포하는 작업이 필요하다. (개발 생산성 저하)

  2. JSP
  ⦁ HTML 코드 안에 Java 코드를 넣는다.
  ⦁ HTML을 작성하기 편하기 때문에 View를 구현하기 좋다.
  ⦁ JSP가 수정된 경우 재배포할 필요가 없이 WAS가 알아서 처리한다. (쉬운 배포)

• JSP 코드는 자바 코드가 아님에도 서블릿과 동일하게 처리된다. 그 이유는 JSP 파일 역시 서블릿 코드로 변환되어서 컴파일되고 실행되기 때문이다.
  JSP 파일은 필요한 순간에 자바 파일로 생성되고, 이를 컴파일해서 class 파일로도 만들어 진다.

  C:\Users\사용자명\AppData\Local\JetBrains\IntelliJIdea2022.3\tomcat\59e36525-b4fa-443c-8544-1defaa71be21\work\Catalina\localhost\ROOT\org\apache\jsp

• JSP는 서블릿 기술과 같은 목적이지만, 브라우저에 보내는 HTML 데이터를 만들어내는 데 좀 더 특화된 기술이다.

  • 서블릿/JSP 모두 Java EE 스펙의 일부이며, 실행을 위해 서블릿 컨테이너 필요
  • 서블릿 컨테이너가 서블릿/JSP 객체를 생성하고 생명 주기를 관리
  • JSP는 내부적으로 서블릿과 같은 방식의 코드로 변환됨.
  • JSP는 HTML 내에 자바 코드 추가 / 서블릿은 자바 코드 안에 HTML 코드 추가

참고 자료

• [JSP] 서블릿(Servlet)과 JSP 정리, MVC 패턴
• [WEB] 🌐 웹 서비스 구조 (Web서버 / 웹컨테이너 / WAS) 정리

🏁 JSP 이용해서 GET/POST 처리하기

JSP 위주로 개발할 때 문제점 살펴보기

GET 방식은 입력과 조회

• 브라우저에서 직접 주소창에 입력하거나 링크를 통해서 접근하는 GET 방식은 다음과 같은 경우에 주로 사용된다.

  • 원하는 데이터 조회
  • 사용자 입력할 수 있는 화면

• webapp[/calc/input.jsp] 생성

1. <form> 태그와 POST 방식

• input.jsp : form 태그와 input 태그 이용하여 입력 화면 구성

<body>
<form>
    <input type="number" name="num1"><br/>
    <input type="number" name="num2">
    <button type="submit">SEND</button>
</form>
</body>

• form 태그 : 입력 양식. form을 이용하여 사용자가 입력하는 내용들을 전송
• input 태그 : 문자, 숫자 입력 (type이라는 속성 이용)
• button 태그 : 화면에 버튼 출력. (type=submit 속성을 이용하면 form태그 내용 전송 가능)

• 주소창에 /calc/input.jsp 입력 ➡️ <form>의 action 속성이 없으므로 자기 자신 호출
  
  (SEND버튼의 속성이 type = "button" 으로 되어 있으므로 사용자가 입력한 값을 input 태그의 name 속성값과 함께 문자열의 형태로 전송하게됨)

- 쿼리 스트링(query string)과 파라미터(parameter)

• 쿼리 스트링이란?
  
• query string은 질의 문자열로 무언가를 요구하거나 물어보는 용도로 데이터를 전달하는 것이다.

  • 쿼리 스트링은 '키=값' 형태로 데이터를 전달한다.
  • 이러한 '키=값' 형태를 흔히 파라미터(parameter)이름과 값이라고 한다.
  • ? 이후로 시작되는 부분이 쿼리 스트링이며, &으로 파라미터를 구분한다.
  • 참고 : 쿼리 파라미터 - 쿼리 스트링 VS Path Variable

POST 방식은 처리를 위한 용도

• <form>태그는 action과 method 속성을 이용하여, 양식을 어떤 방식으로 어디로 전송할 것인지 결정할 수 있다.
  action = "calcResult.jsp"로 처리하고 method는 post 방식으로 하겠다고 변경
  
  전송을 누르면 404(클라이언트가 잘못된 URL 요청을 하였음) 에러가 발생한다.
  당연하다, 현재 calcResult.jsp는 구현되어 있지 않다.

• 🌟주소창에 (주소과 데이터를) 직접 입력하는 GET방식과 달리,
  POST 방식은 주소와 전달하고자 하는 데이터를 분리해서 전송한다.GET 처럼 쿼리스트링 형태로 주소창에 데이터가 보이지 않는다.
  POST는 개발자 도구에서만 입력 값을 확인할 수 있다.

• ⭐ POST 방식은 '등록/수정/삭제' 같은 작업을 수행한다.
  GET 방식과 달리 정보의 확산이 목적이 아니므로 하나의 문자열로 모든 정보를 표현하지 않고, URL과 정보를 따로 구분해서 전달한다.

• calcResult.jsp 작성 (input.jsp에서 전달되는 num1, num2 받아서 처리하는 화면)
  

- EL(Expression Language) '${ }'

• ${}로 작성된 부분은 JSP에서 사용하는 EL(Expression Language)⭐이다.
  서버에서 데이터를 출력하는 용도로 웹에서 System.out.println과 유사한 역할을 한다.

  • 참고 : JSP - EL 표현식 문법과 사용 방법
  • 객체 프로퍼티 값을 꺼낼 때 주로 사용한다.
  • param이라는 이름의 지정된 객체를 이용하여 현재 요청에 전달된 파라미터를 쉽게 추출할 수 있다.(${param.num1}, ${param.num2})

웹의 파라미터는 모두 문자열

• JSP는 브라우저에 단순히 전달하고 싶은 데이터를 구성하는 데는 편리하다.
  BUT 복잡한 코드를 넣는 데는 적합하지 않다.
  ✔️ JSP에서 전달되는 모든 데이터는 문자열로 처리되기 때문이다.
  EL 안에서 Integer.parseInt로 전달된 문자열 param.num[1|2]를 정수로 바꾸어 계산 값 출력

JSP의 올바른 사용법

• ❶ JSP는 기본적으로 GET/POST 방식의 호출을 구분하지 않는다.
  때문에 POST 방식으로 접근해야 하는 calcResult.jsp를 GET 방식으로도 얼마든지 호출할 수 있다.(🧐 단, GET 방식으로 주소창에 직접 호출하면 Param.num1이 빈 값이기 때문에 Integer.parseInt를 사용할 때 예외가 발생하긴 한다.)

• ❷ 유지 보수 측면에서도 문제가 있다.
  JSP 파일명을 바꾸거나 JSP 파일을 교체했을 경우 이전 주소로 교체된 주소로의 접근을 허용하지 않는다. 따라서 주소가 변경된 부분을 사용자들에게 다시 알려줘야 한다.

• 최근 JSP 용도는 제한적이다.

  • JSP에서 쿼리 스트링이나 파라미터를 처리하지 않는다. - JSP 대신 서블릿을 통해 처리
  • JSP는 입력 화면을 구성하거나 처리 결과를 보여주는 용도로만 사용한다.
  • 브라우저는 직접 JSP 경로를 호출하지 않고 서블릿 경로를 통해서 JSP를 보는 방식으로 사용

• ⭐ 이러한 문제를 해결하기 위해서 등장한 방식이 '웹 MVC' 방식으로 JSP는 결과만 출력하고, 처리는 서블릿을 이용하는 방식으로 변화했다.

---

🚩 출처 | 참고 자료

• 자바 웹 개발 워크북 (구멍가게 코딩단 저 , 프리렉)
• 인파 블로그 :

  • [WEB] 🌐 웹 서비스 구조 (Web서버 / 웹컨테이너 / WAS) 정리
  • 🌐 아주 쉽게 이해하는 Stateful / Stateless 차이
  • 🌐 HTTP 메서드 종류 & 요청 흐름 💯 총정리
  • 🌐 HTTP는 무엇일까요? - 기본 핵심 요약 총정리

• [JSP] 서블릿(Servlet)과 JSP 정리, MVC 패턴
• MDN : URL이란?
• 쿼리 파라미터 : 쿼리 스트링 VS Path Variable
• MDN : <form>
• JSP - EL 표현식 문법과 사용 방법