1. 웹 3계층의 동작 방법
•
3계층 구조란 프레젠테이션 로직(클라이언트, 사용자 인터페이스), 비즈니스 로직, 데이터베이스 로직을 각각 다른 플랫폼 상에서 구현한 것이다. 3계층 구조에서 각 계층은 물리적으로도 독립적이며 각 계층의 변경이 다른 계층에 의존하지 않는다. (Web - WAS - DB 3-Tier)
프레젠테이션(클라이언트, Web) 계층
프레젠테이션 계층은 응용 프로그램의 최상위에 위치하고 있는데 이는 서로 다른 층에 있는 데이터 등과 커뮤니케이션을 한다.
•
사용자 인터페이스를 지원한다. (인터넷 브라우저의 정적인 데이터를 제공한다.)
•
이 계층은 GUI, 또는front-end도 불린다.
•
비즈니스로직이나 데이터관리코드를 포함해서는 안된다.
•
주로 웹서버를 뜻한다(물리적 : WEB서버) ex) HTML, javascript, CSS, image
어플리케이션 계층 (WAS)
이 계층은 비즈니스 로직 계층 또는 트랜잭션 계층이라고도 하는데, 비즈니스 로직은 워크스테이션으로부터의 클라이언트 요청에 대해 마치 서버처럼 행동한다. 차례로 어떤 데이터가 필요한지를 결정하고, 메인프레임 컴퓨터 상에 위치하고 있을 세 번째 계층의 프로그램에 대해서는 마치 클라이언트처럼 행동한다.
•
정보처리의 규칙을 가지고 있다.(동적인 데이터를 제공한다)
•
middleware 또는 back-end로 불린다.
•
프레젠테이션코드나 데이터관리 코드를 포함해서는 안된다.
•
주로 어플리케이션 서버를 뜻한다(물리적 : WAS서버)
ex) Java EE, ASP.NET, PHP
데이터 계층
데이터 계층은 데이터베이스와 그것에 액세스해서 읽거나 쓰는 것을 관리하는 프로그램을 포함한다. 애플리케이션의 조직은 이것보다 더욱 복잡해질 수 있지만, 3계층 관점은 대규모 프로그램에서 일부분에 관해 생각하기에 편리한 방법이다.
•
데이터베이스를 주로 뜻한다.
•
DB 또는 File System를 접근 및 관리한다.
•
back-end라고도 불린다.
•
주로 DB서버를 뜻한다(물리적 : DB서버)
ex) MySQL DB, Oracle DB
2. Web 서버와 WAS의 특징 및 차이점
웹 서버
•
웹 서버의 개념
◦
웹 서버는 소프트웨어와 하드웨어로 구분된다.
◦
1) 하드웨어
▪
Web 서버가 설치되어있는 컴퓨터
◦
2) 소프트웨어
▪
웹 브라우저 클라이언트로부터 HTTP 요청을 받아 정적인 컨텐츠(.html .jpeg .css 등)를 제공하는 컴퓨터 프로그램
•
웹 서버의 기능
◦
HTTP 프로토콜을 기반으로 하여 클라이언트(웹 브라우저 또는 웹 크롤러)의 요청을 서비스 하는 기능 을 담당한다.
◦
기능 1)
▪
정적인 컨텐츠 제공
▪
WAS를 거치지 않고 바로 자원을 제공한다.
◦
기능 2)
▪
동적인 컨텐츠 제공을 위한 요청 전달
▪
클라이언트의 요청(Request)을 WAS에 보내고, WAS가 처리한 결과를 클라이언트에게 전달(응답, Response)한다.
▪
클라이언트는 일반적으로 웹 브라우저를 의미한다.
•
웹 서버의 예
Ex) Apache Server, Nginx, IIS(Windows 전용 Web 서버) 등
WAS(Web Application Server)
•
WAS(Web Application Server)의 개념
◦
DB 조회나 다양한 로직 처리를 요구하는 동적인 컨텐츠를 제공하기 위해 만들어진 Application Server
◦
HTTP를 통해 컴퓨터나 장치에 애플리케이션을 수행해주는 미들웨어(소프트웨어 엔진)이다.
◦
“웹 컨테이너(Web Container)” 혹은 “서블릿 컨테이너(Servlet Container)”라고도 불린다.
▪
Container란 JSP, Servlet을 실행시킬 수 있는 소프트웨어를 말한다. 즉, WAS는 JSP, Servlet 구동 환경을 제공한다.
•
WAS의 역할
◦
WAS = Web Server + Web Container
◦
웹 서버 기능들을 구조적으로 분리하여 처리하고자하는 목적으로 제시되었다.
▪
분산 트랜잭션, 보안, 메시징, 쓰레드 처리 등의 기능을 처리하는 분산 환경에서 사용된다.
▪
주로 DB 서버와 같이 수행된다.
◦
현재는 WAS가 가지고 있는 웹 서버 도 정적인 컨텐츠를 처리 하는 데 있어서 성능상 큰 차이가 없다.
•
WAS의 주요 기능
◦
프로그램 실행 환경과 DB 접속 기능 제공
◦
여러 개의 트랜잭션(논리적인 작업 단위) 관리 기능
◦
업무를 처리하는 비즈니스 로직 수행
•
WAS의 예
Ex) Tomcat, JBoss, Jeus, Web Sphere 등
웹 서버와 WAS를 구분하는 이유
•
웹 서버 가 필요한 이유?
◦
클라이언트(웹 브라우저)에 이미지 파일(정적 컨텐츠)을 보내는 과정을 생각해보자.
▪
이미지 파일과 같은 정적인 파일들은 웹 문서(HTML 문서)가 클라이언트로 보내질 때 함께 가는 것이 아니다.
▪
클라이언트는 HTML 문서를 먼저 받고 그에 맞게 필요한 이미지 파일들을 다시 서버로 요청하면 그때서야 이미지 파일을 받아온다.
▪
웹 서버 를 통해 정적인 파일들을 Application Server까지 가지 않고 앞단에서 빠르게 보내줄 수 있다.
◦
따라서 웹 서버 에서는 정적 컨텐츠만 처리하도록 기능을 분배하여 서버의 부담을 줄일 수 있다.
•
WAS가 필요한 이유?
◦
웹 페이지는 정적 컨텐츠 와 동적 컨텐츠 가 모두 존재한다.
▪
사용자의 요청에 맞게 적절한 동적 컨텐츠를 만들어서 제공해야 한다.
▪
이때, 웹 서버 만을 이용한다면 사용자가 원하는 요청에 대한 결과값을 모두 미리 만들어 놓고 서비스를 해야 한다.
▪
하지만 이렇게 수행하기에는 자원이 절대적으로 부족 하다.
◦
따라서 WAS를 통해 요청에 맞는 데이터를 DB에서 가져와서 비즈니스 로직에 맞게 그때 그때 결과를 만들어서 제공함으로써 자원을 효율적으로 사용 할 수 있다.
•
그렇다면 WAS가 웹 서버 의 기능도 모두 수행하면 되지 않을까?
◦
1) 기능을 분리하여 서버 부하 방지
▪
WAS는 DB 조회나 다양한 로직을 처리하느라 바쁘기 때문에 단순한 정적 컨텐츠는 웹 서버 에서 빠르게 클라이언트에 제공하는 것이 좋다.
▪
WAS는 기본적으로 동적 컨텐츠를 제공 하기 위해 존재하는 서버이다.
▪
만약 정적 컨텐츠 요청까지 WAS가 처리한다면 정적 데이터 처리로 인해 부하가 커지게 되고, 동적 컨텐츠의 처리가 지연됨에 따라 수행 속도가 느려진다.
▪
즉, 이로 인해 페이지 노출 시간이 늘어나게 될 것이다.
◦
2) 물리적으로 분리하여 보안 강화
▪
SSL에 대한 암복호화 처리에 웹 서버 를 사용
◦
3) 여러 대의 WAS를 연결 가능
▪
Load Balancing을 위해서 웹 서버 를 사용
▪
fail over(장애 극복), fail back 처리에 유리
▪
특히 대용량 웹 어플리케이션의 경우(여러 개의 서버 사용) 웹 서버 와 WAS를 분리하여 무중단 운영을 위한 장애 극복에 쉽게 대응할 수 있다.
▪
예를 들어, 앞 단의 웹 서버 에서 오류가 발생한 WAS를 이용하지 못하도록 한 후 WAS를 재시작함으로써 사용자는 오류를 느끼지 못하고 이용할 수 있다.
◦
4) 여러 웹 어플리케이션 서비스 가능
▪
예를 들어, 하나의 서버에서 PHP Application과 Java Application을 함께 사용하는 경우
◦
5) 기타
▪
접근 허용 IP 관리, 2대 이상의 서버에서의 세션 관리 등도 웹 서버 에서 처리하면 효율적이다.
•
즉, 자원 이용의 효율성 및 장애 극복, 배포 및 유지보수의 편의성 을 위해 웹 서버 와 WAS를 분리한다.
•
웹 서버 를 WAS 앞에 두고 필요한 WAS들을 웹 서버 에 플러그인 형태로 설정하면 더욱 효율적인 분산 처리가 가능하다.
3. 웹 서버 내부의 구동 방식
웹 서버 는 클라이언트가 특정 페이지를 요청(Request)에 대해 처리한 후 결과를 클라이언트(웹 브라우저)에게 응답(Response)을 한다.
4. Servlet과 JSP의 차이점
•
Servlet : 자바 언어로 웹 개발을 위해 만들어진 것으로, Container가 이해할 수 있게 구성된 순수 자바코드로만 이루어진 것
•
JSP : html 기반에 JAVA 코드를 블록화하여 삽입한 것으로 Servlet을 좀 더 쉽게 접근할 수 있도록 만들어 진 것
5. MVC 패턴이란?
•
Model : data 처리와 접근을 담당
•
View : Client에 보여지는 화면을 담당
•
Controller : Model과 View를 제어
3가지 부분으로 나눔으로서, 데이터와 화면간의 의존관계를 벗어날 수 있게하는 개발 기법입니다.
위의 그림처럼 사용자가 controller를 조작하면 controller는 model을 통해서 데이터를 가져오고 그 정보를 바탕으로 시각적인 표현을 담당하는 View를 제어해서 사용자에게 전달하게 됩니다.
모델, Model
애플리케이션의 정보, 데이타를 나타냅니다. 데이타베이스, 처음의 정의하는 상수, 초기화값, 변수 등을 뜻합니다. 또한 이러한 DATA, 정보들의 가공을 책임지는 컴포넌트를 말합니다.
이 모델은 다음과 같은 규칙을 가지고 있습니다.
1.
사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 한다.
•
즉, 화면안의 네모박스에 글자가 표현된다면, 네모박스의 화면 위치 정보, 네모박스의 크기정보, 글자내용, 글자의 위치, 글자의 포맷 정보 등을 가지고 있어야 한다는 것입니다.
2. 뷰나 컨트롤러에 대해서 어떤 정보도 알지 말아야 한다.
•
데이터 변경이 일어났을 때 모델에서 화면 UI를 직접 조정해서 수정할 수 있도록 뷰를 참조하는 내부 속성값을 가지면 안 된다는 말입니다.
3. 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야만 한다.
•
모델의 속성 중 텍스트 정보가 변경이 된다면, 이벤트를 발생시켜 누군가에게 전달해야 하며, 누군가 모델을 변경하도록 요청하는 이벤트를 보냈을 때 이를 수신할 수 있는 처리 방법을 구현해야 합니다. 또한 모델은 재사용가능해야 하며 다른 인터페이스에서도 변하지 않아야 합니다.
뷰, View
input 텍스트, 체크박스 항목 등과 같은 사용자 인터페이스 요소를 나타냅니다. 다시 말해 데이터 및 객체의 입력, 그리고 보여주는 출력을 담당합니다. 데이타를 기반으로 사용자들이 볼 수 있는 화면입니다.
뷰에서는 다음과 같은 규칙들이 있습니다.
1. 모델이 가지고 있는 정보를 따로 저장해서는 안된다.
•
화면에 글자를 표시 하기 위해, 모델이 가지고 있는 정보를 전달받게 될텐데, 그 정보를 유지하기 위해서 임의의 뷰 내뷰에 저장하면 안됩니다. 단순히 네모 박스를 그리라는 명령을 받으면, 화면에 표시하기만 하고 그 화면을 그릴 때 필요한 정보들은 저장하지 않아야 합니다.
2. 모델이나 컨트롤러와 같이 다른 구성요소들을 몰라야 된다.
•
모델과 같은 자기 자신의 빼고는 다른 요소는 참조하거나 어떻게 동작하는지 알아서는 안됩니다. 그냥 뷰는 데이터를 받으면 화면에 표시해주는 역할만 가진다고 보면 됩니다.
3. 변경이 일어나면 변경통지에 대한 처리방법을 구현해야만 한다.
- 모델과 같이 변경이 일어났을 때 이른 누군가에게 변경을 알려줘야 하는 방법을 구현해야 합니다. 뷰에서는 화면에서 사용자가 화면에 표시된 내용을 변경하게 되면 이를 모델에게 전달해서 모델을 변경해야 할 것이다. 그 작업을 하기 위해 변경 통지를 구현합니다.
그리고 재사용가능하게끔 설계를 해야 하며 다른 정보들을 표현할 때 쉽게 설계를 해야 합니다.
컨트롤러, Controller
데이터와 사용자인터페이스 요소들을 잇는 다리역할을 합니다.
즉, 사용자가 데이터를 클릭하고, 수정하는 것에 대한 "이벤트"들을 처리하는 부분을 뜻합니다.
컨트롤러 또한 다음과 같은 규칙을 이해해야 합니다.
1. 모델이나 뷰에 대해서 알고 있어야 한다.
•
모델이나 뷰는 서로의 존재를 모르고, 변경을 외부로 알리고, 수신하는 방법만 가지고 있는데 이를 컨트롤러가 중재하기 위해 모델과 그에 관련된 뷰에 대해서 알고 있어야 합니다.
2. 모델이나 뷰의 변경을 모니터링 해야 한다.
•
모델이나 뷰의 변경 통지를 받으면 이를 해석해서 각각의 구성 요소에게 통지를 해야 합니다.
•
또한, 애플리케이션의 메인 로직은 컨트롤러가 담당하게 됩니다.
참고자료 :
