JEUS의 노드 이름은 기본적으로 JEUS Manager가 구동되는 머신의 네트워크 이름(hostname)이다. 하지만 한 머신에 여러 개의 노드를 띄우고 싶은 경우에 가상 노드 기능을 사용하여 각 노드에 가상의 이름을 부여할 수 있다. 이 기능을 이용하면 한 머신에 여러 노드를 설정해 놓고 클러스터도 구성할 수 있다. 물론 여러 머신에 분산하는 경우만큼 큰 효과를 기대할 수는 없지만 개발 환경에서 가상적으로 클러스터를 구성하는 데 유용하다. 이 경우에 각각의 JEUS Manager에 서로 다른 Base Port를 할당해야 한다.

가상 노드 설정에 관해 좀 더 자세한 내용은 “2.2.2. 가상 노드 설정”을 참고한다.

JEUS에서는 노드 간에 Failover, 부하 분산을 위해서 서로 다른 노드들과 연결하여 클러스터를 구성할 수 있도록 하고 있다. 이러한 기능을 노드 클러스터링이라고 한다.

다음은 4개의 노드를 연결한 클러스터를 보여준다.

각 노드는 고유의 IP 주소를 가지고 있는 전용 머신에서 운영되거나 JEUS의 가상 노드 기능을 이용하면 2개 이상의 노드를 하나의 머신에 설치해서 클러스터를 구성할 수 있다. 클러스터링된 노드들은 JEUS Manager 간에 P2P(Peer-to-Peer)로 연결을 맺고 주기적으로 서로의 상태를 점검한다. 만약 노드 하나가 다운되었을 경우 이에 대한 대책으로 관리자에게 경고 메일을 보내고 백업 노드를 띄운다거나, 다운된 노드로 가는 요청을 다른 노드로 가도록 Failover 처리를 한다.

또한 각각의 노드에 있는 리소스와 애플리케이션을 같은 클러스터에 있는 다른 노드에서 액세스가 가능하다. 노드 클러스터링에 관한 보다 자세한 내용은 “제4장 JEUS 클러스터링”을 참고한다.

다음은 JEUS Manager에서 제공하는 엔진 컨테이너에서 공통적으로 필요로 하는 서비스에 대한 설명이다.

JEUS Manager는 다음과 같은 동작 상태를 갖는다.

JEUS Manager를 시작시키려면 실행 스크립트를 사용해야 한다. JEUS에서는 jeus라는 이름으로 제공한다. jeus 스크립트를 실행하면 SHUTDOWN 상태에서 BOOTING 상태로 가게 되고, JEUS Manager의 초기화가 완료되면 READY 상태가 된다. JEUS Manager가 READY 상태일 때 관리 툴로 엔진 컨테이너를 실행시키거나 JEUS Manager를 종료할 수 있다.

JEUS가 시스템 내부, 다른 노드 또는 원격 클라이언트와 통신하기 위해 필요로 하는 기본 TCP 소켓 포트를 Base Port라 한다. 기본적으로 9736을 사용한다. 이 Port는 JEUS Manager가 구동되면서 열리며 다른 서비스들의 Port는 이 Base Port에 기반하여 상대적으로 결정된다. 몇몇 서비스의 경우에는 서비스 특성에 따라 별도의 Port를 사용하는 경우도 있지만 대부분의 서비스들은 Base Port를 통해 이용할 수 있다.

엔진은 Java EE에서 정의한 EJB 컨테이너, 웹 컨테이너와 매핑되는 개념으로 사용자가 디플로이한 컴포넌트를 관리하는 역할을 한다. 엔진은 엔진 컨테이너에 포함되는 요소이며, JEUS Manager 및 엔진 컨테이너가 제공하는 서비스들을 이용하여 컴포넌트를 실행시킨다.

JEUS의 엔진은 다음과 같이 4가지 종류가 있다.

다음은 엔진 컨테이너의 주요 서비스에 대한 설명이다.

엔진 컨테이너는 다음과 같은 동작 상태를 갖는다. 단, 엔진 컨테이너의 상태는 JEUS Manager에 의해서 결정된다.

JEUS Manager가 READY 상태일 때 관리 툴을 통해서 엔진 컨테이너를 시작시키거나 다운시킬 수 있다. 만약 엔진 컨테이너가 STARTING 상태에서 설정 오류나 시스템 오류로 인해 시작이 실패했을 경우에는 SHUTDOWN 상태가 된다. 이때 관리 툴에 의해서 다시 STARTING 상태로 될 수 있다. JEUS에서는 관리 툴로 콘솔 툴(jeusadmin), WebAdmin을 제공한다.

