[JBoss] JBoss EAP 6 모듈 아키텍처

1. JBoss EAP 6 아키텍처

JBoss EAP 6 버전에서 각각의 모듈에 대하여 기능을 설정하는 서브시스템은 Java EE의 표준을 제공하는 모듈로, JBoss 시작 시 코어 기능을 제공하는 핵심 서브시스템(Core Subsystem), 클러스터 기능을 제공하는 것 등의 여러 가지 기능을 제공하는 모듈이다. 이때 어느 서브시스템을 이용할 지는 프로파일(Profile)이라 불리는 Subsystem Set을 설정하는 설정파일로 정의할 수 있는데, 이것들이 스탠얼론 모드에서는 standalone.xml, 도메인 모드에서는 domain.xml 인 것이다.

 

JBoss EAP 6의 가동 시 맨 처음에 bootstrap 서비스를 시작하는데, 이는 다른 서비스를 deploy 하기 위한 최소한의 서비스로, JBoss Module, MSC(Modular Service Container)와 코어 서비스인 Threads, Logging, Deployment Scanner, Remoting을 시작하고, 이후에 그 외의 서비스들을 deploy하게 되어 있다.

 이때 그 외의 서비스들이 모두 서브시스템에 해당되게 되는데, JBoss EAP 6 자체가 이러한 서브시스템으로부터 구성되어 있기 때문에, 모듈들의 집합체가 곧 JBoss EAP 6 라고 할 수 있음을 의미한다.

 JBoss EAP 6는 이러한 서브시스템을 관리할 수 있는 운용 관리 서비스로서, Management 를 제공한다. 관리 CLI나 관리 콘솔이라고 하는 운용 관리도구들은 Management에 요청을 보내 결과를 수신하는 것이다.

 

JBoss EAP 6 아키텍처

---

2. 클래스 로더 및 모듈 소개

JBoss EAP 6 에서는 deploy된 애플리케이션의 Class-Path 를 제어하기 위한 새로운 모듈 형식의 클래스 로드 시스템을 사용한다. 이는 기존의 계층형 클래스 로더(기존 JVM이 클래스를 로딩하는 방식)보다 유연하고 관리할 수 있는 범위가 매우 강력해졌다. 개발자가 애플리케이션에서 사용할 수 있는 Class에 대해 상세한 제어가 가능하여, 애플리케이션 서버에서 제공하는 Class를 무시하고, JBoss Admin이 관리하는 Class를 사용하도록 설정도 가능하다.

 

모듈 형식의 클래스 로더는 모든 Java 클래스를 모듈이라는 논리 그룹으로 나눈다. 각 모듈은 다른 모듈에 대한 의존성을 정의하여 해당 모듈의 클래스를 자체 Class-Path에 추가할 수 있다. 모듈 시스템은 JBoss EAP 6에 패키지 된 모든 Java 클래스와 deploy된 애플리케이션의 Java 클래스에 적용되며, 배포된 jar 및 war 파일은 모듈로 취급되기 때문에, 개발자는 모듈 구성을 애플리케이션에 추가하여 응용 프로그램의 Class-Path의 내용을 제어할 수 있다. 

 

 

2.1. JBoss Module과 MSC

JBoss EAP 6 에서는 JBoss MSC(Modular Service Container)가 적용되어 애플리케이션 서버의 Subsystem(EJB, 서블릿, JNDI 바인딩 등)의 각 모듈부터 사용자 애플리케이션까지 MSC 상에서 동작하는 모듈 서비스로 구성하고 있다.

 

'모듈 서비스'를 그냥 '서비스'라고도 부르는데, 이 모듈 서비스는 개별적으로 시작, 정지가 가능하기 때문이다. 

