Jakarta Enterprise Beans는 Enterprise Beans라는 서버 측 구성 요소를 사용하여 분산, 트랜잭션, 보안 및 이식 가능한 자카르타 EE 애플리케이션을 개발하기 위한 API입니다. Enterprise Beans는 애플리케이션의 비즈니스 로직을 분리된 방식으로 구현하여 재사용을 촉진합니다. Jakarta Enterprise Beans은 Jakarta Enterprise Beans 3.2 사양에 설명되어 있습니다.

JBoss EAP 7.3 이상 버전은 다음과 같은 Jakarta Enterprise Beans 3.2 기능을 지원합니다.

다음 기능은 JBoss EAP 7에서 더 이상 지원하지 않습니다.

엔터프라이즈 빈은 Java 클래스로 작성되며 적절한 Jakarta Enterprise Beans 주석을 사용하여 주석을 달 수 있습니다. 자체 아카이브( JAR 파일)에서 애플리케이션 서버에 배포하거나 Jakarta EE 애플리케이션의 일부로 배포할 수 있습니다. 애플리케이션 서버는 각 엔터프라이즈 빈의 라이프사이클을 관리하고 보안, 트랜잭션, 동시성 관리 등의 서비스를 제공합니다.

엔터프라이즈 빈은 다양한 비즈니스 인터페이스를 정의할 수도 있습니다. 비즈니스 인터페이스는 클라이언트가 사용할 수 있는 빈 메서드 중 어떤 것을 보다 잘 제어할 수 있으며 원격 JVM에서 실행되는 클라이언트에 대한 액세스를 허용할 수도 있습니다.

엔터프라이즈 빈에는 세션 빈,메시지 기반 빈, 엔터티 빈의 세 가지 유형이 있습니다.

Jakarta Enterprise Beans 비즈니스 인터페이스는 클라이언트가 사용할 수 있는 세션 빈의 공용 메서드를 선언하는 빈 개발자가 작성한 Java 인터페이스입니다. 세션 빈은 none( 인터페이스 빈 없음 )을 포함하여 원하는 수의 인터페이스를 구현할 수 있습니다.

비즈니스 인터페이스는 로컬 또는 원격 인터페이스로 선언할 수 있지만 둘 다 사용할 수는 없습니다.

자카르타 엔터프라이즈 빈 로컬 비즈니스 인터페이스

Jakarta Enterprise Beans 로컬 비즈니스 인터페이스는 빈과 클라이언트가 동일한 JVM에 있을 때 사용 가능한 메서드를 선언합니다. 세션 빈에서 로컬 비즈니스 인터페이스를 구현하는 경우 해당 인터페이스에 선언된 메서드만 클라이언트에 사용할 수 있습니다.

자카르타 엔터프라이즈 빈 원격 비즈니스 인터페이스

Jakarta Enterprise Beans 원격 비즈니스 인터페이스는 원격 클라이언트에서 사용할 수 있는 방법을 선언합니다. 원격 인터페이스를 구현하는 세션 빈에 대한 원격 액세스는 Jakarta Enterprise Beans 컨테이너에서 자동으로 제공합니다.

원격 클라이언트는 다른 JVM에서 실행되는 모든 클라이언트이며 데스크탑 애플리케이션과 다른 애플리케이션, 서비스 및 엔터프라이즈 빈을 다른 애플리케이션 서버에 배포할 수 있습니다.

로컬 클라이언트는 원격 비즈니스 인터페이스에서 노출하는 메서드에 액세스할 수 있습니다.

Jakarta Enterprise Bean No-interface Bean

비즈니스 인터페이스를 구현하지 않는 세션 빈을 no-interface 빈이라고 합니다. 인터페이스 없는 빈의 모든 공용 메서드는 로컬 클라이언트가 액세스할 수 있습니다.

비즈니스 인터페이스를 구현하는 세션 빈도 비인터페이스 보기를 노출하도록 작성할 수 있습니다.

JBoss EAP는 원격 Jakarta Enterprise Beans 구성 요소를 호출하는 기본 API로 Jakarta Enterprise Beans 클라이언트 라이브러리를 제공합니다.

JBoss EAP 7.1부터 Enterprise Beans 클라이언트 두 개가 제공됩니다.

구성에 다음 Maven 종속성을 포함하여 레거시 EJB 클라이언트 호환성을 사용할 수 있습니다.

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.jboss.eap</groupId>
            <artifactId>wildfly-ejb-client-legacy-bom</artifactId>
            <version>EAP_BOM_VERSION</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>
<dependencies>
    <dependency>
        <groupId>org.jboss</groupId>
        <artifactId>jboss-ejb-client-legacy</artifactId>
    </dependency>
</dependencies>

JBoss EAP Maven 리포지토리에서 사용할 수 있는 EAP_BOM_VERSION 을 사용해야 합니다.

이 작업은 Red Hat CodeReady Studio에서 Jakarta Enterprise Beans 프로젝트를 생성하는 방법을 설명합니다.

사전 요구 사항

Red Hat CodeReady Studio에서 Jakarta Enterprise Beans Project 만들기

이제 지정된 서버에 빌드 및 배포할 수 있는 Red Hat CodeReady Studio에 Jakarta Enterprise Beans 프로젝트가 있습니다.

이 작업은 JAR 파일에 패키징된 하나 이상의 엔터프라이즈 빈을 포함하는 Maven을 사용하여 프로젝트를 생성하는 방법을 보여줍니다.

사전 요구 사항

Maven에서 Jakarta Enterprise Beans Archive Project 만들기

이제 JAR 파일을 빌드하고 패키징하는 Maven 프로젝트가 있습니다. 이 프로젝트에는 엔터프라이즈 빈이 포함될 수 있으며 JAR 파일을 애플리케이션 서버에 배포할 수 있습니다.

이 작업은 Jakarta Enterprise Beans 프로젝트가 포함된 Red Hat CodeReady Studio에서 새 EAR(Enterprise Archive) 프로젝트를 생성하는 방법을 설명합니다.

사전 요구 사항

Jakarta Enterprise Beans 프로젝트가 포함된 EAR 프로젝트 만들기

그림 2.5. 대화 상자 추가 및 제거

이제 회원 Jakarta Enterprise Beans Project가 포함된 Enterprise Application Project를 갖게 되었습니다. 그러면 Jakarta Enterprise Beans 하위 배포가 포함된 단일 EAR 배포로 지정된 서버에 빌드 및 배포됩니다.

Jakarta Enterprise Beans 배포 설명자를 사용하지 않고 만든 Jakarta Enterprise Beans 프로젝트에 추가할 수 있습니다. 이 작업을 수행하려면 아래 절차를 따르십시오.

사전 요구 사항

Jakarta Enterprise Beans 프로젝트에 배포 설명자 추가

성능 모니터링을 위해 빈에 런타임 배포 정보를 추가할 수 있습니다.

사용 가능한 런타임 데이터에 대한 자세한 내용은 JBoss EAP 관리 모델의 tekton 3 하위 시스템을 참조하십시오. 애플리케이션에는 빈 코드의 주석 또는 배포 설명자에 런타임 데이터가 포함될 수 있습니다. 애플리케이션은 두 옵션을 모두 사용할 수 있습니다.

세션 빈은 관련 비즈니스 프로세스 또는 작업 집합을 캡슐화하고 요청하는 클래스에 주입되는 엔터프라이즈 빈입니다. 세션 빈에는 상태 비저장, 상태 저장 및 Singleton의 세 가지 유형이 있습니다.

