2.2. 여러 입력

2.2.1. 개요

표준 경로는 Java DSL의 from(EndpointURL) 구문을 사용하여 단일 끝점에서만 입력을 가져옵니다. 그러나 경로에 대한 여러 입력을 정의해야 하는 경우 어떻게 해야 합니까? Apache Camel은 경로에 여러 입력을 지정할 수 있는 몇 가지 대안을 제공합니다. 이러한 접근 방식은 교환을 서로 독립적으로 처리할지 또는 서로 다른 입력의 교환을 어떤 방식으로든 결합할지 여부(이 경우 “콘텐츠 강화 패턴”를 사용해야 함)에 따라 달라집니다.

2.2.2. 여러 독립 입력

여러 입력을 지정하는 가장 간단한 방법은 from() DSL 명령의 다중 배열 형식을 사용하는 것입니다. 예를 들면 다음과 같습니다.

from("URI1", "URI2", "URI3").to("DestinationUri");

또는 다음과 같은 구문을 사용할 수 있습니다.

from("URI1").from("URI2").from("URI3").to("DestinationUri");

이 두 예에서 입력 끝점, URI1,URI2 및 URI3 간의 교환은 서로 독립적으로 그리고 별도의 스레드에서 처리됩니다. 실제로 이전 경로를 다음 세 개의 별도의 경로와 동일한 것으로 간주할 수 있습니다.

from("URI1").to("DestinationUri");
from("URI2").to("DestinationUri");
from("URI3").to("DestinationUri");

2.2.3. 분할된 경로

예를 들어 두 개의 다른 메시징 시스템에서 들어오는 메시지를 병합하고 동일한 경로를 사용하여 처리할 수 있습니다. 대부분의 경우 그림 2.5. “세분화된 경로를 사용하여 여러 입력 처리” 에 표시된 대로 경로를 세그먼트로 분할하여 여러 입력을 처리할 수 있습니다.

그림 2.5. 세분화된 경로를 사용하여 여러 입력 처리

경로의 초기 세그먼트는 일부 외부 대기열에서 입력을 가져옵니다.예: activemq:Nyse 및 activemq:Nasdaq Cryostat-이자 내부 끝점으로 들어오는 교환을 내부 끝점으로 보냅니다. 두 번째 경로 세그먼트는 들어오는 교환을 병합하여 내부 엔드포인트에서 가져 와서 대상 대기열 activemq:USTxn 으로 전송합니다. InternalUrl 은 라우터 애플리케이션 내에서 사용하기 위한 끝점의 URL입니다. 다음 유형의 끝점은 내부 용도에 적합합니다.

이러한 끝점의 주요 목적은 경로의 다양한 세그먼트를 조합할 수 있도록 하는 것입니다. 모두 여러 입력을 단일 경로에 병합하는 효과적인 방법을 제공합니다.

2.2.4. 직접 끝점

직접 구성 요소는 경로를 연결하는 가장 간단한 메커니즘을 제공합니다. 직접 구성 요소의 이벤트 모델은 동기식 이므로 경로의 후속 세그먼트가 첫 번째 세그먼트와 동일한 스레드에서 실행됩니다. 직접 URL의 일반적인 형식은 direct:EndpointID 입니다. 여기서 끝점 ID, EndpointID 는 단순히 엔드포인트 인스턴스를 식별하는 고유한 영숫자 문자열입니다.

예를 들어 두 개의 메시지 대기열인 activemq:Nyse 및 activemq:Nasdaq 에서 입력을 가져와서 단일 메시지 큐인 activemq:USTxn 에 병합하려면 다음 경로 세트를 정의하여 이 작업을 수행할 수 있습니다.

from("activemq:Nyse").to("direct:mergeTxns");
from("activemq:Nasdaq").to("direct:mergeTxns");

from("direct:mergeTxns").to("activemq:USTxn");

여기서 처음 두 경로는 메시지 큐( Nyse 및 Nasdaq )에서 입력을 가져와서 엔드포인트 direct:mergeTxns 로 보냅니다. 마지막 큐는 이전 두 큐의 입력을 결합하고 결합된 메시지 스트림을 activemq:USTxn 큐로 보냅니다.