또한, 모듈 서비스 간에는 의존관계(dependencies)가 있어, 어느 모듈 서비스에서 필요한 다른 모듈 서비스로 의존성을 재정의할 수 있기 때문에, 다른 모듈 서비스를 주입하는 일도 가능하다. MSC에서는 사용하려는 모듈 서비스에 관한 모든 의존성이 충족되어야만 그 모듈 서비스를 시작한다. 의존성 중 단 1개라도 충족되지 않았을 경우, 해당 모듈 서비스를 정지한다.

 

아래 그림은 MSC의 코어 서비스와 그 구조를 나타낸다.

JBoss MSC 코어 서비스

• Service Builder(서비스 빌더) : Subsystem이 서비스를 설치하기 위해 필요한 처리를 하는 빌더(Builder) 기능을 제공
• Service Registry(서비스 레지스트리) : 서비스 빌더를 이용하여 서비스를 실행할 때, 레지스트리에 서비스명과 서비스 컨트롤러를 등록. MSC는 이 레지스트리를 참조하여 적합한 서비스 컨트롤러를 반환하여 서비스를 제어하게 됨.
• Service Controller(서비스 컨트롤러) : Subsystem이나 모듈 등이 서비스로서 실행될 수 있도록, 서비스 인터페이스(Interface)를 제공하거나 서비스에 대한 제어를 담당.
• Injector(인젝터) : 서비스 빌더가 서비스를 실행할 때, 서비스가 의존하는 모듈을 인젝션하게 되는데 이러한 인젝션 작업도 MSC의 인젝터가 수행해준다. 인젝션은 의존성(dependencies)가 정의되어 있어야 가능하다.
  참고로, 모든 서비스 인스턴스로의 접근은 'Value' 인터페이스에 의해 정의되고 있다.
• Concurrent Service Container : 모든 서비스를 제어하는, base가 되는 중요한 컴포넌트로, 서비스를 시작하기 위해 필요한 작업을 Task화하여, 해당 Task들을 멀티 스레드로 처리하게끔 한다.
  JBoss를 가동하는 데 필요한 bootstrap 처리 등도 Listener Task로 등록하여 처리한다.

 

2.2. 모듈(Module)

여기서 모듈은 클래스 로드 및 의존성 관리를 위해 사용되는 클래스들의 논리적 그룹을 일컫는다.

JBoss 에서의 모듈은 JBoss가 실행될 때 모든 모듈이 로드되는게 아닌, 해당 모듈이 필요할 때에만 로드가 된다.

일반적으로는, 해당 모듈이 명시적 또는 암시적 의존성으로서 포함되는 어플리케이션이 deploy 될 경우에만 실행된다고 보면 된다.

 

 

※ JBoss EAP 6 에서의 모듈(Module)에 대한 여러 정의

• 클래스를 Load할 때의 묶음 단위(논리적 그룹)
• Jar 파일로 된 하나의 패키지
• 여러 개의 jar 파일이나 Property 파일 등의 리소스를 포함하는 개념이기도 함
• 모듈 하나에 대해서는 하나의 클래스를 로드하며, 이때 각 모듈은 런타임에 필요한 의존 모듈을 정의해야 한다.

 

<정적 모듈(Static Module) 동적 모듈(Dinamic Module)의 차이점>

■ 정적 모듈(Static Module)

- 모듈 디렉토리에 모듈을 저장하여 deploy 하는 방식
- $JBOSS_HOME/modules/ 디렉토리에 모듈이 위치.

- 각 하위 디렉토리가 하나의 모듈을 의미하며, 해당 모듈을 실질적으로 동작시키는 jar 파일과 해당 모듈의 설정 파일인 modules.xml이 저장되어 있음.

- JBoss EAP 6 에서 제공하는 모든 API(Java EE API 및 JBoss Logging과 같은 JBoss 자체 API 등)는 모두 정적 모듈 방식으로 제공됨.

- 별도의 외부 라이브러리를 사용하기 위하여, 사용자가 직접 지정한 정적 모듈 역시 서버에 deploy 가능함.

 

정적 모듈 예시

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.0" name="com.mysql">
    <resources>
        <resource-root path="mysql-connector-java-5.1.15.jar" />
    </resources>
    
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>

 