상태 비저장 세션 빈은 가장 단순하지만 가장 널리 사용되는 세션 빈 유형입니다. 클라이언트 애플리케이션에 비즈니스 메서드를 제공하지만 메서드 호출 간에 상태를 유지하지는 않습니다. 각 메서드는 해당 세션 빈 내의 공유 상태를 사용하지 않는 전체 작업입니다. 상태가 없기 때문에 각 메서드 호출이 동일한 인스턴스에서 수행되는지 확인하는 데 애플리케이션 서버가 필요하지 않습니다. 이를 통해 상태 비저장 세션 빈을 매우 효율적이고 확장할 수 있습니다.

상태 저장 세션 빈은 클라이언트 애플리케이션에 비즈니스 방법을 제공하고 클라이언트와의 대화 상태를 유지하는 엔터프라이즈 빈입니다. 유지 관리 중인 이전 단계의 상태에 의존하는 여러 단계에서 수행해야 하는 작업 또는 메서드 호출에 사용해야 합니다. 애플리케이션 서버를 사용하면 각 클라이언트에 각 메서드 호출에 대해 동일한 상태 저장 세션 빈 인스턴스가 수신됩니다.

Singleton 세션 빈은 애플리케이션당 한 번씩 인스턴스화되는 세션 빈이며 Singleton 빈에 대한 모든 클라이언트 요청은 동일한 인스턴스로 이동합니다. Singleton 빈은 책에 설명된 대로 Singleton 디자인 패턴 구현입니다. 설계 패턴 : 재사용 가능한 객체 지향 소프트웨어의 요소 Erich Gamma, Richard Helm, Ralph Johnson 및 John Vlissides; Addison-Wesley가 2005년 게시했습니다.

Singleton 빈은 모든 세션 빈 유형의 최소 메모리 풋프린트를 제공하지만 스레드 보안으로 설계해야 합니다. Jakarta Enterprise Beans 3.2는 개발자가 스레드 안전한 Singleton 빈을 쉽게 구현할 수 있도록 CMC(컨테이너 관리 동시성)를 제공합니다. 그러나 CMC가 충분한 유연성을 제공하지 않는 경우 기존 멀티 스레드 코드(빈 관리 동시성 또는 BMC)를 사용하여 Singleton 빈을 작성할 수도 있습니다.

Red Hat CodeReady Studio에는 엔터프라이즈 빈 클래스를 빠르게 만드는 데 사용할 수 있는 몇 가지 마법사가 있습니다. 다음 절차에서는 Red Hat CodeReady Studio 마법사를 사용하여 세션 빈을 프로젝트에 추가하는 방법을 보여줍니다.

사전 요구 사항

Red Hat CodeReady Studio의 프로젝트에 세션 빈 추가

MDB(Message-driven Bean)는 애플리케이션 개발을 위한 이벤트 중심 모델을 제공합니다. MDB 메서드는 클라이언트 코드에 삽입되거나 클라이언트 코드에서 호출되지 않지만 자카르타 메시징 서버와 같은 메시징 서비스에서 메시지 수신에 의해 트리거됩니다. 자카르타 EE 사양에서는 자카르타 메시징이 지원되어야 하지만 다른 메시징 시스템도 지원할 수 있습니다.

MDB는 특별한 종류의 상태 비저장 세션 빈입니다. onMessage(Message message) 라는 메서드를 구현합니다. 이 메서드는 MDB가 수신 대기 중인 Jakarta Messaging 대상에서 메시지를 수신할 때 트리거됩니다. 즉, MDB는 Jakarta Enterprise Beans 클라이언트가 일반적으로 메서드를 호출하는 상태 비저장 세션 빈과 달리 Jakarta Messaging 공급자의 메시지를 수신하여 트리거됩니다.

MDB는 메시지를 비동기적으로 처리합니다. 기본적으로 각 MDB에는 각 세션이 메시지를 처리하는 최대 16개의 세션이 있을 수 있습니다. 주문 보장 메시지는 없습니다. 메시지 순서를 지정하려면 MDB의 세션 풀을 1 로 제한해야 합니다.

/subsystem=ejb3/strict-max-bean-instance-pool=mdb-strict-max-pool:write-attribute(name=derive-size,value=undefined)

/subsystem=ejb3/strict-max-bean-instance-pool=mdb-strict-max-pool:write-attribute(name=max-pool-size,value=1)

reload

JBoss EAP는 특정 MDB에서 메시지의 활성 수신을 제어하는 세 가지 특성을 제공합니다.

<?xml version="1.1" encoding="UTF-8"?>
<jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
    xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:d="urn:delivery-active:1.1"
    xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd"
    version="3.1"
    impl-version="2.0">
    <assembly-descriptor>
        <d:delivery>
            <ejb-name>HelloWorldQueueMDB</ejb-name>
            <d:active>false</d:active>
        </d:delivery>
    </assembly-descriptor>
</jboss:ejb-jar>

