38장. 구성 요소 구현

초록

이 장에서는 Apache Camel 구성 요소를 구현하는 데 사용할 수 있는 일반적인 접근 방식을 간략하게 설명합니다.

38.1. 구성 요소 아키텍처

38.1.1. 구성 요소의 팩토리 패턴

38.1.1.1. 개요

Apache Camel 구성 요소는 팩토리 패턴을 통해 서로 관련된 클래스 세트로 구성됩니다. 구성 요소의 기본 진입점은 Component 개체 자체입니다( org.apache.camel.Component 유형의 인스턴스). Component 개체를 팩토리로 사용하여 끝점 개체를 만들 수 있으며, 이 오브젝트는 소비자,프로듀서, 교환 개체를 생성하기 위한 팩토리 역할을 합니다. 이러한 관계가 요약되어 있습니다. 그림 38.1. “구성 요소 factory 패턴”

그림 38.1. 구성 요소 factory 패턴

38.1.1.2. Component

구성 요소 구현은 끝점 팩토리입니다. 구성 요소 구현자의 주요 작업은 필요에 따라 새 끝점을 생성하는 Component.createEndpoint() 메서드를 구현하는 것입니다.

각 종류의 구성 요소는 끝점 URI에 표시되는 구성 요소 접두사 와 연결되어야 합니다. 예를 들어 파일 구성 요소는 일반적으로 file://tmp/messages/input 와 같은 끝점 URI에서 사용할 수 있는 파일 접두사와 연결됩니다. Apache Camel에 새 구성 요소를 설치할 때 특정 구성 요소 접두사와 구성 요소를 구현하는 클래스 이름 간의 연결을 정의해야 합니다.

38.1.1.3. endpoint

각 끝점 인스턴스는 특정 끝점 URI를 캡슐화합니다. Apache Camel이 새 엔드포인트 URI에 직면할 때마다 새 엔드포인트 인스턴스를 생성합니다. 끝점 오브젝트는 소비자 끝점 및 생산자 끝점을 생성하기 위한 팩토리이기도 합니다.

엔드포인트는 org.apache.camel.Endpoint 인터페이스를 구현해야 합니다. Endpoint 인터페이스는 다음 팩토리 방법을 정의합니다.

createConsumer() 및 createPollingConsumer() Cryostat-ECDHE는 경로 시작 시 소스 끝점을 나타내는 소비자 끝점을 만듭니다.
경로 끝에 대상 끝점을 나타내는 생산자 끝점을 만듭니다.Creates a producer endpoint, which represents the target endpoint at the end of a route.
path가 전달 및 종료되는 메시지를 캡슐화하는 교환 개체를 만듭니다.Creates an exchange object, which encapsulates the messages passed and down the route.

38.1.1.4. 소비자

소비자 끝점은 요청을 사용합니다. 항상 경로 시작 시 표시되고 수신 요청을 수신하고 발신 응답을 디스패치하는 코드를 캡슐화합니다. 서비스 지향 관점에서 볼 때 소비자는 서비스를 나타냅니다.

소비자는 org.apache.camel.Consumer 인터페이스를 구현해야 합니다. 소비자를 구현할 때 사용할 수 있는 다양한 패턴이 있습니다. 이러한 패턴은 38.1.3절. “소비자 패턴 및 스레드” 에 설명되어 있습니다.

38.1.1.5. 생산자

생산자 끝점 은 요청을 생성합니다. 항상 경로 끝에 표시되고 발신 요청을 디스패치하고 들어오는 응답을 수신하는 코드를 캡슐화합니다. 서비스 지향 관점에서 생산자는 서비스 소비자를 나타냅니다.

생산자는 org.apache.camel.Producer 인터페이스를 구현해야 합니다. 필요한 경우 생산자를 구현하여 비동기식 처리 스타일을 지원할 수 있습니다. 자세한 내용은 38.1.4절. “비동기 처리” 을 참조하십시오.

38.1.1.6. Exchange

exchange 오브젝트는 관련 메시지 집합을 캡슐화합니다. 예를 들어 한 종류의 메시지 교환은 요청 메시지와 관련 응답으로 구성된 동기 호출입니다.

교환은 org.apache.camel.Exchange 인터페이스를 구현해야 합니다. 기본 구현은 많은 구성 요소 구현에 충분합니다. 그러나 추가 데이터를 교환과 연결하거나 교환이 추가 처리를 미리 정의하려는 경우 교환 구현을 사용자 정의하는 것이 유용할 수 있습니다.