■ 동적 모듈(Dinamic Module)

- JAR 또는 WAR(또는 EAR의 하위 배포) 형태로 Deploy시에 JBoss EAP 6 에 생성되어 Load 되는 방식

- 이때 동적 모듈의 이름은 배포된 파일(JAR, WAR, EAR)의 이름과 동일

- deploy 되는 애플리케이션도 다른 모듈과 마찬가지로 로드되기 때문에, 의존성을 설정할 수 있으며 다른 모듈을 참조하여 사용할 수도 있다.

 

2.3. 모듈 의존성

모듈 의존성(Dependency)란, 해당 모듈이 동작하기 위해 다른 모듈의 클래스가 필요한 경우, 이를 참조하기 위한 선언을 말한다. 명시적으로 다른 모듈의 종속성을 지정하지 않으면, 의존성은 전혀 없다.

JBoss EAP 6 에서 모듈을 로드할 때, 모듈 클래스 로더가 모듈의 의존성을 분석하고, 각 의존성 클래스를 class-path에 추가하는데, 이때 지정된 의존성 모듈이 존재하지 않으면 모듈을 로드할 수 없어 오류가 발생하게 된다.

 

의존성은 다음과 같이 두 가지 유형이 존재한다.

• 명시적 의존성
  - 정적 모듈 의존성은 modules.xml 파일에 선언
  - 동적 모듈 의존성은 deployment 파일의 MANIFEST.MF 또는 jboss-deployment-structure.xml 디스크립터에 선언
  - 선택적으로 지정할 수 있음. 즉, 의존성으로 선언한 모듈이 로드되지 않는다고 해서, 해당 모듈 로드를 실패하지는 않으나, 그 이후에 의존성을 정의하여도 해당 모듈이 class-path에 추가되지 않으므로, 모듈이 로드될 때 종속성 모듈(해당 모듈의 의존성으로 선언된 모듈)을 사용할 수 있어야 바람직함.
  
  
• 암시적 의존성
  - 특정 조건 또는 메타 데이터를 발견하면 JBoss EAP 6 가 자동으로 추가하는 방식
  - WEB-INF/lib 디렉토리에 필요한 JAR 파일을 넣는 방법을 일반적으로 사용
  - JBoss EAP 6 와 함께 제공되는 Java EE 6 API가 암시적 의존성의 대표적인 예시임.
  - jboss-deployment-structure.xml 디스크립터 파일에 <exclusions>를 사용하여 원치 않는 암시적 의존성을 제외할 수도 있음.

<모듈 의존성의 사용 예시>

모듈 A는 모듈 B에 의존(모듈 B를 참조해야만, 모듈 A가 실행 가능하다는 말.)

모듈 B는 모듈 C에 의존(모듈 C를 참조해야만, 모듈 B가 실행 가능하다는 말.)

의존성에 따르면, 모듈 A는 모듈 B의 클래스를, 모듈 B는 모듈 C의 클래스에 접근할 수 있다.

그러나, 별도의 설정 없이는 모듈 A가 모듈 C의 클래스에는 접근할 수 없는데, 이러한 경우 'export' 설정을 추가하여 모듈 A가 모듈 C의 클래스를 참조할 수 있는 방법이 있다.

# 모듈 A의 module.xml

<dependencies>
    <module name="B"/>
    <module name="C"/>		# 원래는 모듈 A가 모듈C에 대한 의존성은 없지만, export 옵션을 활용하기 위하여 모듈C에 대한 의존성을 추가함.
</dependencies>

# 모듈 B의 module.xml

<dependencies>
    <module name="C" export="true"/>	# export 옵션을 true로 설정하면, 타 모듈에서 모듈 B를 통해 모듈 C의 클래스를 참조할 수 있게 된다.
</dependencies>

---

3. 배포시 클래스 로딩

3.1. 배포시 클래스 로딩