@MessageDriven(name = "HelloWorldMDB", activationConfig = {
 @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
 @ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/HELLOWORLDMDBQueue"),
 @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge") })
@DeliveryActive(false)

public class HelloWorldMDB implements MessageListener {
    public void onMessage(Message rcvMessage) {
      // ...
    }
}

<dependency>
    <groupId>org.jboss.ejb3</groupId>
    <artifactId>jboss-ejb3-ext-api</artifactId>
    <version>2.2.0.Final</version>
</dependency>

<delivery>
  <ejb-name>MdbName<ejb-name>
  <delivery-group>passive</delivery-group>
</delivery>

<delivery-groups>
  <delivery-group name="group" active="true"/>
</delivery-groups>

/subsystem=ejb3/mdb-delivery-group=group:add
/subsystem=ejb3/mdb-delivery-group=group:remove
/subsystem=ejb3/mdb-delivery-group=group:write-attribute(name=active,value=true)

@MessageDriven(name = "HelloWorldQueueMDB", activationConfig = {
        @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
        @ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/HELLOWORLDMDBQueue"),
        @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge") })
@DeliveryGroup("delivery-group-1")
@DeliveryGroup("delivery-group-2")
public class HelloWorldQueueMDB implements MessageListener {
...
}

<c:clustering>
    <ejb-name>*</ejb-name>
    <c:clustered-singleton>true</c:clustered-singleton>
</c:clustering>

<d:delivery>
    <ejb-name>HelloWorldTopicMDB</ejb-name>
    <d:group>my-mdb-delivery-group</d:group>
</d:delivery>

다음 절차에서는 Red Hat CodeReady Studio의 프로젝트에 Jakarta Messaging 기반 메시지 기반 빈을 추가하는 방법을 설명합니다. 이 절차에서는 주석을 사용하는 Jakarta Enterprise Beans 3.x 메시지 기반 빈을 생성합니다.

사전 요구 사항

Red Hat CodeReady Studio에서 Jakarta Messaging 기반 Bean 추가

jboss-ejb3.xml 배포 설명자에서 사용할 MDB의 리소스 어댑터를 지정할 수 있습니다.

MDB에 jboss-ejb3.xml 에 리소스 어댑터를 지정하려면 다음 예제를 사용합니다.

<jboss xmlns="http://www.jboss.com/xml/ns/javaee"
  xmlns:jee="http://java.sun.com/xml/ns/javaee"
  xmlns:mdb="urn:resource-adapter-binding">
  <jee:assembly-descriptor>
    <mdb:resource-adapter-binding>
      <jee:ejb-name>MyMDB</jee:ejb-name>
      <mdb:resource-adapter-name>MyResourceAdapter.rar</mdb:resource-adapter-name>
    </mdb:resource-adapter-binding>
  </jee:assembly-descriptor>
</jboss>

EAR에 있는 리소스 어댑터의 경우 <mdb:resource-adapter-name> 에 대해 다음 구문을 사용해야 합니다.

@JMSConnectionFactoryDefinition 및 @JMSDestinationDefinition 주석을 사용하여 메시지 기반 빈에 대한 연결 팩토리 및 대상을 생성하는 경우 오브젝트는 MDB가 배포된 서버에서만 생성됩니다. MDB를 클러스터의 모든 노드에도 배포하지 않는 한 클러스터의 모든 노드에서 생성되지 않습니다. 이러한 주석으로 구성된 개체는 MDB가 배포된 서버에서만 생성되므로 MDB에서 원격 서버에서 메시지를 읽고 원격 서버로 전송하는 원격 Jakarta Connectors 토폴로지에 영향을 미칩니다.

Red Hat JBoss Enterprise Application Platform을 사용하면 @ActivationConfigProperty 및 @ Resource 주석을 사용하여 Jakarta Enterprise Beans 및 MDB에서 속성 대체를 활성화할 수 있습니다. 속성 대체에는 다음과 같은 구성 및 코드 변경이 필요합니다.

다음 예제에서는 속성 대체를 사용하기 위해 JBoss EAP와 함께 제공되는 helloworld-mdb 빠른 시작을 수정하는 방법을 보여줍니다. 완료된 작업 예는 helloworld-mdb-propertysubstitution 빠른 시작을 참조하십시오.

$ EAP_HOME/bin/standalone.sh -c standalone-full.xml  -Dproperty.helloworldmdb.queue=java:/queue/HELLOWORLDMDBPropQueue  -Dproperty.helloworldmdb.topic=java:/topic/HELLOWORLDMDBPropTopic  -Dproperty.connection.factory=java:/ConnectionFactory

JBoss EAP는 원격 Jakarta Enterprise Beans 호출을 관리하기 위한 Jakarta Enterprise Beans 클라이언트 API를 도입했습니다. JBoss Jakarta Enterprise Beans 클라이언트 API는 하나 이상의 스레드에서 동시에 연결 및 사용할 수 있는 EJBClientContext를 사용합니다. 즉 EJBClientContext에는 다수의 Jakarta Enterprise Beans 수신자가 포함될 수 있습니다. Jakarta Enterprise Beans 수신자는 Jakarta Enterprise Beans 호출을 처리할 수 있는 서버와 통신하는 방법을 아는 구성 요소입니다. 일반적으로 Jakarta Enterprise Bean 원격 애플리케이션은 다음과 같이 분류할 수 있습니다.

원격 클라이언트 유형에 따라 Jakarta Enterprise Beans 클라이언트 API 관점에서 JVM 내에 둘 이상의 EJBClientContext가 있을 수 있습니다.

독립 실행형 애플리케이션에는 일반적으로 다수의 Jakarta Enterprise Beans 수신자가 지원할 수 있는 단일 EJBClientContext가 있지만 필수는 아닙니다. 독립 실행형 애플리케이션에 EJBClientContext가 두 개 이상 있는 경우 Jakarta Enterprise Beans 클라이언트 컨텍스트 선택기가 적절한 컨텍스트를 반환합니다.

다른 JBoss EAP 인스턴스 내에서 실행되는 원격 클라이언트의 경우 배포된 각 애플리케이션에 해당하는 Jakarta Enterprise Beans 클라이언트 컨텍스트가 있습니다. 해당 애플리케이션이 다른 Jakarta Enterprise Beans를 호출할 때마다 해당 Jakarta Enterprise Beans 클라이언트 컨텍스트를 사용하여 올바른 Jakarta Enterprise Beans 수신자를 찾아 호출을 처리합니다.

Enterprise Beans 프로토콜 메시지가 포함된 메시지 스트림을 압축할 수 있습니다.

데이터 압축 힌트는 JBoss 주석 org.jboss.ejb.client.annotation.CompressionHint 를 통해 지정할 수 있습니다. 힌트 값은 요청, 응답 또는 요청 및 응답을 압축할지 여부를 지정합니다. @CompressionHint 를 추가하는 기본값은 compressResponse=true 및 compressRequest=true 입니다.

인터페이스 수준에서 주석을 지정하여 다음과 같은 Jakarta Enterprise Beans 인터페이스의 모든 메서드에 적용할 수 있습니다.

import org.jboss.ejb.client.annotation.CompressionHint;

@CompressionHint(compressResponse = false)
public interface ClassLevelRequestCompressionRemoteView {
    String echo(String msg);
}

또는 주석은 다음과 같은 Jakarta Enterprise Beans 인터페이스의 특정 메서드에 적용할 수 있습니다.

import org.jboss.ejb.client.annotation.CompressionHint;

public interface CompressableDataRemoteView {

    @CompressionHint(compressResponse = false, compressionLevel = Deflater.BEST_COMPRESSION)
    String echoWithRequestCompress(String msg);

    @CompressionHint(compressRequest = false)
    String echoWithResponseCompress(String msg);

    @CompressionHint
    String echoWithRequestAndResponseCompress(String msg);

    String echoWithNoCompress(String msg);
}

위에 표시된 compressedLevel 설정은 다음과 같은 값을 가질 수 있습니다.

compressionLevel 설정은 기본적으로 Deflater.DEFAULT_COMPRESSION 입니다.

메서드 수준 덮어쓰기가 있는 클래스 수준 주석은 다음과 같습니다.

@CompressionHint
public interface MethodOverrideDataCompressionRemoteView {

    @CompressionHint(compressRequest = false)
    String echoWithResponseCompress(final String msg);

    @CompressionHint(compressResponse = false)
    String echoWithRequestCompress(final String msg);

    String echoWithNoExplicitDataCompressionHintOnMethod(String msg);
}

클라이언트 측에서 org.jboss.ejb.client.view.annotation.scan.enabled 시스템 속성이 true 로 설정되어 있는지 확인합니다. 이 속성은 JBoss Jakarta Enterprise Beans Client에 주석을 스캔하도록 지시합니다.

원격 Jakarta Enterprise Cryostats 클라이언트 애플리케이션은 서버에 연결하기 위해 원격 하위 시스템에 정의된 커넥터를 사용합니다. 요구 사항에 따라 다음 커넥터 중 하나를 사용할 수 있습니다.

기본 HTTP 커넥터

기본 커넥터는 http-connector 로, 클라이언트가 URI 스키마 remote+http 또는 remote+https 를 사용해야 합니다. 기본 원격 연결 포트는 8080 입니다. 이 포트는 undertow 의 기본 포트와 동일합니다. 다음 예제에서는 jboss- Cryostat-client 속성 파일을 보여줍니다.

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost
remote.connection.default.port=8080
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

다른 JBoss EAP 버전의 클라이언트 지원

클라이언트 애플리케이션이 JBoss EAP 6의 Jakarta Enterprise Cryostats 클라이언트 라이브러리를 사용하고 JBoss EAP 7 서버에 대한 연결이 필요한 경우 8080 이외의 포트에 원격 커넥터를 노출하도록 서버를 구성해야 합니다. 그런 다음 클라이언트는 새로 구성된 커넥터를 사용하여 연결해야 합니다.

JBoss EAP 7의 Jakarta Enterprise Cryostats 클라이언트 라이브러리를 사용하고 JBoss EAP 6 서버에 연결해야 하는 클라이언트 애플리케이션은 서버 인스턴스에서 remoting http-remoting 커넥터를 사용하지 않고 리모팅 커넥터를 사용해야 합니다. 이를 위해 다음과 같은 새 클라이언트 측 연결 속성을 정의합니다.

remote.connection.default.protocol=remote

자카르타 Enterprise Cryostats 클라이언트 애플리케이션에 대한 여러 커넥터 지원

JBoss EAP 7.4 이전에는 Jakarta Enterprise Cryostats 클라이언트 애플리케이션이 리모팅 하위 시스템에 정의된 하나의 리모팅 커넥터만 사용하여 서버에 연결할 수 있도록 제한되었습니다. 이 커넥터는 Cryostat 3 하위 시스템의 원격 요소의 connector-ref 특성에 지정되었습니다. 기본 http-connector 를 사용하여 undertow 의 HTTP 업그레이드 기능을 통해 remote+http 프로토콜을 사용하거나 기존 원격 프로토콜을 통해 연결을 제공하기 위해 레거시 커넥터 를 사용할 수 있습니다.

JBoss EAP 7.4를 사용하면 Jakarta Enterprise Cryostats 클라이언트가 연결을 위해 사용할 수 있는 커넥터 목록을 지정할 수 있습니다. 이 목록을 지정하려면 원격 요소의 새 커넥터 특성을 사용합니다. connector 속성은 원격 하위 시스템에 정의된 커넥터 목록을 허용합니다. 이를 통해 단일 서버에서 Jakarta Enterprise Cryostats 클라이언트 애플리케이션에 여러 연결을 제공할 수 있습니다. 예를 들어 EAP 7.2 이상과 호환되는 클라이언트는 이전 버전의 EAP 7.2와 호환되는 레거시 클라이언트 및 이전 버전의 EAP 7.2와 호환되는 레거시 클라이언트가 커넥터와 함께 기존 원격 프로토콜을 사용하여 연결할 수 있는 remote +http 프로토콜을 사용하여 서버에 연결할 수 있습니다.

/subsystem=ejb3/service=remote:write-attribute(name=connectors, value=[http-remoting-connector, legacy-remoting-connector])

domain.xml 또는 standalone.xml 파일을 보고 Cryostat 3 하위 시스템에서 구성된 원격 커넥터를 확인할 수 있습니다.

<remote cluster="ejb" connectors="http-remoting-connector legacy-remoting-connector" thread-pool-name="default">
  <channel-creation-options>
   <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/>
  </channel-creation-options>
</remote>

상호 운용성을 원격하는 Jakarta Enterprise Beans 외에도 다음 옵션을 사용하여 기존 클라이언트에 연결할 수 있습니다.

JBoss EAP는 JBoss EAP에 배포된 Jakarta Enterprise Beans에 대한 CORBA/IIOP 기반 액세스를 지원합니다.

<iiop> 요소는 Jakarta Enterprise Bean의 IIOP, CORBA, 호출을 활성화하는 데 사용됩니다. 이 요소가 있다는 것은 iiop-openjdk 하위 시스템이 설치되어 있음을 의미합니다. <iiop> 요소에는 다음 두 가지 특성이 포함되어 있습니다.

IIOP 활성화

IIOP를 활성화하려면 IIOP OpenJDK ORB 하위 시스템이 설치되어 있어야 하고, <iiop/> 요소가 ejb3 하위 시스템 구성에 있어야 합니다. 배포와 함께 제공되는 standalone-full.xml 구성에는 이러한 두 가지 구성이 모두 활성화되어 있습니다.

IIOP는 서버 구성 파일의 iiop-openjdk 하위 시스템에서 구성됩니다.

<subsystem xmlns="urn:jboss:domain:iiop-openjdk:2.1">

다음 관리 CLI 명령을 사용하여 iiop-openjdk 하위 시스템에 액세스하고 업데이트합니다.

/subsystem=iiop-openjdk

IIOP 요소는 서버의 기본 동작을 제어하는 두 개의 특성을 사용합니다.

<subsystem xmlns="urn:jboss:domain:ejb3:5.0">
  ...
  <iiop enable-by-default="false" use-qualified-name="false"/>
  ...
</subsystem>

다음 관리 CLI 명령은 ejb3 하위 시스템 아래에 <iiop> 요소를 추가합니다.

/subsystem=ejb3/service=iiop:add(enable-by-default=false, use-qualified-name=false)

IIOP를 사용하여 커뮤니티를 연결하는 자카르타 엔터프라이즈 빈 만들기

다음 예제에서는 클라이언트에서 원격 IIOP 호출을 생성하는 방법을 보여줍니다.

아래 예와 같이 SessionContext 인터페이스를 사용하여 Jakarta Enterprise Beans 클라이언트 주소를 확인할 수 있습니다.

public class HelloBean implements HelloBeanRemote {
    @Resource
    SessionContext ctx;
    private Long counter;
    public HelloBean() {
    }
    @PostConstruct
    public void init() {
        counter = 0L;
    }
    @Override
    @RolesAllowed("users")
    public String hello() {
        final String message = "method hello() invoked by user " + ctx.getCallerPrincipal().getName()
                + ", source addr = " +  ctx.getContextData().get("jboss.source-address").toString();
        System.out.println(message);
        return message;
    }
}

독립 실행형 클라이언트 구성

the wildfly -config.xml 파일에서 네임스페이스 urn:xnio:3.5 를 보유하는 작업자 요소 내에서 outbound-bind- addresses 요소를 구성할 수 있습니다. bind-address sub-element는 아래에 정의된 대로 bind -address,bind-port 속성을 사용합니다.

다음은 the wildfly-config.xml 파일을 사용하는 독립 실행형 클라이언트 구성의 예입니다.

<configuration>
    <worker xmlns="urn:xnio:3.5">
        <worker-name value="default"/>
        <outbound-bind-addresses>
            <bind-address bind-address=IP_ADDRESS_TO_BIND_TO bind-port=OPTIONAL_SOURCE_PORT_NUMBER match=CIDR_BLOCK />
        </outbound-bind-addresses>
    </worker>
</configuration>

outbound -bind-address 에는 다음 속성이 필요합니다.

컨테이너 기반 구성

Jakarta Enterprise Beans 클라이언트 주소의 컨테이너 기반 구성은 the wildfly-config.xml 파일에 정의된 독립 실행형 클라이언트 구성과 유사합니다.

아래 예제에서는 ejb3 하위 시스템에서 기본적으로 사용하는 io 하위 시스템의 기본 worker 요소에 outbound -bind-address 를 구성합니다.

/subsystem=io/worker=default/outbound-bind-address=SPECIFY_OUTBOUND_BIND_ADDRESS:add(bind-address=IP_ADDRESS_TO_BIND_TO, bind-port=OPTIONAL_SOURCE_PORT_NUMBER, match=CIDR_BLOCK)

HTTP에 대한 Jakarta Enterprise Beans 호출에는 클라이언트측 및 서버 측 구현의 두 가지 부분이 포함됩니다.

<dependency>
    <groupId>org.wildfly.wildfly-http-client</groupId>
    <artifactId>wildfly-http-ejb-client</artifactId>
</dependency>

/subsystem=undertow/server=default-server/host=default-host/setting=http-invoker:add(http-authentication-factory=myfactory, path="wildfly-services")

JBoss EAP 7.1부터 배포를 매핑하여 elytron 하위 시스템에서 보안을 처리할 수 있습니다. 배포에서 매핑된 보안 도메인을 참조하는 경우 해당 보안은 Elytron에서 처리하며, 그렇지 않으면 레거시 보안 하위 시스템에서 보안을 처리합니다. 이 매핑은 ejb 하위 시스템에서 정의됩니다.

ejb 하위 시스템 내에서 매핑은 배포 내에서 참조된 대로 보안 도메인 이름에서 참조된 Elytron security-domain으로 생성됩니다. 매핑된 보안 도메인 이름이 배포에 빈에 대해 구성되면 Elytron에서 보안을 처리해야 함을 나타냅니다. 새로운 Jakarta Enterprise Beans 보안 인터셉터가 기존 인터셉터 대신 설정됩니다.

새로운 Jakarta Enterprise Beans 보안 인터셉터는 호출과 관련된 Elytron SecurityDomain 을 사용하여 현재 SecurityIdentity 를 가져와 다음 작업을 수행합니다.

JBoss EAP 7.1은 ejb 하위 시스템 application-security-domains 에 새 관리 리소스를 도입했습니다. application-security-domains 요소에는 Elytron 보안 도메인에 매핑해야 하는 애플리케이션 보안 도메인이 포함되어 있습니다.

관리 콘솔 또는 관리 CLI를 사용하여 dpdk 하위 시스템에서 application-security-domain 을 구성할 수 있습니다. 자세한 내용은 다음 항목을 참조하십시오.

/subsystem=ejb3/application-security-domain=MyAppSecurity:add(security-domain=ApplicationDomain)

<application-security-domains>
    <application-security-domain name="MyAppSecurity" security-domain="ApplicationDomain"/>
</application-security-domains>

JBoss EAP를 사용하면 맞춤형 Jakarta Enterprise Beans 인터셉터를 개발하고 관리할 수 있습니다.

다음과 같은 유형의 인터셉터를 생성할 수 있습니다.

사용자 지정 인터셉터 클래스는 모듈에 추가하고 $JBOSS_HOME/modules 디렉터리에 저장해야 합니다.

package org.foo;
import org.jboss.ejb.client.EJBClientInterceptor;
import org.jboss.ejb.client.EJBClientInvocationContext;
public class FooInterceptor implements EJBClientInterceptor {
    @Override
    public void handleInvocation(EJBClientInvocationContext context) throws Exception {
        context.sendRequest();
    }
    @Override
    public Object handleInvocationResult(EJBClientInvocationContext context) throws Exception {
        return context.getResult();
    }
}

package org.testsuite.ejb.serverinterceptor;
import javax.annotation.PostConstruct;
import javax.interceptor.AroundInvoke;
import javax.interceptor.InvocationContext;
public class TestServerInterceptor {
    @AroundInvoke
    public Object aroundInvoke(final InvocationContext invocationContext) throws Exception {

        return invocationContext.proceed();
    }
}

public class ClassLevelContainerInterceptor {
    @AroundInvoke
    private Object iAmAround(final InvocationContext invocationContext) throws Exception {
        return this.getClass().getName() + " " + invocationContext.proceed();
    }
}

<jboss xmlns="http://www.jboss.com/xml/ns/javaee"
       xmlns:jee="http://java.sun.com/xml/ns/javaee"
       xmlns:ci ="urn:container-interceptors:1.0">
    <jee:assembly-descriptor>
        <ci:container-interceptors>
            <!-- Default interceptor -->
            <jee:interceptor-binding>
                <ejb-name>*</ejb-name>
                <interceptor-class>org.jboss.as.test.integration.ejb.container.interceptor.ContainerInterceptorOne</interceptor-class>
            </jee:interceptor-binding>
            <!-- Class level container-interceptor -->
            <jee:interceptor-binding>
                <ejb-name>AnotherFlowTrackingBean</ejb-name>
                <interceptor-class>org.jboss.as.test.integration.ejb.container.interceptor.ClassLevelContainerInterceptor</interceptor-class>
            </jee:interceptor-binding>
            <!-- Method specific container-interceptor -->
            <jee:interceptor-binding>
                <ejb-name>AnotherFlowTrackingBean</ejb-name>
                <interceptor-class>org.jboss.as.test.integration.ejb.container.interceptor.MethodSpecificContainerInterceptor</interceptor-class>
                <method>
                    <method-name>echoWithMethodSpecificContainerInterceptor</method-name>
                </method>
            </jee:interceptor-binding>
            <!-- container interceptors in a specific order -->
            <jee:interceptor-binding>
                <ejb-name>AnotherFlowTrackingBean</ejb-name>
                <interceptor-order>
                    <interceptor-class>org.jboss.as.test.integration.ejb.container.interceptor.ClassLevelContainerInterceptor</interceptor-class>
                    <interceptor-class>org.jboss.as.test.integration.ejb.container.interceptor.MethodSpecificContainerInterceptor</interceptor-class>
                    <interceptor-class>org.jboss.as.test.integration.ejb.container.interceptor.ContainerInterceptorOne</interceptor-class>
                </interceptor-order>
                <method>
                    <method-name>echoInSpecificOrderOfContainerInterceptors</method-name>
                </method>
            </jee:interceptor-binding>
        </ci:container-interceptors>
    </jee:assembly-descriptor>
</jboss>

/subsystem=ejb3:write-attribute(name=allow-ejb-name-regex,value=true)

/subsystem=ejb3:list-add(name=server-interceptors,value={module=org.abccorp:tracing-interceptors:1.0,class=org.abccorp.TracingInterceptor})

/subsystem=ejb3:list-add(name=client-interceptors,value={module=org.abccorp:clientInterceptor:1.0,class=org.abccorp.clientInterceptor})

EJBClientContext ctxWithInterceptors = EJBClientContext.getCurrent().withAddedInterceptors(clientInterceptor);

import org.jboss.ejb.client.annotation.ClientInterceptors;
@ClientInterceptors({HelloClientInterceptor.class})

public interface HelloBeanRemote {
   public String hello();
}

자카르타 엔터프라이즈 빈 구성 요소는 고가용성 시나리오에 대해 클러스터링할 수 있습니다. HTTP 구성 요소와 다른 프로토콜을 사용하므로 서로 다른 방식으로 클러스터링됩니다. Enterprise Beans 2 및 3 상태 저장 빈 및 상태 비저장 빈을 클러스터링할 수 있습니다.

Singleton에 대한 자세한 내용은 JBoss EAP 개발 가이드의 HA Singleton Service 를 참조하십시오.

Jakarta Enterprise Beans 서버 측 클러스터 구성 요소를 호출할 때 Jakarta Enterprise Beans 클라이언트 코드를 단순화할 수 있습니다. 다음 절차에서는 Jakarta Enterprise Beans 클라이언트 코드를 간소화하는 여러 가지 방법을 간략하게 설명합니다.

클러스터링 지원은 JBoss EAP 7.4의 HA 프로필에서 사용할 수 있습니다. HA 기능을 활성화한 독립 실행형 서버를 시작하려면 standalone -ha.xml 또는 standalone- full-ha.xml 파일로 시작해야 합니다.

$ EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml

그러면 HA 기능이 있는 서버의 단일 인스턴스가 시작됩니다.

클러스터링의 이점을 보려면 서버의 두 개 이상의 인스턴스가 필요합니다. HA 기능을 사용하여 다른 서버를 시작하겠습니다. 서버의 다른 인스턴스는 동일한 시스템 또는 다른 시스템에 있을 수 있습니다. 동일한 시스템에 있는 경우 다음 두 가지를 처리해야 합니다.

다음 두 시스템 속성을 startup 명령에 전달하여 이를 수행할 수 있습니다.

$ EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.socket.binding.port-offset=PORT_OFFSET -Djboss.node.name=UNIQUE_NODE_NAME

이 인스턴스에도 Jakarta Enterprise Beans 배포를 배포하는 데 친숙한 접근 방식을 따르십시오.

이제 두 인스턴스에 클러스터형 Jakarta Enterprise Beans가 있는 애플리케이션을 배포했으므로 Jakarta Enterprise Beans는 이제 클러스터링 기능을 사용할 수 있습니다.

@Stateful(passivationCapable=false)

/subsystem=ejb3:write-attribute(name=default-sfsb-cache,value=simple)

클러스터형 Jakarta Enterprise Bean의 페일오버 기능. @Stateful Jakarta Enterprise Beans의 상태가 클러스터 노드에 복제되므로 클러스터의 노드 중 하나가 다운되면 다른 노드에서 호출을 인계받을 수 있습니다.

클러스터의 서버가 충돌하는 경우와 같이 클러스터형 환경에서 일부 상황에서 Jakarta Enterprise Beans 클라이언트에서 응답 대신 예외를 받을 수 있습니다. Jakarta Enterprise Beans 클라이언트 라이브러리는 발생하는 오류 유형에 따라 안전한 경우 호출을 자동으로 다시 시도합니다. 그러나 요청이 실패하고 재시도에 안전하게 확인할 수 없는 경우 환경에 적절하게 예외를 처리할 수 있습니다. 그러나 사용자 지정 인터셉터를 사용하여 재시도 동작을 추가할 수 있습니다.

독립 실행형 원격 클라이언트는 Java Naming 및 Directory Interface 접근법 또는 기본 JBoss Jakarta Enterprise Beans 클라이언트 API를 사용하여 서버와 통신할 수 있습니다. 중요한 점은 클러스터형 Jakarta Enterprise Beans 배포를 호출할 때 클러스터 내의 모든 서버를 나열할 필요가 없다는 것입니다. 이는 클러스터 내에서 클러스터 노드 추가의 동적 특성으로 인해 불가능할 수 있었습니다.

원격 클라이언트는 클러스터링 기능이 있는 서버 중 하나만 나열해야 합니다. 이 서버는 클라이언트와 클러스터된 노드 간의 클러스터 토폴로지 통신의 시작 지점 역할을 합니다.

jboss-ejb-client.properties 구성 파일에서 ejb 클러스터를 구성해야 합니다.

remote.clusters=ejb
remote.cluster.ejb.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
remote.cluster.ejb.connect.options.org.xnio.Options.SSL_ENABLED=false

클라이언트가 서버에 연결하면 서버에 클러스터링 기능이 있는 경우 JBoss Jakarta Enterprise Beans 클라이언트 구현이 클러스터 토폴로지 정보용 서버와 내부적으로 통신합니다. 예를 들어 서버 X가 연결할 초기 서버로 나열되는 경우 클라이언트가 서버 X에 연결할 때 서버는 비동기 클러스터 토폴로지 메시지를 클라이언트에 다시 보냅니다. 이 토폴로지 메시지는 클러스터 이름과 클러스터에 속하는 노드의 정보로 구성됩니다. 노드 정보에는 필요한 경우 연결할 노드 주소와 포트 번호가 포함됩니다. 이 예에서 서버 X는 클러스터에 속하는 다른 서버 Y로 구성된 클러스터 토폴로지를 다시 보냅니다.

상태 저장 클러스터형 Jakarta Enterprise Bean의 경우 호출 흐름이 두 단계로 수행됩니다.

상태 저장 빈에 대한 조회는 내부적으로 클라이언트에서 서버로 동기 세션 생성 요청을 트리거합니다. 이 경우 세션 생성 요청은 jboss-ejb-client.properties 파일에 구성되었으므로 서버 X로 이동합니다. 서버 X가 클러스터되므로 세션 ID를 반환하고 해당 세션의 선호도 를 다시 보냅니다. 클러스터된 서버의 경우 선호도 는 상태 저장 빈이 서버 측에 속하는 클러스터의 이름과 동일합니다. 비클러스터형 빈의 경우 선호도는 세션이 생성된 노드 이름입니다. 이 선호도 를 사용하면 Jakarta Enterprise Beans 클라이언트가 클러스터형 빈의 노드 또는 클러스터되지 않은 빈의 경우 특정 노드로 프록시에서 호출을 라우팅할 수 있습니다. 이 세션 생성 요청이 실행되는 동안 서버 X는 클러스터 토폴로지를 포함하는 비동기 메시지를 다시 보냅니다. JBoss Jakarta Enterprise Beans 클라이언트 구현은 이 토폴로지 정보를 기록하고 나중에 클러스터 내의 노드에 연결하고 필요한 경우 호출을 라우팅하는 데 사용합니다.

장애 조치(failover)가 작동하는 방식을 이해하기 위해 서버 X가 시작점이며 클라이언트 애플리케이션이 상태 저장 빈을 찾아 호출하는 것과 동일한 예제를 고려합니다. 이러한 호출 중에 클라이언트 측은 서버에서 클러스터 토폴로지 정보를 수집합니다. 어떤 이유로든 서버 X가 다운되고 클라이언트 애플리케이션이 프록시에서 호출된다고 가정합니다. 이 단계에서 JBoss Jakarta Enterprise Beans 클라이언트 구현은 선호도 를 인식해야 하며, 이 경우 클러스터 선호도입니다. 클라이언트에 있는 클러스터 토폴로지 정보에서 클러스터에 서버 X와 서버 Y의 두 개의 노드가 있음을 알고 있습니다. 호출이 도착하면 클라이언트에서 서버 X가 다운되었음을 알 수 있으므로 선택기를 사용하여 클러스터 노드에서 적합한 노드를 가져옵니다. 선택기가 클러스터 노드에서 노드를 반환하면 JBoss Jakarta Enterprise Beans 클라이언트 구현에서 연결이 이전에 생성되지 않은 경우 해당 노드에 대한 연결을 생성하고 Jakarta Enterprise Beans 수신자를 생성합니다. 이 예에서 클러스터의 다른 노드만 server Y이므로 선택기는 서버 Y를 노드로 반환하고 JBoss Jakarta Enterprise Beans 클라이언트 구현에서는 이 수신자를 사용하여 Jakarta Enterprise Beans 수신자를 생성하고 이 수신자를 사용하여 프록시의 호출을 전달합니다. 이제 클러스터 내의 다른 노드로 호출이 실패했습니다.

Jakarta Enterprise Beans 프록시와 동일한 컨텍스트에서 검색되는 트랜잭션 개체는 동일한 호스트를 대상으로 합니다. 컨텍스트가 다중 호스트이거나 클러스터된 경우 활성 트랜잭션을 보유하면 호출 컨텍스트가 동일한 노드에 고정됩니다.

이 동작은 트랜잭션이 오버플로되었는지 또는 원격 사용자 트랜잭션을 사용 중인지에 따라 달라집니다.

아웃플로된 트랜잭션의 경우 애플리케이션이 특정 노드에서 조회되면 동일한 트랜잭션에서 해당 애플리케이션에 대한 모든 호출이 이 노드를 대상으로 시도합니다. 아웃플로된 트랜잭션을 이미 수신한 노드는 아직 받지 않은 노드보다 선호됩니다.

원격 사용자 트랜잭션의 경우 첫 번째 성공적인 호출이 트랜잭션을 지정된 노드에 잠그고 이 트랜잭션에서 호출한 후 동일한 노드로 이동해야 합니다. 그렇지 않으면 예외가 발생합니다.

이 섹션에서는 JBoss EAP 인스턴스에 배포된 클라이언트 애플리케이션이 다른 JBoss EAP 인스턴스에 배포된 클러스터형 상태 저장 빈을 호출하는 방법에 대해 설명합니다.

다음 예에서는 3개의 서버가 관련되어 있습니다. 서버 X와 Y는 모두 클러스터에 속하며 클러스터형 Jakarta Enterprise Beans를 배포합니다. 클러스터링 기능이 없을 수도 있고 클러스터링 기능이 없을 수도 있는 다른 서버 인스턴스 서버 서버 C가 있습니다. 서버 C는 서버 X 및 Y에 배포된 클러스터형 빈을 호출하고 페일오버를 수행하려는 배포가 있는 클라이언트 역할을 합니다.

구성은 jboss-ejb-client.xml 파일에서 수행되며, 다른 서버에 대한 원격 아웃바운드 연결을 가리킵니다. jboss-ejb-client.xml 파일의 구성은 서버 C가 클라이언트이기 때문에 서버 C의 배포에 있습니다. 클라이언트 구성은 모든 클러스터된 노드를 가리켜야 하는 것이 아니라 그 중 하나를 가리켜야 합니다. 이는 통신의 시작점으로 사용될 것입니다.

이 경우 원격 아웃바운드 연결이 서버 C에서 서버 X로 생성되고 서버 X가 통신의 시작점으로 사용됩니다. 원격 독립 실행형 클라이언트의 경우와 유사하게 서버 C에서 상태 저장 빈을 찾을 때 세션 생성 요청이 세션 ID와 클러스터 선호도를 반환하는 서버 X로 전송됩니다. 또한 서버 X는 비동기 메시지를 클러스터 토폴로지를 포함하는 서버 C로 보냅니다. 서버 Y는 서버 X와 함께 클러스터에 속해 있기 때문에 이 토폴로지 정보에는 서버 Y의 노드 정보가 포함됩니다. 프록시에서 후속 호출은 클러스터의 노드로 적절하게 라우팅됩니다. 앞에서 설명한 대로 서버 X가 종료되면 클러스터와 다른 노드가 선택되고 호출이 해당 노드로 전달됩니다.

다른 JBoss EAP 인스턴스의 원격 클라이언트 및 원격 클라이언트 모두 장애 조치(failover) 측면에서 유사하게 작동합니다.

Jakarta Enterprise Beans 클라이언트를 클러스터형 Jakarta Enterprise Beans 애플리케이션에 연결하려면 독립 실행형 Jakarta Enterprise Beans 클라이언트 또는 in-server Jakarta Enterprise Beans 클라이언트에서 기존 구성을 확장하여 클러스터 연결 구성을 포함해야 합니다. 독립 실행형 Jakarta Enterprise Beans 클라이언트의 jboss-ejb-client.properties 또는 서버 측 애플리케이션의 jboss-ejb-client.xml 파일까지 클러스터 구성을 포함하도록 확장해야 합니다.

이 예에서는 독립 실행형 Jakarta Enterprise Beans 클라이언트에 필요한 추가 클러스터 구성을 보여줍니다.

remote.clusters=ejb
remote.cluster.ejb.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
remote.cluster.ejb.connect.options.org.xnio.Options.SSL_ENABLED=false
remote.cluster.ejb.username=test
remote.cluster.ejb.password=password

애플리케이션이 remote-outbound-connection을 사용하는 경우 jboss-ejb-client.xml 파일을 구성하고 다음 예와 같이 클러스터 구성을 추가해야 합니다.

<jboss-ejb-client xmlns:xsi="urn:jboss:ejb-client:1.2" xsi:noNamespaceSchemaLocation="jboss-ejb-client_1_2.xsd">
  <client-context>
    <ejb-receivers>
      <!-- this is the connection to access the app-one -->
      <remoting-ejb-receiver outbound-connection-ref="remote-ejb-connection-1" />
      <!-- this is the connection to access the app-two -->
      <remoting-ejb-receiver outbound-connection-ref="remote-ejb-connection-2" />
    </ejb-receivers>

    <!-- If an outbound connection connects to a cluster,
             a list of members is provided after successful connection.
         To connect to this node this cluster element must be defined. -->

    <clusters>
      <!-- cluster of remote-ejb-connection-1 -->
      <cluster name="ejb" security-realm="ejb-security-realm-1" username="quickuser1">
        <connection-creation-options>
        <property name="org.xnio.Options.SSL_ENABLED" value="false" />
        <property name="org.xnio.Options.SASL_POLICY_NOANONYMOUS" value="false" />
        </connection-creation-options>
      </cluster>
    </clusters>
  </client-context>
</jboss-ejb-client>

remote-outbound-connection에 대한 자세한 내용은 JBoss EAP 구성 가이드 의 Remoting Subsystem 정보를 참조하십시오.

서버 간에 애플리케이션의 Jakarta Enterprise Beans 호출의 균형을 맞추기 위해 대체 또는 사용자 지정 로드 밸런싱 정책을 구현할 수 있습니다.

Jakarta Enterprise Beans 호출에 대한 AllClusterNodeSelector 를 구현할 수 있습니다. AllClusterNodeSelector 의 노드 선택 동작은 대규모 클러스터(노드 수 > 20)에서도 AllClusterNodeSelector 가 사용 가능한 모든 클러스터 노드를 사용한다는 점을 제외하고 기본 선택기와 유사합니다. 연결되지 않은 클러스터 노드가 반환되면 자동으로 열립니다. 다음 예제에서는 AllClusterNodeSelector 구현을 보여줍니다.

package org.jboss.as.quickstarts.ejb.clients.selector;

import java.util.Arrays;
import java.util.Random;
import java.util.logging.Level;
import java.util.logging.Logger;

import org.jboss.ejb.client.ClusterNodeSelector;
public class AllClusterNodeSelector implements ClusterNodeSelector {
  private static final Logger LOGGER = Logger.getLogger(AllClusterNodeSelector.class.getName());

  @Override
  public String selectNode(final String clusterName, final String[] connectedNodes, final String[] availableNodes) {
    if(LOGGER.isLoggable(Level.FINER)) {
      LOGGER.finer("INSTANCE "+this+ " : cluster:"+clusterName+" connected:"+Arrays.deepToString(connectedNodes)+" available:"+Arrays.deepToString(availableNodes));
    }

    if (availableNodes.length == 1) {
        return availableNodes[0];
    }
    final Random random = new Random();
    final int randomSelection = random.nextInt(availableNodes.length);
    return availableNodes[randomSelection];
  }

}

Jakarta Enterprise Beans 호출에 대한 SimpleLoadFactorNodeSelector 를 구현할 수도 있습니다. SimpleLoadFactorNodeSelector 의 부하 분산은 부하 요인에 따라 수행됩니다. 로드 계수(2/3/4)는 각 노드의 부하와 관계없이 노드 이름(A/B/C)에 따라 계산됩니다. 다음 예는 SimpleLoadFactorNodeSelector 구현을 보여줍니다.

package org.jboss.as.quickstarts.ejb.clients.selector;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collection;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.logging.Level;
import java.util.logging.Logger;

import org.jboss.ejb.client.DeploymentNodeSelector;
public class SimpleLoadFactorNodeSelector implements DeploymentNodeSelector {
  private static final Logger LOGGER = Logger.getLogger(SimpleLoadFactorNodeSelector.class.getName());
  private final Map<String, List<String>[]> nodes = new HashMap<String, List<String>[]>();
  private final Map<String, Integer> cursor = new HashMap<String, Integer>();

  private ArrayList<String> calculateNodes(Collection<String> eligibleNodes) {
    ArrayList<String> nodeList = new ArrayList<String>();

    for (String string : eligibleNodes) {
      if(string.contains("A") || string.contains("2")) {
        nodeList.add(string);
        nodeList.add(string);
      } else if(string.contains("B") || string.contains("3")) {
        nodeList.add(string);
        nodeList.add(string);
        nodeList.add(string);
      } else if(string.contains("C") || string.contains("4")) {
        nodeList.add(string);
        nodeList.add(string);
        nodeList.add(string);
        nodeList.add(string);
      }
    }
    return nodeList;
  }

  @SuppressWarnings("unchecked")
  private void checkNodeNames(String[] eligibleNodes, String key) {
    if(!nodes.containsKey(key) || nodes.get(key)[0].size() != eligibleNodes.length || !nodes.get(key)[0].containsAll(Arrays.asList(eligibleNodes))) {
      // must be synchronized as the client might call it concurrent
      synchronized (nodes) {
        if(!nodes.containsKey(key) || nodes.get(key)[0].size() != eligibleNodes.length || !nodes.get(key)[0].containsAll(Arrays.asList(eligibleNodes))) {
          ArrayList<String> nodeList = new ArrayList<String>();
          nodeList.addAll(Arrays.asList(eligibleNodes));

          nodes.put(key, new List[] { nodeList, calculateNodes(nodeList) });
        }
      }
    }
  }
   private synchronized String nextNode(String key) {
    Integer c = cursor.get(key);
    List<String> nodeList = nodes.get(key)[1];

    if(c == null || c >= nodeList.size()) {
      c = Integer.valueOf(0);
    }

    String node = nodeList.get(c);
    cursor.put(key, Integer.valueOf(c + 1));

    return node;
  }

  @Override
  public String selectNode(String[] eligibleNodes, String appName, String moduleName, String distinctName) {
    if (LOGGER.isLoggable(Level.FINER)) {
      LOGGER.finer("INSTANCE " + this + " : nodes:" + Arrays.deepToString(eligibleNodes) + " appName:" + appName + " moduleName:" + moduleName
          + " distinctName:" + distinctName);
    }

    // if there is only one there is no sense to choice
    if (eligibleNodes.length == 1) {
      return eligibleNodes[0];
    }
    final String key = appName + "|" + moduleName + "|" + distinctName;

    checkNodeNames(eligibleNodes, key);
    return nextNode(key);
  }
}

jboss-ejb-client.properties 파일 구성

구현 클래스(AllClusterNodeSelector 또는 SimpleLoadFactorNodeSelector )의 이름으로 remote .cluster.ejb.clusternode.selector 속성을 추가해야 합니다. 선택기는 호출 시 사용할 수 있는 구성된 모든 서버가 표시됩니다. 다음 예제에서는 AllClusterNodeSelector 를 클러스터 노드 선택기로 사용합니다.

remote.clusters=ejb
remote.cluster.ejb.clusternode.selector=org.jboss.as.quickstarts.ejb.clients.selector.AllClusterNodeSelector
remote.cluster.ejb.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
remote.cluster.ejb.connect.options.org.xnio.Options.SSL_ENABLED=false
remote.cluster.ejb.username=test
remote.cluster.ejb.password=password

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=one,two
remote.connection.one.host=localhost
remote.connection.one.port = 8080
remote.connection.one.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
remote.connection.one.username=user
remote.connection.one.password=user123
remote.connection.two.host=localhost
remote.connection.two.port = 8180
remote.connection.two.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

Jakarta Enterprise Beans 클라이언트 API 사용

PropertiesBasedEJBClientConfiguration 생성자의 목록에 remote.cluster.ejb.clusternode.selector 속성을 추가해야 합니다. 다음 예제에서는 AllClusterNodeSelector 를 클러스터 노드 선택기로 사용합니다.

Properties p = new Properties();
p.put("remote.clusters", "ejb");
p.put("remote.cluster.ejb.clusternode.selector", "org.jboss.as.quickstarts.ejb.clients.selector.AllClusterNodeSelector");
p.put("remote.cluster.ejb.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS", "false");
p.put("remote.cluster.ejb.connect.options.org.xnio.Options.SSL_ENABLED", "false");
p.put("remote.cluster.ejb.username", "test");
p.put("remote.cluster.ejb.password", "password");

p.put("remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED", "false");
p.put("remote.connections", "one,two");
p.put("remote.connection.one.port", "8080");
p.put("remote.connection.one.host", "localhost");
p.put("remote.connection.two.port", "8180");
p.put("remote.connection.two.host", "localhost");

EJBClientConfiguration cc = new PropertiesBasedEJBClientConfiguration(p);
ContextSelector<EJBClientContext> selector = new ConfigBasedEJBClientContextSelector(cc);
EJBClientContext.setSelector(selector);

p = new Properties();
p.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
InitialContext context = new InitialContext(p);

jboss-ejb-client.xml 파일 구성

서버에서 서버 간 통신에 부하 분산 정책을 사용하려면 클래스를 애플리케이션과 함께 패키징하고 META-INF 폴더에 있는 jboss-ejb-client.xml 설정 내에 구성합니다. 다음 예제에서는 AllClusterNodeSelector 를 클러스터 노드 선택기로 사용합니다.

<jboss-ejb-client xmlns:xsi="urn:jboss:ejb-client:1.2" xsi:noNamespaceSchemaLocation="jboss-ejb-client_1_2.xsd">
  <client-context deployment-node-selector="org.jboss.ejb.client.DeploymentNodeSelector">
    <ejb-receivers>
      <!-- This is the connection to access the application. -->
      <remoting-ejb-receiver outbound-connection-ref="remote-ejb-connection-1" />
    </ejb-receivers>
    <!-- Specify the cluster configurations applicable for this client context -->
    <clusters>
      <!-- Configure the cluster of remote-ejb-connection-1. -->
      <cluster name="ejb" security-realm="ejb-security-realm-1" username="test" cluster-node-selector="org.jboss.as.quickstarts.ejb.clients.selector.AllClusterNodeSelector">
        <connection-creation-options>
          <property name="org.xnio.Options.SSL_ENABLED" value="false" />
          <property name="org.xnio.Options.SASL_POLICY_NOANONYMOUS" value="false" />
        </connection-creation-options>
      </cluster>
    </clusters>
  </client-context>
</jboss-ejb-client>

보안과 함께 위의 구성을 사용하려면 ejb-security-realm-1을 클라이언트- 서버 구성에 추가해야 합니다. 다음 예제에서는 보안 영역(ejb-security-realm-1)을 추가하기 위한 CLI 명령을 보여줍니다. 값은 "test" 사용자의 base64 인코딩 암호입니다.

/core-service=management/security-realm=ejb-security-realm-1:add()
/core-service=management/security-realm=ejb-security-realm-1/server-identity=secret:add(value=cXVpY2sxMjMr)

서버 간 통신에 부하 분산 정책을 사용해야 하는 경우 클래스를 애플리케이션 또는 모듈과 함께 패키징할 수 있습니다. 이 클래스는 최상위 EAR 아카이브의 META -INF 디렉터리에 있는 jboss- ejb-client 설정 파일에서 구성됩니다. 다음 예제에서는 배포 노드 선택기로 RoundRobinNodeSelector 를 사용합니다.

<jboss-ejb-client xmlns="urn:jboss:ejb-client:1.2">
    <client-context deployment-node-selector="org.jboss.example.RoundRobinNodeSelector">
        <ejb-receivers>
            <remoting-ejb-receiver outbound-connection-ref="..."/>
        </ejb-receivers>
        ...
    </client-context>
</jboss-ejb-client>

클라이언트 코드가 클러스터형 Jakarta Enterprise Bean을 호출하면 클러스터 선호도가 자동으로 설정됩니다. 클라이언트 측에서 트랜잭션을 관리하는 경우 클러스터에서 특정 노드를 대상으로 하도록 선택하거나 클라이언트가 트랜잭션을 처리할 클러스터 노드를 지연적으로 선택할 수 있습니다. 이 섹션에서는 두 옵션에 대해 설명합니다.

Jakarta Enterprise Beans Transactions 특정 노드를 대상으로 합니다

다음 절차에 따라 클러스터의 특정 노드를 대상으로 트랜잭션을 처리할 수 있습니다.

Jakarta Enterprise Beans Transactions Lazily Select a Node

클라이언트에서 트랜잭션과 관련된 첫 번째 호출 중에 트랜잭션을 처리하도록 클러스터 노드를 지연적으로 선택할 수 있습니다. 이를 통해 클러스터 전체에서 트랜잭션의 부하를 분산할 수 있습니다. 이 옵션을 사용하려면 아래 절차를 따르십시오.

JBoss EAP는 클러스터형 환경에서 Jakarta Enterprise Bean 타이머를 유지하기 위해 클러스터형 데이터베이스 지원 타이머를 지원합니다. 클러스터링이 데이터베이스를 통해 제공되기 때문에 짧은 시간 내에 타이머 수가 꺼지면 성능이 저하됩니다. ejb3/service=timer-service/database -data -store 구성 요소의 refresh-interval 및 allow- execution 특성을 사용하여 성능을 최적화할 수 있습니다.

다음과 같이 비클러스터형 모드에서 데이터베이스 타이머를 사용할 수도 있습니다.

Jakarta Enterprise Beans-clustered 데이터베이스 타이머는 다음과 같이 작동합니다.

트랜잭션과 READ_COMMITTED 또는 SERIALIZABLE 격리 모드를 사용하므로 행 업데이트에는 하나의 노드만 성공적으로 수행되며 타이머가 실행되는 노드입니다.