38.1.1.7. 메시지

Exchange 오브젝트에는 두 가지 다른 메시지 슬롯이 있습니다.

현재 메시지를 message history로 지정합니다.
out message Cryostat- Cryostattemporarily 응답 메시지가 있습니다.

모든 메시지 유형은 동일한 Java 오브젝트 org.apache.camel.Message 로 표시됩니다. 메시지 구현을 항상 사용자 지정할 필요는 없습니다. 기본 구현인 DefaultMessage 가 일반적으로 적합합니다.

38.1.2. 경로에서 구성 요소 사용

38.1.2.1. 개요

Apache Camel 경로는 기본적으로 org.apache.camel.Processor 유형의 프로세서 파이프라인입니다. 메시지는 process() 메서드를 호출하여 노드에서 노드로 전달되는 교환 오브젝트 E 로 캡슐화됩니다. 프로세서 파이프라인의 아키텍처는 그림 38.2. “경로의 소비자 및 Producer 인스턴스” 에 설명되어 있습니다.

그림 38.2. 경로의 소비자 및 Producer 인스턴스

38.1.2.2. 소스 끝점

경로 시작 시 org.apache.camel.Consumer 오브젝트로 표시되는 소스 엔드포인트가 있습니다. 소스 끝점은 들어오는 요청 메시지를 수락하고 응답을 디스패치합니다. 경로를 구성할 때 Apache Camel은 38.1.1절. “구성 요소의 팩토리 패턴” 에 설명된 대로 끝점 URI에서 구성 요소 접두사를 기반으로 적절한 소비자 유형을 생성합니다.

38.1.2.3. 프로세서

파이프라인의 각 중간 노드는 프로세서 오브젝트( org.apache.camel.Processor 인터페이스 구현)로 표시됩니다. 표준 프로세서(예: 필터,throttler 또는 지연기)를 삽입하거나 고유한 사용자 지정 프로세서 구현을 삽입할 수 있습니다.

38.1.2.4. 대상 끝점

경로 끝에는 org.apache.camel.Producer 오브젝트로 표시되는 대상 엔드포인트가 있습니다. 프로세서 파이프라인의 끝에 제공되므로 생산자는 프로세서 오브젝트( org.apache.camel.Processor 인터페이스 구현)이기도 합니다. 대상 끝점은 발신 요청 메시지를 보내고 들어오는 응답을 수신합니다. 경로를 구성할 때 Apache Camel은 엔드포인트 URI에서 구성 요소 접두사를 기반으로 적절한 Producer 유형을 생성합니다.

38.1.3. 소비자 패턴 및 스레드

38.1.3.1. 개요

소비자를 구현하는 데 사용되는 패턴은 들어오는 교환을 처리하는 데 사용되는 스레딩 모델을 결정합니다. 소비자는 다음 패턴 중 하나를 사용하여 구현할 수 있습니다.

이벤트 중심 패턴 의 경우 소비자는 외부 스레드에 의해 구동됩니다.
예약된 폴링 패턴 Cryostat- Cryostat 소비자는 전용 스레드 풀로 구동됩니다.
폴링 패턴 Cryostat- type-threading 모델은 정의되지 않은 상태로 유지됩니다.

38.1.3.2. 이벤트 중심 패턴

이벤트 중심 패턴에서 애플리케이션의 다른 부분(일반적으로 타사 라이브러리)에서 소비자가 구현하는 메서드를 호출할 때 들어오는 요청 처리가 시작됩니다. 이벤트 중심 소비자의 좋은 예는 Apache Camel Cryostat 구성 요소이며, 여기서 이벤트는 Cryostat 라이브러리에서 시작합니다. Cryostat 라이브러리는 handleNotification() 메서드를 호출하여 요청 processing Cryostat를 시작합니다. 예 41.4. “CryostatConsumer 구현” 에서 자세한 내용을 참조하십시오.

그림 38.3. “이벤트 기반 소비자” 이벤트 기반 소비자 패턴의 개요를 보여줍니다. 이 예제에서는 notify() 메서드에 대한 호출에 의해 처리가 트리거되는 것으로 가정합니다.

그림 38.3. 이벤트 기반 소비자

