WS와 WAS 연결

1. 소개

 

Web Container 를 사용하기 위해서는 HTTP 클라이언트와 Web Container 사이에서 중간자 역할과 코디네이터 역할을 하는

 

한 개 이상의 웹서버를 설정해야 한다.

 

이런 관점에서 봤을 때 웹서버는 클라이언트 와 Web Container 구조에서 중간 계층 역할을 수행 한다.

웹서버의 기능은 기본적으로 클라이언트의 HTTP 요청을 받고 분석하고, 뒤단의 Web Container 에 있는

 

Context (Web application)에 전달해야 할 요청이라고 판단되면 Container 로 요청을 전달하는 것이다.

 

Container 는 그 요청을 분석하고 수행하여 클라이언트에게 응답을 전달할 수 있는 웹서버에게 돌려보낸다.

 

2. 리스너란 무엇인가?

 

리스너는 일반적으로 웹서버나 HTTP 클라이언트가 직접 접근 할 수 있는 Web Container 쪽의 소켓이라고

 

생각할 수 있다.

 

이 리스너(소켓)는 웹서버(또는 HTTP 클라이언트)로부터 요청을 받고 Web Container 에서 처리한 static 또는 dynamic

 

content 를 반환한다

 

(여기서 dynamic content 는 JSP 나 Servlet 과 같은 Java 기반의 컨텐츠를 의미하고 static content 는 HTML 페이지나

이미지 파일과 같은 이미 생성된 데이터를 의미한다.).

 

리스너에는 두 가지 종류가 존재한다. 웹서버 리스너와 클라이언트 리스너가 그것이다

1. 웹서버 리스너는 외부의 웹서버들과 연결되고 이들과 통신을 위해서는 맞춤 프로토콜을 사용한다.

 

클라이언트는 이 웹서버를 통하여 Web Container 와 통신한다.

 

2. 클라이언트 리스너는 주로 클라이언트와 직접 연결되고 HTTP 프로토콜을 사용한다.

 

 

이 리스너들은 종류에 상관없이 Container 레벨에서 설정되지 않고, Context Group 레벨에서 설정된다

주목할 점은 Context Group 리스너의 또 다른 사항은 이론적으로는 다수의 리스너가 각 Context Group 에 설정될 수 있다는

 

것이다. 단 한 가지의 제약 조건은 각 리스너들이 각기 다른 리스닝 포트를 지정 받아 설정되어야 한다 는 것이다.

 

3. Worker thread 와 Worker thread pool

 

각 리스너에는 풀(Worker thread pool)이라는 것이 포함되어 있다. 이것은 Worker thread 들을 관리한다.

 

리스너의 포트로 요청이 도착했을 때 한 개의 Worker thread 가 이 풀에서 꺼내어지고, 요청을 처리하기 위해 지정 받은 후

응답을 만들어 낸다. 여기에서의 “처리”라는 개념은 static content 를 가져오는 것에부터 JSP 나 Servlet 을 실행하는 것까지

 

모두를 포함한다.

 

4. 여덟 가지의 리스너들

 

1) HTTP 리스너

HTTP 리스너는 Web Container 가 자체적으로 가지고 있는 최소 규모의 “웹서버”라고 할 수 있다.

 

이것은 static content 와 JSP/Servlet 에 대한 기본 HTTP요청을 받고 처리할 수 있는 기능을 가진다.

 

하지만, CGI, PHP, SSI, 그리고 SSL/HTTPS 와 같은 보안 기능은 지원하지 않는다.

 

그렇기 때문에 실 운영환경에서는 내부 HTTP 리스너의 사용을 권장하지 않는다.

 

내부 Server 는 개발과 테스팅 목적으로 적합하다.

 

따라서, 운영환경에서는 WebtoB 또는 Apache 를 사용한다.

작은 규모의 운영환경(100~200 동시 사용자)에서는 HTTP 리스너 사용을 고려할 수도 있다.

 

기능면에서 좀 부족함이 있지만 이러한 제한된 환경 내에서는 WebtoB 나 Apache 보다 좋은 성능을 보여준다.

 

2) 보안 리스너