클래스 로딩을 위해 JBoss EAP 에서 배포(Deployment)는 모두 모듈로 처리된다. 이러한 배포 형식의 모듈을 동적 모듈(Dinamic Module)이라고 하며, 이때 클래스 로딩의 작동 방식은 배포 유형에 따라 다르다.

 

<WAR 패키지 & EAR 패키지의 동작 방식>

■ WAR 패키지

- WAR 패키지가 하나의 모듈로 간주된다.

- WEB-INF/lib 디렉토리의 파일들은 WEB-INF/classes 디렉토리에 있는 클래스와 동일하게 처리된다.

- WAR로 패키징된 클래스들은 동일한 클래스 로더에 로드된다.

 

■ EAR 패키지

- EAR 배포는 여러 개의 모듈로 구성된다.

- EAR의 lib/ 디렉토리가 부모 모듈에 해당한다.

- EAR의 각 WAR 배포는 하나의 모듈을 의미하며, 마찬가지로 EAR 내의 EJB JAR 배포도 하나의 모듈을 의미한다.

- EAR의 WAR 및 JAR 배포와 같은 서브 배포 모듈은 자동으로 부모 모듈에 의존하지만, 하위 배포까지 자동으로 의존성을 갖지는 않는다. (하위 배포 단절, Subdeployment Isolation)

- 서브 배포 모듈 간의 명시적 종속 관계는 여느 다른 모듈들과 같은 방법으로 추가할 수 있다.

 

3.2. 클래스 로딩의 우선 순위

JBoss EAP 6 모듈 클래스 로더는 우선 순위 구조를 이용하여 클래스 로딩 충돌이 발생하지 않도록 한다.

배포 시 패키지와 클래스들의 리스트는 각각의 배포와 해당 종속성에 의해 생성되는데, 이 리스트는 클래스 로딩의 우선 순위 규칙에 따라 순서대로 나열된다. 런타임 중 클래스를 로드하면 클래스 로더는 이 리스트를 검색하여 최초로 일치하는 것을 로드하게 된다. 이렇게 하면 배포 클래스 경로에 동일한 클래스나 패키지의 여러 복사본들이 서로 충돌하지 않게 된다.

 

<클래스 로딩의 우선 순위>

1. 암시적 의존성
   - Java EE API들은 JBoss EAP 6 가 자동으로 추가한 의존성.
   - Java 기반에서의 일반적인 기능 및 JBoss EAP 6 의 API 가 포함되어 있기 때문에 우선순위가 가장 높음.
   
   
2. 명시적 의존성
   - 애플리케이션 설정에서 수동으로 추가되는 의존성
   - 애플리케이션의 MANIFEST.MF 파일 또는 새로운 옵션으로 추가된 JBoss-deployment-structure.xml 파일을 사용하여 추가 가능.
   
   
3. 로컬 리소스
   - 배포 애플리케이션 내에 패키징된 클래스 파일
   - 예시로, WAR 파일 안의 WEB-INF/classes 또는 WEB-INF/lib 디렉토리의 JAR 파일들을 말함.
   
   
4. 배포 간의 의존성
   - EAR 배포 애플리케이션에 있는 다른 배포와의 의존성
   - EAR의 lib 디렉토리에 있는 클래스 또는 다른 EJB JAR에 정의된 클래스들을 말함.

 

3.3. EAR 배포와 클래스 로딩

엔터프라이즈 아카이브(EAR)는 JAR 또는 WAR 배포와 같이 단일 모듈로 로드하지 않고, 독립적인 여러 모듈로 로드한다.

 

<EAR에 존재하는 '모듈'을 결정하는 규칙>

- 각 WAR 및 EJB JAR subdeployments 들이 모듈에 해당한다.

- EAR 아카이브 루트에 있는 lib/ 디렉토리의 내용이 모듈에 해당하며, 이것들을 부모 모듈이라고 한다.