Invocation Manager는 엔진 컨테이너에서 컴포넌트(서블릿/JSP, Stateless Session Bean, MDB)를 호출하는 경우에 사용하는 리소스에 대해 Logging을 남기거나 반환하는 작업을 한다. 이 구성요소를 위해 3가지 모드 중 하나를 선택할 수 있다.

엔진 컨테이너는 JEUS Manager가 실행되는 JVM과는 다른 JVM에서 실행된다. 이것은 애플리케이션의 오류로 인해 엔진 컨테이너에 문제가 발생하더라도 JEUS Manager에는 영향을 주지 않기 위한 구조이다. 그러나 명시적으로 엔진 컨테이너의 이름을 'default'로 정함으로써, JEUS Manager가 실행되는 JVM에서 엔진 컨테이너를 실행 시킬 수 있다. Default 엔진 컨테이너는 주로 개발 환경에서 여러 엔진 컨테이너를 운영할 필요가 없을 때 사용된다.

보통 모든 엔진 컨테이너는 JEUS Manager가 실행되는 JVM과는 다른 JVM에서 실행된다. 이것은 엔진 컨테이너나 혹은 그것에 포함된 엔진들에 문제가 발생할 경우 JEUS Manager에는 영향을 주지 않기 위한 구조이다. 그러나 이와 반대로 JEUS Manager에 문제가 생길 경우 엔진 컨테이너에서 운영되는 애플리케이션들이 JEUS Manager의 서비스를 이용할 수가 없기 때문에 정상적으로 진행되지 않을 수 있다.

따라서 엔진 컨테이너가 JEUS Manager의 상태를 주기적으로 감시하고, 만약 JEUS Manager에 이상이 생길 경우 자체적으로 다운(Self-Down)하는 기능을 제공한다.

JEUS Manager 감시의 상태 전이

엔진 컨테이너가 JEUS Manager의 상태를 잘못 판단하거나 순간적인 부하로 인해 잠시동안 비정상 상황이 되는 경우에 엔진 컨테이너가 Self-Down해 버리면 문제가 있을 수 있다.

따라서 JEUS Manager 감시는 다음과 같은 4단계로 나눠서 상태를 최대한 올바르게 판단할 수 있도록 한다.

JEUS Manager 감시 방법

JEUS Manager 감시의 경우 다음의 2가지 종류 중 하나를 선택하여 사용할 수 있으며, JEUS Manager 감시(Self-Down 기능)를 사용하지 않을 수도 있다.

JEUS Manager 감시의 설정

다음과 같은 엔진 컨테이너 옵션으로 JEUS Manager 감시(Self-Down기능)를 세부적으로 조정할 수 있다. JEUS Manager 감시의 상태전이의 경우 위의 "JEUS Manager 감시 방법"을 참조한다.

JEUS는 애플리케이션 간에 클래스가 중복되어 발생하는 문제를 방지하기 위해 애플리케이션마다 서로 다른 클래스 로더를 사용한다. 이를 Isolated Class Loader(이하 Isolated)라고 하는데, Java EE 표준은 이 방식을 기본으로 사용할 것을 권장하고 있으며 JEUS도 그 권고를 따르고 있다.

다음은 Isolated Class Loader 계층 구조이다.

이 구조에서는 각 애플리케이션의 웹 모듈의 클래스 로더가 그 애플리케이션의 EJB 클래스 로더의 하위에 존재한다. 그리고 한 애플리케이션의 클래스 로더는 다른 애플리케이션의 클래스 로더에 클래스를 요청하지 않는다. Java EE 표준은 애플리케이션이 다른 애플리케이션의 인터페이스를 필요로 하는 경우 그 인터페이스들을 같이 패키징하도록 규정하고 있으므로 다른 애플리케이션의 클로스 로더를 참조할 수 없다.

클래스를 공유해서 사용하지 않기 때문에 한 애플리케이션을 다시 디플로이할 때 다른 애플리케이션도 같이 다시 디플로이할 필요가 없어진다. 이 클래스 로더 구조를 제대로 사용하기 위해서는 결국 연관된 애플리케이션끼리 EAR로 묶어서 하나의 애플리케이션으로 만드는 작업이 필요하다.

웹 클래스 로더가 EJB 클래스 로더로 클래스를 요청할 수 있다. EJB 모듈 클래스 로더 중 하나가 다른 EJB 모듈 클래스 로더로 필요한 클래스를 요청할 수도 있다. 이처럼 서로 다른 애플리케이션 간에 클래스 로더를 공유하는 것을 Shared Class Loader라고 한다.

다음은 Shared Class Loader 계층 구조이다.

다음은 각 애플리케이션의 클래스 로더에 대한 설명이다.