보안 리스너는 HTTP 리스너와 동일하지만 SSL(HTTPS)도 지원한다는 것이 다르다.

 

3) TCP 리스너

TCP 리스너는 일반적인 리스너에 맞춤 프로토콜(HTTP 를 사용하지 않음)을 사용하는 리스너이다.

 

4) UDP 리스너

UDP 리스너는 TCP 리스너와 동일하나 TCP 대신 UDP 프로토콜을 사용한다는 점만 다르다.

 

따라서 이후에는 특별한 언급이 없을 경우 TCP 리스너와 동일하다고 보면 된다.

 

5) Apache 리스너

Apache리스너는 앞단의 Apache Server와 연동을 가능하게 한다.

 

Apache Open Source Server는 http://www.apache.org/에서 다운 받을 수 있다.

Apache 리스너는 위에서 설명한 세 개의 리스너와 같은 방식으로 작동한다.

다른 점은 웹서버가 내부적으로 운영되는 반면 Apache 웹서버가 Web Container 의 앞 단에서 외부적으로 실행되고 있다는

 

것이다.

6) WebtoB 리스너

 

WebtoB 는 JEUS Web 어플리케이션 Server 의 기본 웹서버다.

 

WebtoB 는static 페이지 전송, CGI, SSI, PHP 등 기본적인 웹서버 기능들을 모두 지원한다.

 

JEUS Web Container 와 인터페이스 할 때에는 Servlet/JSP 서비스도 제공한다.

 

WebtoB 리스너는 위에서 언급한 리스너와 조금 다른 종류의 리스너라고 할수 있다.

WebtoB 리스너는 다른 리스너와 달리 리스너가 WebtoB Server 의 위치를 찾아서, 접속하고자 하는 특징을 가진다.

 

그러므로, WebtoB 리스너를 사용할 때에는 WebtoB Server 가 리스닝 모드로 대기를 하고,

 

WebtoB 리스너(즉, Web Container)가 연결을 시도한다.

 

이러한 연결방식을 Reverse Connection Pooling 이라 한다.

중요: 위 문장은 WebtoB Server 가 Web Container 보다 먼저 구동 중에 있어야한다는 것을 뜻한다.

이런 특징의 결과로 방화벽 밖에 WebtoB Server 를 위치하고 안쪽에서 리스너를 이용하여 연결을 맺을 수 있다.

 

이것은 방화벽이 주로 밖으로부터의 연결시도를 억제하고 안으로부터의 연결은 가능하게 하여 방화벽의 장점을

 

그대로 살릴 수 있는 특징을 부여한다. 다른 종류의 리스너와 웹서버를 방화벽과 사용할 경우에는 이러한 구성이 어렵다.

둘째, WebtoB 와 Web Container 가 같은 머신 내에 존재하면 둘 간의 통신은 Pipe 통신을 사용한다.

 

일반적인 소켓 방식을 사용하는 것보다 Pipe 통신을함으로써 월등한 성능 향상을 기대할 수 있다.

참고: WS 엔진은 노드 당 하나만을 사용할 수 있다.

 

7) AJP13 Listener

이 리스너는 AJP 1.3 protocol 을 사용하는데, Apache listener 가 AJP 1.2 protocol 을 사용하는 것을 제외하고는

 

Apache listener 와 동일하게 동작한다.

AJP 1.3 listener 는 Apache listener 보다 강력한 기능을 가진다.

 

따라서 Apache 서버가 AJP 1.3(mod_jk module 을 통해서)을 지원한다면 AJP 1.3 listener 를 사용할 것을 권장한다.

 

8) Tmax Listener

Tmax 는 분산 환경에서 이질적인 자원을 통합해 주는 시스템 소프트웨어이다.

 

Tmax 리스너는 Tmax 와 연동하기 위한 특수한 리스너로 WebtoB 리스너와 마찬가지로 활동적인 리스너이기 때문에

 

Web Container 를 구동시키기 전에 Tmax 가 먼저 구동되어 있어야 한다.

Tmax 리스너는 Jeus 와 Tmax 간의 정보를 주고 받거나, http 요청을 Tmax 의 Gateway 를 통해 받음으로써 통신 채널을

 

일원화 하는 등의 용도로 사용될수 있다.