- 위에서 정의한 모듈들은 다음과 같이 추가 암시적 종속성이 있는 다른 모듈과 동일한 동작을 한다.

- WAR의 subdeployments는 상위 모듈 및 EJB JAR 파일의 subdeployments에 대해 암시적 종속성이 있다.

- EJB JAR의 subdeployments는 상위 모듈과 다른 EJB JAR 파일의 subdeployments에 대해 암시적 종속성이 있다.

 

<subdeployment의 명시적 종속 관계 설정 방법>

위에서 설명한 암시적 종속성은 JBoss EAP 6 에서 기본적으로 subdeployment 클래스 로더 격리가 비활성화 되어 있기 때문에 발생한다. 이는 EAR에 있는 WAR와 EJB JAR 들은 별도의 설정 없이 서로 참조가 가능하다는 말이다.

만일 JBoss EAP 6의 기본값과는 별개로, 엄격한 호환성이 필요하다면(암시적 종속성이 아닌 명시적 종속성을 사용해야 한다면) 아래와 같이 subdeployment 클래스 로더 격리(isolation)을 활성화 할 수 있다.

<subsystem xmlns="urn:jboss:domain:ee:1.1">

    # true : 격리를 활성화-> 명시적 종속성(엄격한 호환성 관리를 하겠다.) / false(기본값) : 격리를 비활성화 -> 암시적 종속성 허용
    <ear-subdeployment-isolated>true</ear-subdeployment-isolated>  
</subsystem>

 

참고로 Jave EE 스펙에서는 서로 참조하지 못하도록 규정하고 있다.(즉, 명시적 종속성을 사용할 것을 권장한다는 의미.) Java EE 6 표준에서는 포터블 애플리케이션의 종속성을 명시적으로 각 subdeployment의 MANIFEST.MF 파일에서 class-path 로 선언하지 않는 한, 서로 액세스할 수 있는 subdeployments에 의존하지 않도록 권장하고 있다.

 

 

3.4. 동적 모듈의 모듈 이름(name 속성)

■ WAR 패키지의 모듈 이름 지정

deployment.{DEPLOYMENT_NAME}

ex) inventory.war 와 store.jar 라는 이름으로 deploy하게 되면,

이 모듈을 참조하려면 deployment.inventory.war, deployment.store.jar 로 참조해야 한다.

 

■ EAR 패키지의 모듈 이름 지정

deployment.{EAR_NAME}.{SUBDEPLOYMENT_NAME}

ex) accounts.ear 에 있는 reports.war 라는 subdeployment 가 있다면,

이 모듈을 참조하려면 deployment.accounts.ear.reports.war 로 참조해야 한다.

 

3.5. jboss-deployment-structure.xml 파일

jboss-deployment-structure.xml은 JBoss EAP 6 를 위한 새로운 optional deployment 디스크립터이다.

이 디스크립터는 애플리케이션 배포 시, 클래스 로딩을 제어할 수 있도록 한다. 

위 디스크립터의 XML 스키마는 $JBOSS_HOME/docs/schema/jboss-deployment-structure-1_0.xsd 에 있다.

 

 

4. 동적 모듈(배포 모듈)에 명시적 의존성 추가하기

다이내믹 모듈은 Deployment 속의 MANIFEST.MF 또는 jboss-deployment-structure.xml 디스크립터에 의존성을 선언할 수 있다. 명시적인 모듈 의존성을 애플리케이션에 추가하면 이 모듈의 클래스를 애플리케이션의 class-path에 추가할 수 있게 된다.

 

4.1. MANIFEST.MF 의존성 추가 방법

① MANIFEST.MF 파일 추가

프로젝트에 MANIFEST.MF 파일이 없다면 MANIFEST.MF 라는 파일을 우선 만들어야 한다. WAR에서는 이 파일을 WEB-INF 디렉토리에 추가하며, JAR에서는 META-INF 디렉토리에 추가하면 된다.

 

② 의존성 항목 추가

