[Xml] JEUS - WS 와 WAS 연결

--------------------------------------------------------------------------------------------------

제목 : JEUS - WS 와 WAS 연결 하기

참고자료 : http://technet.tmaxsoft.com

 --------------------------------------------------------------------------------------------------

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 를 통해 받음으로써 통신 채널을

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

---------------<<WEBMain.xml>>-----------------------------------------

<?xml version="1.0"?>
<web-container xmlns="http://www.tmaxsoft.com/xml/ns/jeus">
. . .
    <context-group>
. . .
        <webserver-connection>

         //Context Group 에는 단 하나의 <webserverconnection> 태그가 존재할 수 있지만 이 아래에는 여러 개의 리스너

         //설정이존재할 수 있다

            <webtob-listener>
                <listener-id>WebListener2</listener-id>
                <port>9900</port>

                 //WebtoB Server 와 연결할 Port. 이 포트 값은 WebtoB 설정 파일내의 JSVPORT 설정 값과 일치해야 한다.

                <output-buffer-size>16384</output-buffer-size>
                <thread-pool>
                    <min>10</min>
                    <max>10</max>

                     //min, max 값이 WebtoB 설정 파일의 *SERVER 절에 지정된 MinProc, MaxProc 값과 일치해야 한다.

                    <step>4</step>
                    <max-idle-time>60000</max-idle-time>
                    <max-wait-queue>2</max-wait-queue>
                    <thread-state-notify>
                        <max-thread-active-time>150000</max-thread-active-time>
                        <notify-threshold>100</notify-threshold>
                        <restart-threshold>18</restart-threshold>
                        <notifier-id>MyNotifier</notifier-id>
                        <notify-subject>JEUS WEB CONTAINER THREAD STATE WARNING</notify-subject>
                        <restart-subject>JEUS WEB CONTAINER RESTART WARNING</restart-subject>
                    </thread-state-notify>
                </thread-pool>
                <postdata-read-timeout>40000</postdata-read-timeout>
                <scheme>http</scheme>

                <hth-count>2</hth-count>

                 //HTH count는WebtoB 설정 파일의 *NODE 절에 지정된 HTH 프로세스 개수와 일치해야 한다

                <request-prefetch>true</request- prefetch>

                 //Request prefetch : Web Container 측에서 요청을 처리하는 동안 다음 요청을 WebtoB 로부터 미리 받아 올

                 //것인지 정한다.(Boolean 값).

                 //이기능이 활성화 되면, Web Container 는 각 WebtoB Worker Thread 마다 하나의 큐를 할당한다.

                 //큐는 Worker Thread 가 현재 요청을 처리하는 동안 WebtoB 로 부터오는 요청을 버퍼링한다.

                 //따라서 Web Container는 WebtoB 로부터 다음 요청을 받는 시간을 단축 시킬 수 있다.

                 //이 기능의 단점은 요청을 처리하는 도중 Web Container 에 심각한 문제가 발생하면,

                 //큐에 축적된 요청들을 잃어버릴 수 있다는 점이다.

                <disable-pipe>false</disable-pipe>

                 //disable pipe 설정이 "true"로 설정되어 있으면 WebtoB 와 Web Container 의 효율적인 Pipe 통신을

                 //불가능하게 한다.

                 //WebtoB Server와 Web Container 가 다른 머신에서 수행되고 있으면 필요한 항목이다.

                <webtob-address>111.111.111.111</webtob-address>

                 //WebtoB (IP) address. WebContainer 와 연결을 맺을 WebtoB 의 IP 주소 항목이다.

                <registration-id>MyGroup</registration-id>

                 //registration ID 는 WebtoB 설정파일의 *SERVER 값과 일치해야 한다.

                 //설정하지 않은 경우 기본값으로 이 값은 Context Group 의 이름과 같은 값으로 설정된다.

                <webtob-home>c:\WebtoB\</webtob-home>

                 //WebtoB home directory 는 JEUS_WSDIR 이라는 환경 변수로 정의된 WebtoB 의 기본 WebtoB Home 과

                 //다를 경우에 설정한다 (또는 그 환경변수가 설정되어 있지 않을 때).

                 //이 설정은 두 개 이상의 WebtoB 인스턴스가 로컬 머신에서 운영되고 있고 Web Container 가 이 두 개

                 //이상의 WebtoB 인스턴스에 연결될 필요가 있을 때 유용하다.

                <read-timeout>120000</read-timeout>

                 //read timeout 설정: WebtoB 웹서버는 지속적으로 Web Container 에게 WebtoB 의 설정 파일에 정의된

                 // “svrchktime” 변수 값의 간격으로 “ping”메시지를 보낸다.

                 //Web Container 는 여기에서 정의한 시간 간격으로 WebtoB 의 ping 을 체크한다.

                 //WebtoB 의 ping 이 여기에서 설정된 시간 간격 내에서 발견되지 않으면 통신 연결은 끊어진 것으로

                 //간주되어 다시 설정된다. 그러므로, 여기의 값은 “svrchktime”보다 커야 한다.

                <reconnect-timeout>60000</reconnect-timeout>

                 //reconnect timeout 값: WebtoB Server 와 WebtoB 리스너 사이의 연결들이 운영도중 끊어질 경우가 생길 수 있다.

                 //Reconnect-timeout 은 이러한 경우에 재연결 시도를 위한 제한 시간이다.

                 //제한된 시간이 지나면 현재의 모든 WebtoB 연결은 끊어지고, 만약 WebtoB 백업이 지정되어 있으면

                 //Web Container 는 다음 WebtoB Server 에 Fail-over 를 시도한다.

                 //다음 WebtoB 백업 마저 장애가 난다면 그 다음의 것을 시도한다.

                 //최후의 WebtoB 마저 장애가 나면 주 WebtoB 리스너에 시도하게 된다.

                 //“-1”은 무한대 반복 시도, “0”은 재연결 시도를 하지 않음을의미한다.

                <webtob-backup>
                    <port>9901</port>
                    <output-buffer-size16384</output-buffer-size>
                    <thread-pool>
