Web Application과 Web Server, Servlet과 WAS의 관계

웹 어플리케이션 개요

1. 데스크톱 어플리케이션

웹 브라우저 없이 데스크톱에서 바로 실행되는 어플리케이션

예) Java GUI 프로그래밍을 위한 awt, swing 라이브러리를 이용하여 개발한 프로그램

단점
번거로운 배포 과정 - 기능 업데이트가 있을 때 마다 배포된 PC 모두 재배포 필요. 시간, 인력 등 자원 낭비
취약한 보안 - 코드만으로 구동되는 애플리케이션이므로, 코드 내에 적힌 데이터베이스 접속 정보 등 보안에 관한 정보 노출 위험

(사실 쓸모가 없다...)

 

 

2. 초기 클라이언트-서버 어플리케이션

Client	Server
UI, 비즈니스 로직(기능)	데이터 처리

단점
번거로운 배포 과정 - 변경 사항이 있을 때 마다 클라이언트와 서버 둘 다 업데이트 필요
취약한 보안 - 클라이언트가 직접 데이터에 접근하므로 보안 관련 정보 탈취 위험성 존재

이러한 단점을 개선하기 위한 클라이언트-서버 구조 등장

 

 

3. 개선된 클라이언트-서버 어플리케이션

Client	Application Server	Database Server
UI	네트워크, 비즈니스 로직	데이터 처리

장점
보안성 강화 - 어플리케이션 서버가 데이터베이스에 접근하므로 클라이언트는 데이터에 관한 정보를 몰라도 됨
초기보다 용이한 배포 - 어플리케이션 서버에서 변경사항이 생겨도 전체가 아닌 어플리케이션 서버만 바꿔서 배포 가능 
단점
불편한 어플리케이션 설정
1) 다중 요청에 대한 처리 - 한 번에 하나의 클라이언트 요청만 수행할 수 있기 때문에 하나의 작업이 끝나야만 다른 요청 수행 가능
-> 해결 방안 : 멀티스레드 프로그래밍으로 클라이언트 요청 마다 각각의 스레드를 생성하여 처리
2) 서버 통신을 위한 소켓 프로그래밍 필요
3...) 데이터베이스 커넥션, 트랜잭션 관리, 자바 빈 등 여러 설정들 직접 관리 필요

이러한 단점을 개선하기 위해 웹 서버 어플리케이션 구조 등장

 

 

4. 웹 서버 어플리케이션

Client	Web Server	Application Server	Database Server
UI	네트워크	비즈니스 로직	데이터 처리

장점
네트워크 관리를 웹 서버가 대신 담당하므로 어플리케이션 서버에서는 비즈니스 로직 개발에만 집중 가능
배포 용이 - 기능 추가 또는 업데이트가 있어도 어플리케이션 서버만 변경하여 배포 가능

그렇다면 웹 서버는 뭐하는 넘이냐

 

 

 

웹 서버 어플리케이션

1.  정적 페이지(Static Page)

웹 서버 삼형제 HTML, CSS, JavaScvript

장점
단순한 정적 컨텐츠(예)이미지)를 클라이언트에게 빠르게 제공 가능
단점
정해진 컨텐츠만 뱉어냄

아앗; 웹 페이지에서 데이터베이스와 데이터 주고받으며 지지고 볶은 결과도 보고싶어...

-> 동적 페이지를 원해!

 

 

2. 동적 페이지(Dynamic Page)와 CGI

동적 페이지를 위해서는 클라이언트-웹 서버 통신이 필요하다.

클라이언트가 웹 서버에게 돈을 주고 '사과 사와라' 라고 하면 웹서버는 사과를 구해 클라이언트에게 갖다줘야 한다. 

이 때 돈과 사과가 오가는 방식을 정리해 둔 규칙이 있다.

CGI (Common Gateway Interface)
웹 서버와 프로그램 사이의 데이터 통신 규칙