의존성 모듈(dependency) 이름을 쉼표로 구분하여 의존성 항목을 MANIFEST.MF 파일에 추가한다.

Dependencies : org.javasist, org.apache.velocity

 

이때 'optional' 이라는 키워드를 넣으면 해당 의존성 모듈을 선택적으로 지정할 수 있다.

Dependencies : org.javasist optional, org.apache.velocity

 

'export' 라는 키워드를 넣으면 해당 의존성 모듈을 다른 모듈에서도 참조할 수 있게끔 한다.

Dependencies : org.javasist, org.apache.velocity export

 

4.2. jboss-deployment-structure.xml 의존성 추가 방법

jboss-deployment-structure.xml 배포 디스크립터는 클래스 로딩을 제어할 수 있는 새로운 형태의 디스크립터로, 배포 어플리케이션의 META-INF/ 디렉토리 또는 WEB-INF/ 디렉토리에 위치하면 된다.

암시적 의존성 모듈이 추가되지 않도록 하는 기능, 추가되지 않은 의존성을 추가하는 기능, 추가 모듈의 정의, EAR의 클래스 로딩 동작 변경, 모듈에 리소스 경로를 추가하는 기능 등의 다양한 기능을 제어할 수 있다.

 

배포 디스크립터 파일의 의존성을 추가하면 JBoss EAP 6 에서 애플리케이션 배포 시, 지정된 모듈의 JAR 파일들을 애플리케이션의 class-path에 클래스로 추가하게 된다. 

 

① jboss-deployment-structure.xml 파일 추가

애플리케이션 deployment 파일에 jboss-deployment-structure.xml 이라는 새 파일을 만들어 프로젝트에 추가한다. 

# <jboss-deployment-structure>가 루트인 XML 파일

<jboss-deployment-structure>

</jboss-deployment-structure>

웹 어플리케이션(WAR)에서는 이 파일을 WEB-INF/ 디렉토리에 위치시키고, EJB 아카이브(JAR)는 META-INF/ 디렉토리에 위치시키면 된다.

 

② 의존성 섹션 추가

<deployment> 를 문서 루트에 생성하고, 그 안에 <dependencies> 앨리먼트를 만들어 준다.

 

③ 모듈 요소 추가

<dependencies> 앨리먼트 하위에 각 모듈 의존성에 대한 <module> 앨리먼트를 name 속성과 함께 추가한다.

이때 optional 이라는 속성을 추가하면, 해당 의존성을 옵션으로 지정할 수 있다.

또한 export 속성을 추가하면, 해당 의존성을 가지는 모듈이 다른 모듈에서 참조될 경우, export 된 모듈도 로드할 수 있게 된다.

 

 

다음은 위의 설명을 바탕으로 완성된 jboss-deployment-structure.xml 파일이다.

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
    <deployment>
        <dependencies>
            <module name="org.javassist" />
            <module name="org.apache.velocity" optional="TRUE" export="TRUE" />
        </dependencies>
    </deployment>
</jboss-deployment-structure>

 

4.3. 모듈이 암시적으로 로드되지 않도록 설정

배포 가능한 애플리케이션을 설정하여 암시적 의존성을 로드되지 않도록 설정할 수 있는데, JBoss EAP 6 에서 제공되는 이러한 기능은 일반적으로 애플리케이션이 다른 버전의 라이브러리를 사용하거나 별도의 프레임워크가 애플리케이션에 포함되는 경우 사용하게 된다.

 

방법은 간단하다. jboss-deployment-structure.xml 파일에 <exclusions> 라는 앨리먼트를 추가하면 된다.

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
    <deployment>
        <exclusions>
            <module name-"org.javassist"/>
            <module name="org.apache.velocity" export="TRUE" />
        </exclusions>
    </deployment>
</jboss-deployment-structure>

 

4.4. Deploy 시 subsystem을 제외하도록 설정