이벤트 중심 소비자는 들어오는 요청을 다음과 같이 처리합니다.

소비자는 들어오는 이벤트를 수신하기 위한 방법을 구현해야 합니다( 그림 38.3. “이벤트 기반 소비자” 에서 이는 notify() 메서드로 표시됩니다. notify() 를 호출하는 스레드는 일반적으로 애플리케이션의 별도의 부분이므로 소비자의 스레드 정책은 외부적으로 구동됩니다.
예를 들어, Cryostat 소비자 구현의 경우 소비자는 NotificationListener.handleNotification() 메서드를 구현하여 Cryostat에서 알림을 수신합니다. 소비자 처리를 구동하는 스레드는 Cryostat 계층 내에 생성됩니다.
notify() 메서드의 본문에서 소비자는 먼저 들어오는 이벤트를 교환 오브젝트인 E 로 변환한 다음 경로의 다음 프로세서에서 process() 를 호출하여 교환 오브젝트를 인수로 전달합니다.

38.1.3.3. 예약된 폴링 패턴

예약된 폴링 패턴에서 소비자는 요청이 도착했는지 여부를 정기적으로 확인하여 들어오는 요청을 검색합니다. 요청 확인은 java.util.concurrent 라이브러리에서 제공하는 표준 패턴인 예약된 executor 서비스인 기본 제공 타이머 클래스에 의해 자동으로 예약됩니다. 예약된 executor 서비스는 시간 간격에 따라 특정 작업을 실행하고 작업 인스턴스를 실행하는 데 사용되는 스레드 풀을 관리합니다.

그림 38.4. “예약된 Poll 소비자” 예약된 폴링 소비자 패턴의 개요를 보여줍니다.

그림 38.4. 예약된 Poll 소비자

예약된 폴링 소비자는 다음과 같이 들어오는 요청을 처리합니다.

예약된 executor 서비스에는 소비자 처리를 시작하는 데 사용할 수 있는 스레드 풀이 있습니다. 예약된 각 시간 간격이 경과한 후 예약된 executor 서비스는 풀에서 사용 가능한 스레드를 가져옵니다(기본적으로 풀에는 5개의 스레드가 있음). 사용 가능한 스레드가 있는 경우 해당 스레드를 사용하여 소비자에서 poll() 메서드를 호출합니다.
소비자의 poll() 메서드는 들어오는 요청의 처리를 트리거하기 위한 것입니다. poll() 메서드의 본문에서 소비자는 들어오는 메시지를 검색하려고 시도합니다. 요청을 사용할 수 없는 경우 poll() 메서드는 즉시 반환됩니다.
요청 메시지를 사용할 수 있는 경우 소비자는 이를 교환 오브젝트에 삽입한 다음 경로의 다음 프로세서에서 process() 를 호출하여 교환 오브젝트를 인수로 전달합니다.

38.1.3.4. 폴링 패턴

폴링 패턴에서 타사가 소비자의 폴링 방법 중 하나를 호출할 때 들어오는 요청 처리가 시작됩니다.

receive()
receiveNoWait()
receive(긴 시간)

폴링 방법에서 호출을 시작하기 위한 정확한 메커니즘을 정의하는 구성 요소 구현에 따라 다릅니다. 이 메커니즘은 폴링 패턴에 지정되지 않습니다.

그림 38.5. “폴링 소비자” 폴링 소비자 패턴의 개요를 보여줍니다.

그림 38.5. 폴링 소비자

폴링 소비자는 수신 요청을 다음과 같이 처리합니다.

들어오는 요청 처리는 소비자의 폴링 방법 중 하나가 호출될 때마다 시작됩니다. 이러한 폴링 방법을 호출하는 메커니즘은 구성 요소 구현에 의해 정의됩니다.
receive() 메서드의 본문에서 소비자는 들어오는 요청 메시지를 검색하려고 시도합니다. 현재 사용할 수 있는 메시지가 없는 경우 해당 동작은 호출된 수신 방법에 따라 달라집니다.
- receiveNoWait() 즉시 반환
- receive(long timeout) 은 지정된 시간 초과 간격을 대기합니다.^[2] 반환하기 전
- receive() 는 메시지가 수신될 때까지 대기합니다.
요청 메시지를 사용할 수 있는 경우 소비자는 이를 교환 오브젝트에 삽입한 다음 경로의 다음 프로세서에서 process() 를 호출하여 교환 오브젝트를 인수로 전달합니다.

38.1.4. 비동기 처리

38.1.4.1. 개요

생산자 끝점은 일반적으로 교환을 처리할 때 동기 패턴을 따릅니다. 파이프라인의 이전 프로세서가 생산자에서 process() 를 호출할 때, process() 메서드는 응답을 수신할 때까지 차단됩니다. 이 경우 프로세서의 스레드는 생산자가 요청을 보내고 응답을 수신할 때까지 차단된 상태로 유지됩니다.

그러나 이전 프로세서를 생산자에서 분리하여 프로세서의 스레드가 즉시 릴리스되고 process() 호출이 차단 되지 않는 경우가 있습니다. 이 경우 이전 프로세서에 process() 메서드의 비차단 버전을 호출하는 옵션을 제공하는 비동기 패턴을 사용하여 생산자를 구현해야 합니다.

다양한 구현 옵션에 대한 개요를 제공하기 위해 이 섹션에서는 생산자 엔드포인트를 구현하기 위한 동기 및 비동기 패턴에 대해 설명합니다.

38.1.4.2. 동기 생산자

그림 38.6. “동기 Producer” 는 생산자가 교환 처리를 완료할 때까지 이전 프로세서가 차단되는 동기 생산자의 개요를 보여줍니다.

그림 38.6. 동기 Producer

동기 생산자는 다음과 같이 교환을 처리합니다.

파이프라인의 이전 프로세서는 생산자의 동기 프로세스() 메서드를 호출하여 동기 처리를 시작합니다. 동기 프로세스() 메서드는 단일 교환 인수를 사용합니다.
process() 메서드의 본문에서 생산자는 요청(메시지 내)을 엔드포인트로 보냅니다.
교환 패턴에서 필요한 경우 생산자는 응답(아웃 메시지)이 끝점에서 수신될 때까지 기다립니다. 이 단계에서는 process() 메서드가 무기한 차단될 수 있습니다. 그러나 교환 패턴이 응답을 요청하지 않으면 process() 메서드는 요청을 보낸 직후 반환할 수 있습니다.
process() 메서드가 반환되면 exchange 오브젝트에 동기 호출( Out 메시지 메시지)의 응답이 포함됩니다.

38.1.4.3. 비동기 생산자

그림 38.7. “비동기 Producer” 생산자가 하위 스레드로 교환을 처리하고 이전 프로세서는 상당한 시간 동안 차단되지 않는 비동기 생산자의 개요를 보여줍니다.

그림 38.7. 비동기 Producer

비동기 생산자는 다음과 같이 교환을 처리합니다.

프로세서에서 비동기 process() 메서드를 호출하려면 먼저 경로의 반환 부분에 대한 교환 처리를 담당하는 비동기 콜백 오브젝트를 생성해야 합니다. 비동기 콜백의 경우 프로세서는 AsyncCallback 인터페이스에서 상속하는 클래스를 구현해야 합니다.
프로세서는 생산자의 비동기 process() 메서드를 호출하여 비동기 처리를 시작합니다. 비동기 process() 메서드는 두 개의 인수를 사용합니다.
- 교환 오브젝트
- 동기 콜백 오브젝트
process() 메서드의 본문에서 생산자는 처리 코드를 캡슐화하는 Runnable 오브젝트를 생성합니다. 그런 다음 생산자는 이 실행 가능 오브젝트의 실행을 하위 스레드에 위임합니다.
비동기 process() 메서드는 반환되므로 프로세서의 스레드가 확보됩니다. 교환 처리는 별도의 하위 스레드에서 계속됩니다.
Runnable 오브젝트는 In 메시지를 엔드포인트로 전송합니다.
교환 패턴에서 필요한 경우 Runnable 오브젝트는 응답(Out 또는 Fault 메시지)이 끝점에서 수신될 때까지 대기합니다. Runnable 오브젝트는 응답이 수신될 때까지 차단됩니다.
응답이 도착하면 Runnable 개체는 응답(Out message)을 교환 오브젝트에 삽입한 다음 비동기 콜백 오브젝트에서 done() 을 호출합니다. 그런 다음 비동기 콜백은 응답 메시지(하위 스레드에서 실행)를 처리합니다.

^[2] 시간 초과 간격은 일반적으로 밀리초 단위로 지정됩니다.