클라이언트-서버 어플리케이션 아키텍쳐에서 멀티 스레드와 소켓 프로그래밍, 데이터베이스 커넥션 등을 직접 구현했었다. 귀찮으니까 CGI를 이용해 클라이언트가 보내는 요청에 대해 데이터베이스 커넥션을 열고 프로세스를 생성하는 정해진 방식을 따르기로 한다. 언어 종류에 상관 없이 이 인터페이스를 구현하면 웹 서버와 통신이 가능한 것이다.

 

 

3. Servlet

 Java는 웹 서버 통신을 위해 Jakarta EE 라이브러리의 Servlet 클래스를 사용한다. 

Jakarta EE
(Enterprise Edition - Java EE에서 이클립스가 인수하면서부터 Jakarta로 명칭이 바뀌었다.)
기업용 애플리케이션 개발에 필요한 기술 정의 모음(플랫폼)
Java SE에 부가적으로 웹 서버 개발을 위한 기능

그렇지만 Servlet은 클래스일 뿐이다. 이것만으로 웹 서버 통신을 할 수 없다.

그렇다면 이 라이브러리로 어떻게 웹 서버 통신을 하냐고 물어본다면 WAS를 사용해서~

 

 

3. WAS

그런데 그 전에 문제가 있음. 클라이언트에서 요청이 올 때 마다 CGI구현체를 계속 만들어낸다... 같은 요청이어도 새 객체를 만들어 사용한다는 것이다. 저런!... 메모리, 리소스 등 자원을 너무 잡아먹는다.

완 전 비효율적

 

이 구현체를 싱글톤 방식으로 사용한다면 어떨까...! 그게 바로 WAS의 역할이다.

WAS (Web Application Server)
=  웹 컨테이너 web Container
= 서블릿 컨테이너 Servlet Container

 

 

Servlet과 WAS로 동적 페이지를 구현할 수 있는 웹 어플리케이션 서버를 구성할 수 있다.

1. 클라이언트가 쿼리 스트링을 통해 돌래를 달라고 요청

2. WAS가 Selvet의 doGet( ) 메소드를 호출함으로써 돌래 요청

3. Servlet은 요청을 보고 데이터베이스에게 돌래를 달라고 함

4. 데이터베이스는 돌래를 찾아 Servlet에게 줌

5. Servlet은 WAS에게 돌래를 전달함으로써 응답

6. WAS가 클라이언트에게 돌래를 전달함으로써 응답

WAS내에 Servlet 클래스 코드가 포함된 것이 아님! 톰캣의 카타리나가 복사해서 WAS에 띄운거임
톰캣은 더 공부해서 글써오겟음니다

 

 

이제 WAS가 CGI를 구체화해서 사용하던 역할을 대신 하게된다.

요청이 들어왔을 때,

기존 Thread Pool에 스레드가 존재하지 않음 -> 새로운 thread 생성

Thread Pool에 사용할 수 있는 스레드가 존재 -> 가져다가 사용 후 프로세스 종료 시 반납

 

CGI는 요청마다 새로운 객체를 생성했다면, Thread Pool은 이미 존재하는 객체를 바로 사용할 수 있으므로 더 빠른 속도로 연결할 수 있고 효율적인 자원 관리가 가능하다.

 

 

3. Web Server와 WAS의 차이

웹 서버

Nginx, Apache Server...

80port, 정적 페이지

 

웹 컨테이너 = WAS

Tomcat...

8080port, 동적 페이지

 

사담 - 톰캣을 아파치 톰캣이라고도 부른다. 톰캣 5.5부터 웹 서버도 지원하게 되었고 톰캣이 아파치 재단 거기도 하고,,,걍 톰캣하면 was를 생각하면 되겠다

 

아그럼 톰캣 원툴로 동적 페이지 구현 가능 아니냐

-> 가능하긴 한데 전략 상 나눠쓰는거임 웹 서버로 로드 밸런싱하거나 접근 제한하거나 여러 서버 was물릴수도 잇고 정적 페이지까지 was에 부담시키는것보다 어차피 정적인거 웹 서버가 웹 브라우저에 빨리 보내주면 더 좋은거고 레고놀이 가능