Deploy시 subsystem을 제외시키기 위해서는, 이 역시 jboss-deployment-structure.xml 설정파일을 편집해야 한다. 서브시스템을 제외하는 것은 서브시스템을 제거하는 것과 같은 효과가 있지만, 하나의 deployment 파일에만 적용된다는 점이 삭제 방법과 다른 점이다.

 

① jboss-deployment-structure.xml 파일 편집

vim으로 jboss-deployment-structure.xml 파일을 연다.

 

② <exclude-subsystems> 앨리먼트 작성

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
    <deployment>
        <exclude-subsystems>
            <subsystem name="SUBSYSTEM_NAME" />
        </exclude-subsystems>
    </deployment>
</jboss-deployment-structure>

 

 

5. 모듈 서비스의 로드 방법

JBoss MSC(Moduler Service Container) 에서는 의존관계(dependencies)가 있는 모듈 서비스 로드에 Concurrent DAG(Directed Acyclic Graph) Execution 이라는 방식을 도입하여 기존의 로드 방법(Serial DAG Execution)보다 빠르게 로드하는 것이 가능하게 되었다.

 

아래 그림과 같은 의존관계를 가진 모듈들에 대해 살펴보자.

모듈 의존관계(dependencies) 예시

기존의 Serial DAG Execution 방식과 같은 단일 CPU 사용 방식은 아래 그림처럼 각 모듈을 차례로 로드했었다.

Serial DAG Execution 방식

 

최근에는 CPU가 멀티코어가 일반적이므로, 단일의 CPU 코어로 처리하는 방식은 효율적인 방식이 아니다.

이러한 점 때문에 JBoss EAP 6 에서는 다음 그리과 같이 Concurrent DAG Execution 방식을 사용한다. 이는 병렬로 모듈들을 로드하여 CPU의 코어를 효율적으로 활용하여 딜레이를 단축시킨다.

Concurrent DAG Execution 방식

 

6. JBoss EAP의 부트

JBoss EAP 6의 bootstrap은 서비스 컨트롤러에 의해 서버 서비스의 부팅을 처리하는 일을 시작한다. 

부팅 시 설정 파일(standalone.xml 등)을 읽어서 사용할 operation을 작성하고, 필요한 처리를 각각 step으로 등록하여 Multi-Thread로 처리하게 된다. 서브시스템을 시작하는 경우에는, parallel-subsystem-boot 오퍼레이션을 작성하여 Multi-Process로 서브시스템을 시작하게 된다.

 

JBoss EAP 6의 부트 순서는 extension, subsystem, deployment 순으로 실행된다.

 

아래 그림은 extension 모듈의 로드 절차를 보여준다.

JBoss EAP 6 부트시 extension 모듈 로드 절차

JBoss EAP 6 부팅 과정에서 extension 모듈 초기화 과정을 살펴보면,

먼저 standalone.xml 파일을 파싱하여 <extension> 모듈의 이름들을 찾는다.

 

이후 extension 모듈들을 $JBOSS_HOME/modules 디렉토리에서 모듈 이름에 해당하는 모듈을 로딩하는데, 이 모듈들은 org.jboss.as.controller.Extension를 구현할 클래스들에 해당된다.

 

이 Extension 모듈은 어떤 XML 네임스페이스를 사용할 것인지 구현하고 있어, 해당하는 XML 스키마를 읽어 MSC(Modular Service Container)에서 weld 서브시스템을 시작한다.  

 

이렇게 standalone.xml 파일에 정의된 서브시스템들이 모두 시작되면, 메인 애플리케이션의 deployment를 수행한다.

---

참고

https://chanchan-father.tistory.com/676?category=843153 

JBoss EAP 6과 친해지기 9탄 - JBoss EAP 6 모듈 아키텍처

https://access.redhat.com/documentation/ko-kr/jboss_enterprise_application_platform/6.3/html/development_guide/chap-class_loading_and_modules

Chapter 3. Class Loading and Modules JBoss Enterprise Application Platform 6.3 | Red Hat Customer Portal