직접 끝점의 구현은 다음과 같이 작동합니다. 교환이 생산자 끝점(예: to("direct:mergeTxns")에 도달할 때마다 직접 끝점은 동일한 끝점 ID가 있는 모든 소비자 끝점에 직접 교환을 전달합니다(예: from("direct:mergeTxns")). 직접 끝점은 동일한 JVM(Java 가상 머신) 인스턴스에서 동일한 CamelContext 에 속하는 경로 간 통신에만 사용할 수 있습니다.

2.2.5. SEDA 끝점

SEDA 구성 요소는 함께 경로를 연결하기 위한 대체 메커니즘을 제공합니다. 직접 구성 요소와 유사한 방식으로 사용할 수 있지만 다음과 같이 다른 기본 이벤트 및 스레딩 모델이 있습니다.

SEDA 엔드포인트 처리는 동기가 아닙니다. 즉, SEDA 생산자 엔드포인트에 교환을 보내면 제어가 경로의 이전 프로세서로 즉시 반환됩니다.
SEDA 끝점에는 다음 경로 세그먼트에 의해 처리되기 전에 들어오는 모든 교환을 저장하는 대기열 버퍼( java.util.concurrent.BlockingQueue 유형)가 포함되어 있습니다.
각 SEDA 소비자 끝점은 스레드 풀을 생성하여 차단 대기열에서 교환 오브젝트를 처리합니다.
SEDA 구성 요소는 경쟁하는 소비자 패턴을 지원하므로 각 들어오는 교환이 특정 엔드포인트에 연결된 소비자가 여러 개 있어도 한 번만 처리됩니다.

SEDA 엔드포인트 사용의 주요 이점 중 하나는 경로가 내장 소비자 스레드 풀로 인해 응답성이 향상될 수 있다는 것입니다. 주식 거래 예는 다음과 같이 직접 끝점 대신 SEDA 끝점을 사용하도록 다시 작성할 수 있습니다.

from("activemq:Nyse").to("seda:mergeTxns");
from("activemq:Nasdaq").to("seda:mergeTxns");

from("seda:mergeTxns").to("activemq:USTxn");

이 예제와 직접 예제의 주요 차이점은 SEDA를 사용할 때 두 번째 경로 세그먼트( seda:mergeTxns 에서 activemq:USTxn)가 5개의 스레드 풀에서 처리된다는 것입니다.

참고

SEDA에는 단순히 경로 세그먼트를 붙여넣는 것보다 더 많은 것이 있습니다. 스테이징된 이벤트 중심 아키텍처(SEDA)는 보다 관리가 용이한 다중 스레드 애플리케이션을 빌드하기 위한 설계 철학을 포함합니다. Apache Camel의 SEDA 구성 요소는 간단히 이 설계 철학을 애플리케이션에 적용할 수 있도록 하는 것입니다. SEDA에 대한 자세한 내용은 http://www.eecs.harvard.edu/~mdw/proj/seda/ 을 참조하십시오.

2.2.6. VM 끝점

VM 구성 요소는 SEDA 엔드포인트와 매우 유사합니다. 유일한 차이점은 SEDA 구성 요소는 동일한 CamelContext 내에서 경로 세그먼트를 연결하는 반면 VM 구성 요소를 사용하면 동일한 Java 가상 시스템에서 실행되는 경우 별도의 Apache Camel 애플리케이션에서 경로를 함께 연결할 수 있다는 것입니다.

주식 거래 예는 다음과 같이 SEDA 끝점 대신 VM 끝점을 사용하도록 다시 작성할 수 있습니다.

from("activemq:Nyse").to("vm:mergeTxns");
from("activemq:Nasdaq").to("vm:mergeTxns");

또한 별도의 라우터 애플리케이션(동일 Java VM에서 실행)에서 다음과 같이 경로의 두 번째 세그먼트를 정의할 수 있습니다.

from("vm:mergeTxns").to("activemq:USTxn");

2.2.7. 콘텐츠 강화 패턴

컨텐츠 강화 패턴은 경로에 대한 여러 입력을 처리하는 근본적으로 다른 방법을 정의합니다. 교환이 강화 프로세서에 진입하면 보강된 정보는 정보를 검색하기 위해 외부 리소스에 연락한 다음 원래 메시지에 추가됩니다. 이 패턴에서 외부 리소스는 메시지에 대한 두 번째 입력을 효과적으로 나타냅니다.

예를 들어 신용 요청을 처리하는 애플리케이션을 작성하고 있다고 가정합니다. 신용 요청을 처리하기 전에 고객에게 신용 등급을 할당하는 데이터로 보강해야 합니다. 여기서 등급 데이터는 디렉터리의 src/data/ratings 파일에 저장됩니다. 다음과 같이 pollEnrich() 패턴과 GroupedExchangeAggregationStrategy 집계 전략을 사용하여 평가 파일의 데이터와 들어오는 신용 요청을 결합할 수 있습니다.

from("jms:queue:creditRequests")
    .pollEnrich("file:src/data/ratings?noop=true", new GroupedExchangeAggregationStrategy())
    .bean(new MergeCreditRequestAndRatings(), "merge")
    .to("jms:queue:reformattedRequests");

여기서 GroupedExchangeAggregationStrategy 클래스는 org.apache.camel.processor.aggregate 패키지의 표준 집계 전략이며 각 새 교환을 java.util.List 인스턴스에 추가하고 결과 목록을 Exchange.GROUPED_EXCHANGE exchange 속성에 저장합니다. 이 경우 목록에는 원래 교환( creditRequests JMS 큐에서)과 파일 엔드포인트에서 제공하는 강화 교환이라는 두 가지 요소가 포함되어 있습니다.

그룹화된 교환에 액세스하려면 다음과 같은 코드를 사용할 수 있습니다.

public class MergeCreditRequestAndRatings {
    public void merge(Exchange ex) {
        // Obtain the grouped exchange
        List<Exchange> list = ex.getProperty(Exchange.GROUPED_EXCHANGE, List.class);

        // Get the exchanges from the grouped exchange
        Exchange originalEx = list.get(0);
        Exchange ratingsEx  = list.get(1);

        // Merge the exchanges
        ...
    }
}

이 애플리케이션의 대체 방법은 병합 코드를 사용자 지정 집계 전략 클래스의 구현에 직접 배치하는 것입니다.

콘텐츠 강화 패턴에 대한 자세한 내용은 10.1절. “콘텐츠 Enricher” 을 참조하십시오.

2.2. 여러 입력

2.2.1. 개요

2.2.2. 여러 독립 입력

2.2.3. 분할된 경로

2.2.4. 직접 끝점

2.2.5. SEDA 끝점

2.2.6. VM 끝점

2.2.7. 콘텐츠 강화 패턴

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat 소개

Red Hat legal and privacy links

Red Hat legal and privacy links