...
                    </thread-pool>
...
                    <webtob-address>111.111.111.112</webtob-address>
...
                </webtob-backup>
            </webtob-listener>

            <apache-listener>
. . .
            </apache-listener>

            <http-listener>
                <listener-id>WebListener1</listener-id>

                 //listener ID: 리스너의 유일한 식별자 이다. 이름은 WEBMain.xml파일 내부에서 유일한 것이어야 한다.

                 //여기에서의 ID는 “non-shared” 모드의 DB풀에서 리스너가 작업하고 있는 쓰레드 풀(Servlet 풀)을

                 //식별하기 위해 사용된다.

                <port>8007</port>

                //port number: 클라이언트(또는 Apache Server)가 연결되어 있는 포트번호 이다.

                //HTTP를 위해서는 기본적으로 80 번을 사용하고 SSL을 위해서는 443 을 사용한다

                //(IANA, http://www.iana.org/ 에서 정의). JEUS설정에서는 어떤 포트도 기본으로 설정되어 있지 않으므로

                //이 태그는 모든 리스너에서 반드시 지정해 줘야 한다.

                <output-buffer-size>16384</output-buffer-size>

                 //output buffer size: Servlet 결과가 임시적으로 저장되는 내부 캐시 버퍼의 크기를 결정한다.

                 //버퍼가 꽉 찼을 때에는 한 번에 클라이언트에게 모두 보내진다.

                 //이 옵션은 성능향상을 위해 사용되지만 일반적으로 사용되지 않는다.

                <thread-pool>

                //worker-thread pool: 이 설정은 각 리스너의 Worker thread pool 의 크기와 행동 방식을 결정짓는다.

                //worker thread 가 클라이언트 요청을 리하기 위해서 사용되며 풀 크기가 크면 클수록 더 많은 요청이 

                //동시에 처리될 수 있다 (시스템 리소스를 많이 사용한다). 쓰레드 풀의 설정을 다음과 같다.

                    <min>10</min>
                    <max>20</max>
                    <step>2</step>

                     //Step 설정은 풀의 크기가 증가할 때 몇 개 씩의 쓰레드가 증가할 것인지를 지정한다.

                    <max-idle-time>60000</max-idle-time>

                     //maximum idle time 은 풀 내에 존재하던 쓰레드가 제거되기전까지의 사용되고 있지 않은 시간을 지정한다

                     //(결과로 시스템자원은 늘어난다).
                     //각 Worker thread pool 은 request wait queue 를 가지고 있다. 이 큐는 실제 가용한 Worker thread 보다

                     //많은 요청이 들어 올 때사용된다.

                     //이 큐는 소켓 리스너에 의해 유지되는 낮은 레벨의 backlog 큐보다 상위 레벨의 큐이다.

                     //다음의 두 태그는 이 큐와 관련된 것들이다.

                    <max-wait-queue>10</max-wait-queue>

                     //max wait queue 설정은 더 많은 Worker thread 가 풀에 생성되기 전에 얼마나 많은 요청들이

                     //request wait queue 에 존재할 수있는지에 대해 결정한다

                     //(몇 개의 쓰레드가 증가될 지는 step설정에서 정의된다).

                    <max-queue>50</max-queue>

                     //max queue 설정은 큐에 대기할 수 있는 최대 요청값을 설정한다.

                     //이 큐가 꽉 찬 후에 더 많은 요청이 도착하면 busy 페이지가 클라이언트에게 반환된다.

                    <thread-state-notify>
                        ... <!-- see next sub-section -->
                    </thread-state-notify>
                </thread-pool>
                <postdata-read-timeout>40000</postdata-read-timeout>

                //postdata read timeout 설정은 웹서버나 Web 클라이언트에서 postdata 를 읽어 들일 때 기다릴 수 있는 최대

                //시간 값이다.

                //읽기는request.getInputStream().read() 메소드로 한다. 단위는 천분의 일초이고 기본 값은 30000 이다.

                <scheme>http</scheme>

                 //Scheme 에 설정하는 값은 javax.servlet.http.HttpServletRequest.getScheme() 메소드에 의해 반환되는

                 //프로토콜의 값을 정의한다.

                 //보안 리스너 또는 WebtoB 나 Apache에서 SSL 기능을 사용할 경우에는 “https”값이 지정되어야 한다.

                <back-log>100</back-log>

                 //Backlog 는 요청이 매우 빈번하고 리스너가 더 이상 지탱하지 못할 경우에 큐잉될 수 있는 최대 클라이언트

                 //요청 값을 지정한다.

                 //이 값은 리스너 Server 소켓이 인스턴스화 되었을 때에 java.net.ServerSocket(int port, int backlog)에 전달된다.

                 //큐잉된 클라이언트 연결 요청 값이 backlog 크기를 초과할 경우에는 클라이언트는 “connection refused”

                 //메시지를 받는다.

                <server-access-control>true</server-access-control>

                 //server access control Boolean 스위치는 클라이언트 또는 웹서버 접근제한을 켜고 끈다.

                <allowed-server>127.0.0.1</allowed-server>

                 //allowed servers list 는 위의 server access control 이 켜져 있을 때만 사용할 수 있다.

                 //이 리스트는 어떤 클라이언트 또는 Server 들이 이 리스너에 접근할 수 있는지 지정한다.

                 //이 리스트에 있는 클라이언트들은 그들의 IP 주소를 이용하여 식별한다.

            </http-listener>

. . .
            </tcp-listener>
            <secure-listener>
. . .
            </secure-listener>
...
        </webserver-connection>
. . .
    </context-group>
...
</web-container>

---------------<<WEBMain.xml>>-----------------------------------------

[출처] JEUS - WS 와 WAS 연결 하기 (geckos kitchen) |작성자 soju_glass