DSL( Domain Specific Language )을 사용하려면 RouteBuilder 클래스를 확장하고 라우팅 규칙을 정의하는 configure() 메서드를 재정의합니다.

필요한 만큼 RouteBuilder 클래스를 정의할 수 있습니다. 각 클래스는 한 번 인스턴스화되며 CamelContext 오브젝트에 등록됩니다. 일반적으로 각 RouteBuilder 오브젝트의 라이프사이클은 라우터를 배포하는 컨테이너에서 자동으로 관리합니다.

라우터 개발자로서 핵심 작업은 RouteBuilder 클래스를 하나 이상 구현하는 것입니다. 다음 두 가지 대체 RouteBuilder 클래스가 있습니다.

RouteBuilder 클래스는 라우팅 규칙을 시작하는 데 사용되는 메서드를 정의합니다(예: from(), intercept(), exception()).

예 1.1. “RouteBuilder 클래스 구현” 최소 RouteBuilder 구현을 표시합니다. configure() 메서드 본문에는 라우팅 규칙이 포함되어 있으며 각 규칙은 단일 Java 문입니다.

import org.apache.camel.builder.RouteBuilder;

public class MyRouteBuilder extends RouteBuilder {

public void configure() {
  // Define routing rules here:
  from("file:src/data?noop=true").to("file:target/messages");

  // More rules can be included, in you like.
  // ...
}
}

의 규칙 형식 (URL1).to(URL2) 은 디렉토리 src/data 에서 파일을 읽고 디렉터리 target/messages 디렉터리에 전송하도록 라우터에 지시합니다. 옵션 ?noop=true 는 라우터가 src/data 디렉토리에 있는 소스 파일을 유지(삭제하지 않음)하도록 지시합니다.

DSL(Domain Specific Language)은 특수한 목적을 위해 설계된 최소 언어입니다. DSL은 논리적으로 완료할 필요는 없지만 선택한 도메인에서 문제를 적절하게 설명하기 위해 표현 가능한 권한이 필요합니다. 일반적으로 DSL에는 전용 구문 분석기, 인터프리터 또는 컴파일러가 필요하지 않습니다. DSL은 기존 객체 지향 호스트 언어의 상단에 파키백을 할 수 있으며 호스트 언어 API의 구성에 DSL 구문이 깔끔하게 맵을 제공했습니다.

가상 DSL에서 다음과 같은 명령 시퀀스를 고려하십시오.

command01;
command02;
command03;

다음과 같이 이러한 명령을 Java 메서드 호출에 매핑할 수 있습니다.

command01().command02().command03()

블록을 Java 메서드 호출에 매핑할 수도 있습니다. 예를 들면 다음과 같습니다.

command01().startBlock().command02().command03().endBlock()

DSL 구문은 호스트 언어 API의 데이터 유형에 의해 암시적으로 정의됩니다. 예를 들어 Java 메서드의 반환 유형은 다음에 합법적으로 호출할 수 있는 방법을 결정합니다( DSL의 다음 명령과 동일함).

Apache Camel은 라우팅 규칙을 정의하는 라우터 DSL 을 정의합니다. 이 DSL을 사용하여 RouteBuilder.configure() 구현의 본문에 규칙을 정의할 수 있습니다. 그림 1.1. “로컬 라우팅 규칙” 는 로컬 라우팅 규칙을 정의하는 기본 구문의 개요를 보여줍니다.

그림 1.1. 로컬 라우팅 규칙

로컬 규칙은 항상 라우팅 규칙의 메시지 소스(소비자 끝점)를 지정하는 from("EndpointURL") 메서드로 시작합니다. 그런 다음 임의로 긴 프로세서 체인을 규칙에 추가할 수 있습니다(예: filter()). 일반적으로 규칙을 통과하는 메시지의 대상(프로덕터끝점)을 지정하는 to("EndpointURL") 메서드로 규칙을 종료합니다. 그러나 to() 로 규칙을 종료할 필요는 없습니다. 규칙에서 메시지 대상을 지정하는 다른 방법이 있습니다.

로컬 규칙은 항상 from("EndpointURL") 을 사용하여 소비자 끝점을 정의하여 시작하고 일반적으로 (항상은 아님) to("EndpointURL") 를 사용하여 생산자 엔드포인트를 정의하여 끝납니다. 엔드포인트 URL인 EndpointURL 은 배포 시 구성된 구성 요소 중 하나를 사용할 수 있습니다. 예를 들어 파일 엔드포인트, file:MyMessageDirectory, Apache CXF 엔드포인트, cxf:MyServiceName 또는 Apache ActiveMQ 엔드포인트 activemq:queue:MyQName 을 사용할 수 있습니다. 구성 요소 유형의 전체 목록은 Apache Camel 구성 요소 참조를 참조하십시오.

교환 오브젝트는 메타데이터에 의해 보강된 메시지로 구성됩니다. 교환은 라우팅 규칙을 통해 메시지가 전파되는 표준 형식이므로 Apache Camel에서 교환은 매우 중요합니다. 교환의 주요 구성 요소는 다음과 같습니다.

Exchange 개체를 사용하면 다양한 메시지 교환 패턴에 대한 메시지 처리를 쉽게 일반화할 수 있습니다. 예를 들어 비동기 프로토콜은 소비자 끝점에서 생산자 엔드포인트( InOnly MEP)로 이동하는 단일 메시지로 구성된 MEP를 정의할 수 있습니다. 반면 RPC 프로토콜은 요청 메시지와 응답 메시지( InOut MEP)로 구성된 MEP를 정의할 수 있습니다. 현재 Apache Camel은 다음 MEP를 지원합니다.

여기서 이러한 메시지 교환 패턴은 열거 유형인 org.apache.camel.ExchangePattern 의 상수로 표시됩니다.

경우에 따라 여러 교환 인스턴스를 캡슐화하는 단일 교환을 사용하는 것이 유용합니다. 이를 위해 그룹화된 교환을 사용할 수 있습니다. 그룹화된 교환은 기본적으로 Exchange.GROUPED_EXCHANGE 교환 속성에 저장된 java.util.List of Exchange 개체를 포함하는 교환 인스턴스입니다. 그룹화된 교환을 사용하는 방법에 대한 예제는 8.5절. “수집기” 를 참조하십시오.

프로세서는 경로를 통과하는 교환 스트림에 액세스하고 수정할 수 있는 경로의 노드입니다. 프로세서에서는 동작을 수정하는 표현식 또는 서술자 인수를 사용할 수 있습니다. 예를 들어 그림 1.1. “로컬 라우팅 규칙” 에 표시된 규칙에는 xpath() 서술자를 인수로 사용하는 filter() 프로세서가 포함되어 있습니다.

식(문자열 또는 기타 데이터 형식에 평가) 및 서술자(true 또는 false로 평가)는 기본 제공 프로세서 유형에 대한 인수로 자주 발생합니다. 예를 들어 다음 필터 규칙은 foo 헤더가 값 표시줄 과 동일한 경우에만 메시지에서 전파됩니다.

from("seda:a").filter(header("foo").isEqualTo("bar")).to("seda:b");

여기서 필터가 서술자인 header("foo").isEqualTo("bar") 에 의해 검증됩니다. 메시지 콘텐츠를 기반으로 보다 정교한 서술자 및 표현식을 구성하려면 표현식 및 서술자 언어 중 하나를 사용할 수 있습니다( II 부. 라우팅 표현식 및 서술자 언어참조).

다음 XML 스키마의 namespace에 XML DSL between- Cryostatbelongs를 정의하는 라우터 스키마 Cryostat- Cryostat:

http://camel.apache.org/schema/spring

라우터 스키마의 위치는 일반적으로 Apache 웹 사이트의 최신 버전의 스키마를 참조하는 http://camel.apache.org/schema/spring/camel-spring.xsd 로 지정됩니다. 예를 들어 Apache Camel Spring 파일의 루트 빈 요소는 일반적으로 예 1.2. “라우터 스키마 위치 지정” 에 표시된 대로 구성됩니다.

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:camel="http://camel.apache.org/schema/spring"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="
       http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
       http://camel.apache.org/schema/spring http://camel.apache.org/schema/spring/camel-spring.xsd">

  <camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
    <!-- Define your routing rules here -->
  </camelContext>
</beans>

런타임에 Apache Camel은 Spring 파일에 지정된 스키마 위치에서 라우터 스키마를 다운로드하지 않습니다. 대신 Apache Camel은 camel-spring JAR 파일의 루트 디렉토리에서 스키마 사본을 자동으로 선택합니다. 이렇게 하면 Spring 파일을 구문 분석하는 데 사용되는 스키마의 버전이 항상 현재 런타임 버전과 일치합니다. Apache 웹 사이트에 게시된 최신 버전의 스키마가 현재 사용 중인 런타임 버전과 일치하지 않을 수 있으므로 이는 중요합니다.

일반적으로 전체 기능을 갖춘 XML 편집기를 사용하여 Spring 파일을 편집하는 것이 좋습니다. XML 편집기의 자동 완성 기능을 사용하면 라우터 스키마를 준수하는 XML을 더 쉽게 작성할 수 있으며 XML이 잘못 구성된 경우 편집기는 즉시 경고할 수 있습니다.

XML 편집기는 일반적으로 xsi:schemaLocation 특성에 지정하는 위치에서 스키마를 다운로드하는 데 의존합니다. 편집하는 동안 올바른 스키마 버전을 사용하고 있는지 확인하려면 일반적으로 camel-spring.xsd 파일의 특정 버전을 선택하는 것이 좋습니다. 예를 들어 Apache Camel의 2.3 버전에 대한 Spring 파일을 편집하려면 다음과 같이 beans 요소를 수정할 수 있습니다.

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:camel="http://camel.apache.org/schema/spring"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="
       http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
       http://camel.apache.org/schema/spring http://camel.apache.org/schema/spring/camel-spring-2.3.0.xsd">
...

편집을 완료하면 기본 camel-spring.xsd 로 다시 변경합니다. 현재 다운로드할 수 있는 스키마 버전을 확인하려면 웹 페이지인 http://camel.apache.org/schema/spring 로 이동합니다.

Apache Camel 끝점은 경로에 있는 메시지의 소스 및 싱크입니다. 끝점은 매우 일반적인 종류의 빌딩 블록입니다. 충족해야 하는 유일한 요구 사항은 메시지 소스(프로덕션 끝점) 또는 메시지 싱크(컨트리스팅)로 작동한다는 것입니다. 따라서 HTTP와 같은 프로토콜 지원 끝점에서 정기적으로 더미 메시지를 생성하는 Quartz와 같은 간단한 타이머 끝점에 이르기까지 Apache Camel에서 지원되는 다양한 끝점 유형이 있습니다. Apache Camel의 주요 강점 중 하나는 새 엔드포인트 유형을 구현하는 사용자 지정 구성 요소를 비교적 쉽게 추가할 수 있다는 것입니다.

끝점은 다음과 같은 일반적인 형식을 갖는 끝점 URI 로 식별됩니다.

scheme:contextPath[?queryOptions]

URI 스키마 는 http 와 같은 프로토콜을 식별하고 contextPath 는 프로토콜에서 해석되는 URI 세부 정보를 제공합니다. 또한 대부분의 스키마를 사용하면 다음 형식으로 지정된 쿼리 옵션인 queryOptions 를 정의할 수 있습니다.

?option01=value01&option02=value02&...

예를 들어 다음 HTTP URI를 사용하여 Google 검색 엔진 페이지에 연결할 수 있습니다.

http://www.google.com

다음 File URI를 사용하여 C:\temp\src\data 디렉터리에 나타나는 모든 파일을 읽을 수 있습니다.

file://C:/temp/src/data

모든 스키마 가 프로토콜을 나타내는 것은 아닙니다. 경우에 따라 스키마 는 타이머와 같은 유용한 유틸리티에 대한 액세스를 제공합니다. 예를 들어 다음 Timer 엔드포인트 URI는 1초마다 교환을 생성합니다(=1000밀리초). 이를 사용하여 경로의 활동을 예약할 수 있습니다.

timer://tickTock?period=1000

경우에 따라 끝점 URI가 제공된 모든 관련 구성 정보로 인해 상당히 길어질 수 있습니다. JBoss Fuse 6.2 이상에서는 긴 URI 작업을 보다 쉽게 관리할 수 있도록 두 가지 접근 방식을 사용할 수 있습니다.

Apache Camel 구성 요소의 많은에는 일정 기간(예: 시간 초과 값을 지정하는 등) 값이 있는 옵션이 있습니다. 기본적으로 이러한 기간 옵션은 일반적으로 밀리 초의 기간으로 해석되는 순수수로 지정됩니다. 그러나 Apache Camel은 기간 동안 더 읽기 쉬운 구문을 지원하므로 시간, 분, 초 단위로 기간을 표시할 수 있습니다. 공식적으로 사람이 읽을 수 있는 기간은 다음 구문을 따르는 문자열입니다.

[NHour(h|hour)][NMin(m|minute)][NSec(s|second)]

대괄호 안에 있는 각 용어( [] )는 선택 사항이며 표기법 (A|B) 은 A 및 B 가 대안임을 나타냅니다.

예를 들어 다음과 같이 45 분 기간을 사용하여 타이머 끝점을 구성할 수 있습니다.

from("timer:foo?period=45m")
  .to("log:foo");

다음과 같이 시간, 분 및 두 번째 단위의 임의의 조합을 사용할 수도 있습니다.

from("timer:foo?period=1h15m")
  .to("log:foo");
from("timer:bar?period=2h30s")
  .to("log:bar");
from("timer:bar?period=3h45m58s")
  .to("log:bar");

기본적으로 URI에 지정하는 옵션 값은 자동으로 URI로 인코딩됩니다. 경우에 따라 이는 바람직하지 않은 동작입니다. 예를 들어 암호 옵션을 설정할 때 URI 인코딩 없이 원시 문자 문자열을 전송하는 것이 좋습니다.

구문, RAW(RawValue) 로 옵션 값을 지정하여 URI 인코딩을 전환할 수 있습니다. 예를 들면 다음과 같습니다.

from("SourceURI")
 .to("ftp:joe@myftpserver.com?password=RAW(se+re?t&23)&binary=true")

이 예에서 password 값은 리터럴 값 se+re?t&23 으로 전송됩니다.

일부 끝점 URI 옵션은 Java 열거 상수에 매핑됩니다. 예를 들어 로그 구성 요소의 수준 옵션은 enum 값, INFO,WARN,ERROR 등을 사용할 수 있습니다. 이 유형 변환은 대소문자를 구분하지 않으므로 다음 대안을 사용하여 로그 생산자 끝점의 로깅 수준을 설정할 수 있습니다.

<to uri="log:foo?level=info"/>
<to uri="log:foo?level=INfo"/>
<to uri="log:foo?level=InFo"/>

Camel 2.17에서 XSLT와 같은 리소스 기반 구성 요소는 ref: 를 접두사로 사용하여 레지스트리에서 리소스 파일을 로드할 수 있습니다.

예를 들어 ifmyvelocityscriptbean 및 mysimplescriptbean 은 레지스트리에 있는 두 빈 ID입니다.

Velocity endpoint:
------------------
from("velocity:ref:myvelocityscriptbean").<rest_of_route>.

Language endpoint (for invoking a scripting language):
-----------------------------------------------------
from("direct:start")
  .to("language:simple:ref:mysimplescriptbean")
 Where Camel implicitly converts the bean to a String.

각 URI 스키마 는 Apache Camel 구성 요소가 기본적으로 엔드포인트 팩토리인 Apache Camel 구성 요소에 매핑됩니다. 즉, 특정 유형의 엔드포인트를 사용하려면 런타임 컨테이너에 해당 Apache Camel 구성 요소를 배포해야 합니다. 예를 들어 JMS 엔드포인트를 사용하려면 컨테이너에 JMS 구성 요소를 배포합니다.

Apache Camel은 다양한 전송 프로토콜 및 타사 제품과 애플리케이션을 통합할 수 있는 다양한 구성 요소를 제공합니다. 예를 들어 일반적으로 사용되는 구성 요소 중 일부는 File, JMS, CXF (Web services), HTTP,kafkaty, Direct 및 Mock입니다. 지원되는 구성 요소의 전체 목록은 Apache Camel 구성 요소 설명서 를 참조하십시오.

대부분의 Apache Camel 구성 요소는 Camel 코어에 별도로 패키지됩니다. Maven을 사용하여 애플리케이션을 빌드하는 경우 관련 구성 요소 아티팩트에 대한 종속성을 추가하여 쉽게 애플리케이션에 구성 요소(및 타사 종속 항목)를 추가할 수 있습니다. 예를 들어 HTTP 구성 요소를 포함하려면 다음 Maven 종속성을 프로젝트 POM 파일에 추가합니다.

<!-- Maven POM File -->
  <properties>
    <camel-version>{camelFullVersion}</camel-version>
    ...
  </properties>

  <dependencies>
    ...
    <dependency>
      <groupId>org.apache.camel</groupId>
      <artifactId>camel-http</artifactId>
      <version>${camel-version}</version>
    </dependency>
    ...
  </dependencies>

다음 구성 요소는 Camel 코어( camel-core 아티팩트에서)에 기본 제공되므로 항상 사용할 수 있습니다.

소비자 끝점 은 경로 시작 시 표시되는 끝점입니다(즉, from() DSL 명령에서). 즉, 소비자 끝점은 경로에서 처리를 시작합니다. 이는 새로운 교환 인스턴스(일반적으로 수신 또는 획득한 일부 메시지에 따라)를 생성하고 나머지 경로에서 교환을 처리하는 스레드를 제공합니다.

예를 들어 다음 JMS 소비자 끝점은 결제 대기열에서 메시지를 가져와서 경로에서 처리합니다.

from("jms:queue:payments")
  .process(SomeProcessor)
  .to("TargetURI");

또는 이와 동등한 경우 Spring XML:

<camelContext id="CamelContextID"
              xmlns="http://camel.apache.org/schema/spring">
  <route>
    <from uri="jms:queue:payments"/>
    <process ref="someProcessorId"/>
    <to uri="TargetURI"/>
  </route>
</camelContext>

일부 구성 요소는 소비자만 사용할 수 있습니다. 즉, 소비자 끝점을 정의하는 데만 사용할 수 있습니다. 예를 들어 Quartz 구성 요소는 소비자 끝점을 정의하는 데 독점적으로 사용됩니다. 다음 Quartz 엔드포인트는 1초마다 (1000밀리초) 이벤트를 생성합니다.

from("quartz://secondTimer?trigger.repeatInterval=1000")
  .process(SomeProcessor)
  .to("TargetURI");

원하는 경우 fromF() Java DSL 명령을 사용하여 엔드포인트 URI를 포맷된 문자열로 지정할 수 있습니다. 예를 들어 사용자 이름과 암호를 FTP 끝점의 URI로 대체하려면 다음과 같이 Java에 경로를 작성할 수 있습니다.

fromF("ftp:%s@fusesource.com?password=%s", username, password)
  .process(SomeProcessor)
  .to("TargetURI");

여기서 첫 번째 발생 %s 는 username 문자열의 값으로 교체되고 두 번째 발생 %s 가 password 문자열로 교체됩니다. 이 문자열 형식 지정 메커니즘은 String.format() 에 의해 구현되며 C Cryostat () 함수에서 제공하는 포맷과 유사합니다. 자세한 내용은 java.util.Formatter 를 참조하십시오.

생산자 엔드포인트 는 경로의 중간 또는 끝에 표시되는 엔드포인트입니다(예: to() DSL 명령). 즉, 생산자 끝점은 기존 교환 오브젝트를 수신하고 교환 내용을 지정된 엔드포인트로 보냅니다.

예를 들어 다음 JMS 생산자 끝점은 현재 교환의 내용을 지정된 JMS 큐로 푸시합니다.

from("SourceURI")
  .process(SomeProcessor)
  .to("jms:queue:orderForms");

Spring XML과 동일합니다.

<camelContext id="CamelContextID" xmlns="http://camel.apache.org/schema/spring">
  <route>
    <from uri="SourceURI"/>
    <process ref="someProcessorId"/>
    <to uri="jms:queue:orderForms"/>
  </route>
</camelContext>

일부 구성 요소는 생산자만, 즉 생산자 끝점을 정의하는 데만 사용할 수 있습니다. 예를 들어 HTTP 끝점은 생산자 엔드포인트를 정의하는 데만 사용됩니다.

from("SourceURI")
  .process(SomeProcessor)
  .to("http://www.google.com/search?hl=en&q=camel+router");

원하는 경우 toF() Java DSL 명령을 사용하여 엔드포인트 URI를 포맷된 문자열로 지정할 수 있습니다. 예를 들어 사용자 지정 Google 쿼리를 HTTP URI로 대체하려면 다음과 같이 Java에서 경로를 작성할 수 있습니다.

from("SourceURI")
  .process(SomeProcessor)
  .toF("http://www.google.com/search?hl=en&q=%s", myGoogleQuery);

여기서 %s 발생은 사용자 지정 쿼리 문자열인 myGoogleQuery 로 교체됩니다. 자세한 내용은 java.util.Formatter 를 참조하십시오.

라우터에서 단순히 소비자 엔드포인트를 생산자 엔드포인트에 연결하는 것보다 더 흥미로운 작업을 수행할 수 있도록 경로에 프로세서를 추가할 수 있습니다. 프로세서는 라우팅 규칙에 삽입하여 규칙을 통과하는 메시지를 임의의 처리를 수행할 수 있는 명령입니다. Apache Camel은 표 1.1. “Apache Camel 프로세서” 와 같이 다양한 프로세서를 제공합니다.

경로에서 프로세서를 사용하는 방법에 대한 몇 가지 아이디어를 얻으려면 다음 예제를 참조하십시오.

choice() 프로세서는 들어오는 메시지를 대체 생산자 엔드포인트로 라우팅하는 데 사용되는 조건부 명령문입니다. 각 대체 생산자 끝점 앞에는 서술자 인수를 사용하는 when() 메서드 앞에 옵니다. 서술자가 true이면 다음 대상이 선택되고, 처리는 규칙에서 다음 when() 메서드로 진행됩니다. 예를 들어 다음 choice() 프로세서는 Predicate1 및 Predicate2 의 값에 따라 수신 메시지를 Target1,Target2 또는 Target3 으로 보냅니다.

from("SourceURL")
    .choice()
        .when(Predicate1).to("Target1")
        .when(Predicate2).to("Target2")
        .otherwise().to("Target3");

Spring XML과 동일합니다.

<camelContext id="buildSimpleRouteWithChoice" xmlns="http://camel.apache.org/schema/spring">
  <route>
    <from uri="SourceURL"/>
    <choice>
      <when>
        <!-- First predicate -->
        <simple>header.foo = 'bar'</simple>
        <to uri="Target1"/>
      </when>
      <when>
        <!-- Second predicate -->
        <simple>header.foo = 'manchu'</simple>
        <to uri="Target2"/>
      </when>
      <otherwise>
        <to uri="Target3"/>
      </otherwise>
    </choice>
  </route>
</camelContext>

Java DSL에는 endChoice() 명령을 사용해야 할 수 있는 특수한 경우가 있습니다. 일부 표준 Apache Camel 프로세서를 사용하면 특수 하위 복제를 사용하여 추가 매개 변수를 지정할 수 있으며 일반적으로 end() 명령으로 종료되는 추가 중첩 수준을 효과적으로 열 수 있습니다. 예를 들어 로드 밸런서 절을 loadBalance().to("mock:foo").to("mock:bar").end() 로 지정할 수 있습니다. 그러나 로드 밸런서 절이 선택 조건에 포함된 경우 다음과 같이 endChoice() 명령을 사용하여 절을 종료해야 합니다.

from("direct:start")
    .choice()
        .when(bodyAs(String.class).contains("Camel"))
            .loadBalance().roundRobin().to("mock:foo").to("mock:bar").endChoice()
        .otherwise()
            .to("mock:result");

filter() 프로세서는 관심 없는 메시지가 생산자 엔드포인트에 도달하지 못하도록 하는 데 사용할 수 있습니다. 단일 서술자 인수가 필요합니다. 서술자가 true이면 메시지 교환이 생산자를 통해 허용됩니다. 서술자가 false이면 메시지 교환이 차단됩니다. 예를 들어 다음 필터는 들어오는 메시지에 헤더를 포함하지 않는 한 메시지 교환을 차단합니다. foo 값은 bar 와 같습니다.

from("SourceURL").filter(header("foo").isEqualTo("bar")).to("TargetURL");

Spring XML과 동일합니다.

<camelContext id="filterRoute" xmlns="http://camel.apache.org/schema/spring">
  <route>
    <from uri="SourceURL"/>
    <filter>
      <simple>header.foo = 'bar'</simple>
      <to uri="TargetURL"/>
    </filter>
  </route>
</camelContext>

throttle() 프로세서는 생산자 엔드포인트가 과부하되지 않도록 합니다. throttler는 초당 전달할 수 있는 메시지 수를 제한하여 작동합니다. 들어오는 메시지가 지정된 속도를 초과하면 throttler는 버퍼에서 초과 메시지를 누적하고 생산자 엔드포인트로 더 느리게 전송합니다. 예를 들어 처리량 속도를 초당 100개 메시지로 제한하려면 다음 규칙을 정의할 수 있습니다.

from("SourceURL").throttle(100).to("TargetURL");

Spring XML과 동일합니다.

<camelContext id="throttleRoute" xmlns="http://camel.apache.org/schema/spring">
  <route>
    <from uri="SourceURL"/>
    <throttle maximumRequestsPerPeriod="100" timePeriodMillis="1000">
      <to uri="TargetURL"/>
    </throttle>
  </route>
</camelContext>

여기에 설명된 표준 프로세서 중 어느 것도 필요한 기능을 제공하지 않으면 항상 고유한 사용자 지정 프로세서를 정의할 수 있습니다. 사용자 지정 프로세서를 만들려면 org.apache.camel.Processor 인터페이스를 구현하고 process() 메서드를 재정의하는 클래스를 정의합니다. 다음 사용자 지정 프로세서인 MyProcessor 는 들어오는 메시지에서 foo 라는 헤더를 제거합니다.

public class MyProcessor implements org.apache.camel.Processor {
public void process(org.apache.camel.Exchange exchange) {
  inMessage = exchange.getIn();
  if (inMessage != null) {
      inMessage.removeHeader("foo");
  }
}
};

사용자 지정 프로세서를 라우터 규칙에 삽입하려면 프로세스에 프로세서를 삽입하는 일반적인 메커니즘을 제공하는 process() 메서드를 호출합니다. 예를 들어 다음 규칙은 예 1.3. “사용자 지정 프로세서 클래스 구현” 에 정의된 프로세서를 호출합니다.

org.apache.camel.Processor myProc = new MyProcessor();

from("SourceURL").process(myProc).to("TargetURL");

Apache Camel에서 파이프라이닝은 경로 정의에서 노드 연결을 위한 주요 패러다임입니다. 파이프라인 개념은 UNIX 운영 체제 사용자에게 가장 익숙할 수 있으며 운영 체제 명령을 결합하는 데 사용됩니다. 예를 들어 ls | more 는 디렉토리 목록 ls 를 page-scrolling 유틸리티로 파이프하는 명령의 예입니다. 파이프라인의 기본 개념은 한 명령의 출력이 다음 명령의 입력으로 제공됨입니다. 경로의 경우 자연 유추는 한 프로세서의 외부 메시지가 다음 프로세서의 In 메시지로 복사되는 것입니다.

초기 엔드포인트를 제외한 경로의 모든 노드는 org.apache.camel.Processor 인터페이스에서 상속한다는 점에서 프로세서 입니다. 즉, 프로세서는 DSL 경로의 기본 빌딩 블록을 구성합니다. 예를 들어 filter(), delayer(), setBody(), setHeader() 및 to() 와 같은 DSL 명령은 모두 프로세서를 나타냅니다. 프로세서가 경로를 구축하기 위해 함께 연결하는 방법을 고려할 때 두 가지 처리 방법을 구분하는 것이 중요합니다.

첫 번째 접근 방식은 프로세서가 그림 2.1. “메시지 내 수정 프로세서” 와 같이 교환의 In 메시지를 간단히 수정하는 것입니다. 이 경우 교환 의 외부 메시지는 null 로 유지됩니다.

그림 2.1. 메시지 내 수정 프로세서

다음 경로는 billingSystem 제목을 추가(또는 수정)하여 현재 In 메시지를 수정하는 setHeader() 명령을 보여줍니다.

from("activemq:orderQueue")
    .setHeader("BillingSystem", xpath("/order/billingSystem"))
    .to("activemq:billingQueue");

두 번째 접근 방식은 프로세서가 그림 2.2. “프로세서에서 출력 메시지 생성” 에 표시된 대로 처리 결과를 나타내는 Out 메시지를 생성하는 위치입니다.

그림 2.2. 프로세서에서 출력 메시지 생성

다음 경로는 문자열 DummyBody 가 포함된 메시지 본문을 사용하여 Out 메시지를 생성하는 transform() 명령을 보여줍니다.

from("activemq:orderQueue")
    .transform(constant("DummyBody"))
    .to("activemq:billingQueue");

여기서 constant("DummyBody") 는 상수 표현식을 나타냅니다. transform() 의 인수가 표현식 유형이어야 하므로 문자열 DummyBody 를 직접 전달할 수 없습니다.

그림 2.3. “InOnly 교환을 위한 샘플 Pipeline” InOnly 교환을 위한 프로세서 파이프라인의 예를 보여줍니다. 프로세서 B 및 C는 출력 메시지를 생성하는 동안 In 메시지를 수정하여 작동합니다. 경로 빌더는 다음과 같이 프로세서를 함께 연결합니다. 특히 프로세서 B 및 C는 파이프라인 형태로 서로 연결되어 있습니다. 즉, 프로세서 B의 아웃 메시지가 프로세서 C로 전달되기 전에 In 메시지로 이동되고 프로세서 C의 아웃 메시지는 생산자 엔드포인트로 전환되기 전에 In 메시지로 이동합니다. 따라서 프로세서의 출력 및 입력은 그림 2.3. “InOnly 교환을 위한 샘플 Pipeline” 에 표시된 대로 연속 파이프라인에 결합됩니다.

그림 2.3. InOnly 교환을 위한 샘플 Pipeline

Apache Camel은 기본적으로 파이프라인 패턴을 사용하므로 경로에 파이프라인을 생성하는 데 특수 구문을 사용할 필요가 없습니다. 예를 들어 다음 경로는 userdataQueue 대기열에서 메시지를 가져오고 Velocity 템플릿을 통해 메시지를 파이프한 다음(텍스트 형식으로 고객 주소를 생성하기 위해) 결과 텍스트 주소를 큐로 보냅니다.

from("activemq:userdataQueue")
    .to(ExchangePattern.InOut, "velocity:file:AdressTemplate.vm")
    .to("activemq:envelopeAddresses");

Velocity 엔드포인트인 speed :file:AddressTemplate.vm 은 파일 시스템의 Velocity 템플릿 파일 file:AddressTemplate.vm 의 위치를 지정합니다. to() 명령은 교환을 Velocity 엔드포인트로 보내기 전에 교환 패턴을 InOut 로 변경한 다음 나중에 InOnly 로 다시 변경합니다. Velocity 엔드포인트에 대한 자세한 내용은 Apache Camel 구성 요소 참조 가이드의 Velocity 를 참조하십시오.

그림 2.4. “InOut Exchange를 위한 샘플 Pipeline” InOut 교환을 위한 프로세서 파이프라인의 예를 보여줍니다. 일반적으로 원격 프로시저 호출(RPC) 의미 체계를 지원하는 데 사용됩니다. 프로세서 A, B 및 C는 파이프라인 형태로 함께 연결되며 각 프로세서의 출력은 다음 프로세서의 입력으로 제공됩니다. 생산자 엔드포인트에 의해 생성된 최종 아웃 메시지는 소비자 엔드포인트로 다시 전송되며 원래 요청에 대한 응답을 제공합니다.

그림 2.4. InOut Exchange를 위한 샘플 Pipeline

InOut 교환 패턴을 지원하려면 경로의 마지막 노드(프로덕터 엔드포인트 또는 다른 종류의 프로세서인지 여부)가 Out 메시지를 생성하는 것이 중요합니다. 그렇지 않으면 소비자 엔드포인트에 연결하는 모든 클라이언트가 중단되고 응답 메시지를 무기한 기다립니다. 모든 생산자 끝점이 Out 메시지를 생성하는 것은 아닙니다.

들어오는 HTTP 요청을 처리하여 결제 요청을 처리하는 다음 경로를 고려하십시오.

from("jetty:http://localhost:8080/foo")
    .to("cxf:bean:addAccountDetails")
    .to("cxf:bean:getCreditRating")
    .to("cxf:bean:processTransaction");

들어오는 결제 요청이 웹 서비스의 파이프라인을 통해 처리되는 경우 cxf:bean:addAccount Details,cxf:bean:getCreditRating, cxf:bean:processTransaction. 최종 웹 서비스인 processTransaction 은 JETTY 엔드포인트를 통해 다시 전송되는 응답(아웃 메시지)을 생성합니다.

파이프라인이 일련의 끝점으로 구성되면 다음 대체 구문을 사용할 수도 있습니다.

from("jetty:http://localhost:8080/foo")
    .pipeline("cxf:bean:addAccountDetails", "cxf:bean:getCreditRating", "cxf:bean:processTransaction");

InOptionalOut 교환의 파이프라인은 기본적으로 그림 2.4. “InOut Exchange를 위한 샘플 Pipeline” 의 파이프라인과 동일합니다. InOut 과 InOptionalOut 의 차이점은 InOptionalOut 교환 패턴과의 교환이 null Out 메시지를 회신으로 사용할 수 있다는 것입니다. 즉, InOptionalOut 교환의 경우 nullOut 메시지가 파이프라인에 있는 다음 노드의 In 메시지에 복사됩니다. 반대로 InOut 교환의 경우 nullOut 메시지가 삭제되고 현재 노드의 원래 In 메시지가 대신 다음 노드의 In 메시지로 복사됩니다.

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

여러 입력을 지정하는 가장 간단한 방법은 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.5. “세분화된 경로를 사용하여 여러 입력 처리” 에 표시된 대로 경로를 세그먼트로 분할하여 여러 입력을 처리할 수 있습니다.

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

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

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

직접 구성 요소는 경로를 연결하는 가장 간단한 메커니즘을 제공합니다. 직접 구성 요소의 이벤트 모델은 동기식 이므로 경로의 후속 세그먼트가 첫 번째 세그먼트와 동일한 스레드에서 실행됩니다. 직접 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 에 속하는 경로 간 통신에만 사용할 수 있습니다.

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개의 스레드 풀에서 처리된다는 것입니다.

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");

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

예를 들어 신용 요청을 처리하는 애플리케이션을 작성하고 있다고 가정합니다. 신용 요청을 처리하기 전에 고객에게 신용 등급을 할당하는 데이터로 보강해야 합니다. 여기서 등급 데이터는 디렉터리의 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” 을 참조하십시오.

Quarkus 통합은 임의의 Java 오브젝트를 사용하여 메시지를 처리하기 위한 일반적인 용도 메커니즘을 제공합니다. Quarkus 참조를 경로에 삽입하면 Java 오브젝트에서 임의의 메서드를 호출하여 들어오는 교환에 액세스하고 수정할 수 있습니다. exchange의 내용을 매개 변수에 매핑하고, 8080 메서드의 반환 값을 매개 변수 바인딩 이라고 합니다. 매개변수 바인딩은 메서드의 매개변수를 초기화하기 위해 다음 접근 방식의 조합을 사용할 수 있습니다.

빈은 클래스 이름 또는 빈 ID를 키로 사용하여 빈을 조회할 수 있는 서비스인 8080 레지스트리 를 통해 액세스할 수 있습니다. 8080 레지스트리에서 항목을 생성하는 방법은 기본 프레임워크의 경우 일반 Java, Spring, Guice 또는 블루프린트에 따라 다릅니다. 레지스트리 항목은 일반적으로 암시적으로 생성됩니다(예: Spring XML 파일에서 Spring 8080을 인스턴스화할 때).

Apache Camel은 8080 레지스트리에 대한 플러그인 전략을 구현하여 기본 레지스트리 구현을 투명하게 만드는 빈에 액세스하기 위한 통합 계층을 정의합니다. 따라서 표 2.2. “레지스트리 플러그인” 에 표시된 대로 다양한 다른 8080 레지스트리와 Apache Camel 애플리케이션을 통합할 수 있습니다.

일반적으로 관련 8080 레지스트리가 자동으로 설치되므로 빈 레지스트리 구성에 대해 우려할 필요가 없습니다. 예를 들어 Spring 프레임워크를 사용하여 경로를 정의하는 경우 Spring ApplicationContextRegistry 플러그인이 현재 CamelContext 인스턴스에 자동으로 설치됩니다.

OSGi 컨테이너의 배포는 특수한 사례입니다. Apache Camel 경로가 OSGi 컨테이너에 배포되면 CamelContext 에서 빈 인스턴스를 해결하기 위해 레지스트리 체인을 자동으로 설정합니다. 레지스트리 체인은 OSGi 레지스트리와 블루프린트(또는 Spring) 레지스트리로 구성됩니다.

Java 8080(일반 이전 Java 오브젝트 또는 Cryostat)을 사용하여 교환 오브젝트를 처리하려면 Java 오브젝트의 메서드에 인바운드 교환을 바인딩하는 Cryostat () 프로세서를 사용합니다. 예를 들어, 클래스 MyBeanProcessor 를 사용하여 인바운드 교환을 처리하려면 다음과 같은 경로를 정의합니다.

from("file:data/inbound")
    .bean(MyBeanProcessor.class, "processBody")
    .to("file:data/outbound");

Cryostat () 프로세서는 MyBeanProcessor 유형의 인스턴스를 생성하고 processBody() 메서드를 호출하여 인바운드 교환을 처리합니다. 이 방법은 단일 경로에서 MyBeanProcessor 인스턴스에만 액세스하려는 경우에만 적합합니다. 그러나 여러 경로에서 동일한 MyBeanProcessor 인스턴스에 액세스하려면 Object 유형을 첫 번째 인수로 사용하는ans () 변형을 사용합니다. 예를 들면 다음과 같습니다.

MyBeanProcessor myBean = new MyBeanProcessor();

from("file:data/inbound")
    .bean(myBean, "processBody")
    .to("file:data/outbound");
from("activemq:inboundData")
    .bean(myBean, "processBody")
    .to("activemq:outboundData");

Quarkus에서 오버로드된 메서드를 정의하는 경우 해당 매개 변수 유형과 함께 메서드 이름을 지정하여 호출할 오버로드된 메서드를 선택할 수 있습니다. 예를 들어 MyBeanBrocessor 클래스에 두 개의 오버로드된 메서드인 processBody(String) 및 processBody(String,String) 가 있는 경우 다음과 같이 후자 오버로드된 메서드를 호출할 수 있습니다.

from("file:data/inbound")
  .bean(MyBeanProcessor.class, "processBody(String,String)")
  .to("file:data/outbound");

또는 각 매개변수의 유형을 명시적으로 지정하는 대신 사용하는 매개변수 수로 메서드를 식별하려면 와일드카드 문자 * 를 사용할 수 있습니다. 예를 들어 정확한 매개변수 유형에 관계없이 두 매개변수를 사용하는 processBody 라는 메서드를 호출하려면 다음과 같이 polkit () 프로세서를 호출합니다.

from("file:data/inbound")
.bean(MyBeanProcessor.class, "processBody(*,*)")
.to("file:data/outbound");

메서드를 지정할 때 간단한 정규화되지 않은 유형 이름(예: processBody(Exchange)) 또는 정규화된 유형 name(예: processBody(org.apache.camel.Exchange) 을 사용할 수 있습니다.

Quarkus 메서드를 호출할 때 매개 변수 값을 명시적으로 지정할 수 있습니다. 다음과 같은 간단한 유형 값을 전달할 수 있습니다.

다음 예제에서는 명시적 매개변수 값을 동일한 메서드 호출에서 형식 지정자와 혼합할 수 있는 방법을 보여줍니다.

from("file:data/inbound")
  .bean(MyBeanProcessor.class, "processBody(String, 'Sample string value', true, 7)")
  .to("file:data/outbound");

이전 예에서 첫 번째 매개변수의 값은 매개변수 바인딩 주석에 의해 결정될 수 있습니다( “기본 주석”참조).

간단한 유형 값 외에도 간단한 언어(30장. 간단한 언어)를 사용하여 매개변수 값을 지정할 수도 있습니다. 즉, 매개 변수 값을 지정할 때 Simple 언어의 전체 기능을 사용할 수 있습니다. 예를 들어 메시지 본문과 title 헤더의 값을 8080 메서드에 전달하려면 다음을 수행합니다.

from("file:data/inbound")
  .bean(MyBeanProcessor.class, "processBodyAndHeader(${body},${header.title})")
  .to("file:data/outbound");

전체 헤더 해시 맵을 매개변수로 전달할 수도 있습니다. 예를 들어 다음 예제에서는 두 번째 메서드 매개 변수를 java.util.Map 유형으로 선언해야 합니다.

from("file:data/inbound")
  .bean(MyBeanProcessor.class, "processBodyAndAllHeaders(${body},${header})")
  .to("file:data/outbound");

빈 메서드에 교환을 바인딩하려면 특정 규칙을 준수하는 메서드 서명을 정의할 수 있습니다. 특히 메서드 서명에 대한 두 가지 기본 규칙이 있습니다.

들어오는 메시지 본문에 액세스하거나 수정하는 measure 메서드를 구현하려면 단일 문자열 인수를 사용하고 문자열 값을 반환하는 메서드 서명을 정의해야 합니다. 예를 들면 다음과 같습니다.

// Java
package com.acme;

public class MyBeanProcessor {
    public String processBody(String body) {
        // Do whatever you like to 'body'...
        return newBody;
    }
}

유연성을 높이기 위해 들어오는 교환에 액세스하는 8080 방법을 구현할 수 있습니다. 이를 통해 모든 헤더, 본문 및 속성에 액세스하거나 수정할 수 있습니다. 교환 처리의 경우 메서드 서명은 단일 org.apache.camel.Exchange 매개 변수를 사용하고 void 를 반환합니다. 예를 들면 다음과 같습니다.

// Java
package com.acme;

public class MyBeanProcessor {
    public void processExchange(Exchange exchange) {
        // Do whatever you like to 'exchange'...
        exchange.getIn().setBody("Here is a new message body!");
    }
}

Java에서 빈 인스턴스를 생성하는 대신 Spring XML을 사용하여 인스턴스를 만들 수 있습니다. 실제로 XML로 경로를 정의하는 경우 가능한 유일한 접근 방식입니다. XML로 빈을 정의하려면 표준 Spring 8080 요소를 사용합니다. 다음 예제에서는 MyBeanProcessor 인스턴스를 만드는 방법을 보여줍니다.

<beans ...>
    ...
    <bean id="myBeanId" class="com.acme.MyBeanProcessor"/>
</beans>

Spring 구문을 사용하여 blank의 생성자 인수에 데이터를 전달할 수도 있습니다. Spring 8080 요소를 사용하는 방법에 대한 자세한 내용은 Spring 참조 가이드 의 IoC 컨테이너를 참조하십시오.

8080 요소를 사용하여 오브젝트 인스턴스를 생성할 때, 8080 요소의 id 속성 값(배터리의 ID 값)을 사용하여 나중에 참조할 수 있습니다. 예를 들어, myBeanId 와 동일한 ID가 있는 8080 요소가 있는 경우 다음과 같이 Cryostat Ref() 프로세서를 사용하여 Java DSL 경로의 빈 을 참조할 수 있습니다.

from("file:data/inbound").beanRef("myBeanId", "processBody").to("file:data/outbound");

여기서 Cryo statRef() 프로세서는 지정된 8080 인스턴스에서 MyBeanProcessor.processBody() 메서드를 호출합니다.

Camel 스키마의 8080 요소를 사용하여 Spring XML 경로 내에서 8080을 호출할 수도 있습니다. 예를 들면 다음과 같습니다.

<camelContext id="CamelContextID" xmlns="http://camel.apache.org/schema/spring">
  <route>
    <from uri="file:data/inbound"/>
    <bean ref="myBeanId" method="processBody"/>
    <to uri="file:data/outbound"/>
  </route>
</camelContext>

약간의 효율성 향상을 위해 cache 옵션을 true 로 설정하면 jenkins가 사용될 때마다 레지스트리를 조회하지 않도록 할 수 있습니다. 예를 들어 캐싱을 활성화하려면 다음과 같이 8080 요소에서 cache 특성을 설정할 수 있습니다.

<bean ref="myBeanId" method="processBody" cache="true"/>

Spring 8080 요소를 사용하여 오브젝트 인스턴스를 생성할 때, 빈 의 ID(Must 요소의 id 속성 값)를 사용하여 Java에서 개체 인스턴스를 참조할 수 있습니다. 예를 들어, myBeanId 와 동일한 ID가 있는 8080 요소가 있는 경우 다음과 같이 Cryostat Ref() 프로세서를 사용하여 Java DSL 경로의 빈 을 참조할 수 있습니다.

from("file:data/inbound").beanRef("myBeanId", "processBody").to("file:data/outbound");

또는 다음과 같이 @BeanInject 주석을 사용하여 삽입하여 Spring 8080을 참조할 수 있습니다.

// Java
import org.apache.camel.@BeanInject;
...
public class MyRouteBuilder extends RouteBuilder {

   @BeanInject("myBeanId")
   com.acme.MyBeanProcessor bean;

   public void configure() throws Exception {
     ..
   }
}

@BeanInject 주석에서 빈 ID를 생략하면 Camel에서 레지스트리를 유형별로 조회하지만 지정된 유형의 단일ans만 있는 경우에만 작동합니다. 예를 들어 com.acme.MyBeanProcessor 유형의ans를 조회하고 삽입하려면 다음을 수행합니다.

@BeanInject
com.acme.MyBeanProcessor bean;

Camel 컨텍스트에서 사용하는 빈의 경우 일반적으로 올바른 종료 순서는 다음과 같습니다.

이 종료 순서가 역방향인 경우 Camel 컨텍스트가 이미 삭제되어 오류가 발생할 수 있습니다(오류로 직접 발생함). 또는 Camel 컨텍스트가 삭제되는 동안 누락된 Cryostat를 생성하려고 하면 오류도 발생할 수 있습니다. Spring XML의 기본 종료 순서는 빈과 camelContext 가 Spring XML 파일에 표시되는 순서에 따라 달라집니다. 잘못된 종료 순서로 인한 임의의 오류를 방지하기 위해 camelContext 는 Spring XML 파일의 다른 빈보다 먼저 종료되도록 구성됩니다. 이는 Apache Camel 2.13.0 이후의 기본 동작입니다.

이 동작을 변경해야 하는 경우( Camel 컨텍스트가 다른 빈보다 먼저 종료 되지 않도록 함) camelContext 요소에 shutdownEager 속성을 false 로 설정할 수 있습니다. 이 경우 Spring 종속 속성을 사용하여 종료 순서를 보다 세밀하게 제어할 수 있습니다.

“기본 방법 서명” 에 설명된 기본 매개변수 바인딩이 항상 사용하기에 편리하지는 않을 수 있습니다. 예를 들어 일부 데이터 조작을 수행하는 레거시 Java 클래스가 있는 경우 인바운드 교환에서 데이터를 추출하여 기존 메서드 서명의 인수에 매핑해야 할 수 있습니다. 이러한 종류의 매개변수 바인딩에 대해 Apache Camel은 다음과 같은 종류의 Java 주석을 제공합니다.

표 2.3. “기본 Cryostat 주석” 메시지 데이터를 8080 메서드의 인수에 삽입하는 데 사용할 수 있는 org.apache.camel Java 패키지의 주석을 표시합니다.

예를 들어 다음 클래스는 기본 주석을 사용하여 메시지 데이터를 processExchange() 메서드 인수에 삽입하는 방법을 보여줍니다.

// Java
import org.apache.camel.*;

public class MyBeanProcessor {
    public void processExchange(
        @Header(name="user") String user,
        @Body String body,
        Exchange exchange
    ) {
        // Do whatever you like to 'exchange'...
        exchange.getIn().setBody(body + "UserName = " + user);
    }
}

주석을 기본 규칙과 혼합하는 방법을 확인하십시오. 주석이 달린 인수를 삽입하는 것 외에도 매개 변수 바인딩은 교환 오브젝트를 org.apache.camel.Exchange 인수에 자동으로 삽입합니다.

표현식 언어 주석은 message 데이터를 8080 메서드의 인수에 삽입하기 위한 강력한 메커니즘을 제공합니다. 이러한 주석을 사용하면 선택한 스크립팅 언어로 작성된 임의의 스크립트를 호출하여 인바운드 교환에서 데이터를 추출하고 메서드 인수에 데이터를 삽입할 수 있습니다. 표 2.4. “표현식 언어 주석” message 데이터를 Cryostat 메서드의 인수에 삽입하는 데 사용할 수 있는 org.apache.camel. Cryostat 패키지(및 비코어 주석의 하위 패키지)의 주석을 표시합니다.

예를 들어 다음 클래스는 @XPath 주석을 사용하여 들어오는 메시지의 본문에서 사용자 이름과 암호를 XML 형식으로 추출하는 방법을 보여줍니다.

// Java
import org.apache.camel.language.*;

public class MyBeanProcessor {
    public void checkCredentials(
        @XPath("/credentials/username/text()") String user,
        @XPath("/credentials/password/text()") String pass
    ) {
        // Check the user/pass credentials...
        ...
    }
}

@Bean 주석은 등록된 8080을 호출한 결과를 삽입할 수 있기 때문에 특별한 경우입니다. 예를 들어 메서드 인수에 상관 관계 ID를 삽입하려면 @Bean 주석을 사용하여 다음과 같이 ID 생성기 클래스를 호출할 수 있습니다.

// Java
import org.apache.camel.language.*;

public class MyBeanProcessor {
    public void processCorrelatedMsg(
        @Bean("myCorrIdGenerator") String corrId,
        @Body String body
    ) {
        // Check the user/pass credentials...
        ...
    }
}

여기서 myCorrIdGenerator 문자열은 ID 생성기 인스턴스의 빈 ID입니다. ID 생성기 클래스는 다음과 같이 spring 8080 요소를 사용하여 인스턴스화할 수 있습니다.

<beans ...>
    ...
    <bean id="myCorrIdGenerator" class="com.acme.MyIdGenerator"/>
</beans>

여기에서 MyIdGenerator 클래스를 다음과 같이 정의할 수 있습니다.

// Java
package com.acme;

public class MyIdGenerator {

    private UserManager userManager;

    public String generate(
        @Header(name = "user") String user,
        @Body String payload
    ) throws Exception {
       User user = userManager.lookupUser(user);
       String userId = user.getPrimaryId();
       String id = userId + generateHashCodeForPayload(payload);
       return id;
   }
}

참조된 8080 클래스 MyIdGenerator 에서 주석을 사용할 수도 있습니다. generate() 메서드 서명에 대한 유일한 제한 사항은 @Bean 에서 주석이 달린 인수에 삽입하려면 올바른 유형을 반환해야 한다는 것입니다. @Bean 주석은 메서드 이름을 지정할 수 없으므로 주입 메커니즘은 일치하는 반환 유형이 있는 참조 빈에서 첫 번째 메서드를 호출하기만 하면 됩니다.

매개변수 바인딩 주석은 인터페이스 또는 슈퍼클래스에서 상속될 수 있습니다. 예를 들어 Header 주석과 Body 주석을 사용하여 Java 인터페이스를 정의하는 경우 다음과 같이 다음과 같습니다.

// Java
import org.apache.camel.*;

public interface MyBeanProcessorIntf {
    void processExchange(
        @Header(name="user") String user,
        @Body String body,
        Exchange exchange
    );
}

구현 클래스에 정의된 오버로드된 메서드 MyBeanProcessor 는 다음과 같이 기본 인터페이스에 정의된 주석을 상속합니다.

// Java
import org.apache.camel.*;

public class MyBeanProcessor implements MyBeanProcessorIntf {
    public void processExchange(
        String user,  // Inherits Header annotation
        String body,  // Inherits Body annotation
        Exchange exchange
    ) {
        ...
    }
}

Java 인터페이스를 구현하는 클래스는 종종개인 또는 패키지 전용 범위로 보호됩니다. 이러한 방식으로 제한된 구현 클래스에서 메서드를 호출하려고 하면 Quarkus 바인딩이 공개적으로 액세스할 수 있는 해당 인터페이스 메서드를 호출하는 것으로 대체됩니다.

예를 들어 다음 공용 Cryostat Intf 인터페이스를 고려해 보십시오.

// Java
public interface BeanIntf {
    void processBodyAndHeader(String body, String title);
}

여기서 Cryo statIntf 인터페이스는 다음 보호된 Cryostat IntfImpl 클래스에 의해 구현됩니다.

// Java
protected class BeanIntfImpl implements BeanIntf {
    void processBodyAndHeader(String body, String title) {
        ...
    }
}

다음 Cryostat 호출은 public Cryostat Intf.processBodyAndHeader 메서드를 호출합니다.

from("file:data/inbound")
  .bean(BeanIntfImpl.class, "processBodyAndHeader(${body}, ${header.title})")
  .to("file:data/outbound");

Cryostat 통합에는 연결된 클래스의 인스턴스를 생성하지 않고도 정적 메서드를 호출할 수 있습니다. 예를 들어 정적 메서드를 정의하는 다음 Java 클래스를, changeSomething():

// Java
...
public final class MyStaticClass {
    private MyStaticClass() {
    }

    public static String changeSomething(String s) {
        if ("Hello World".equals(s)) {
            return "Bye World";
        }
        return null;
    }

    public void doSomething() {
        // noop
    }
}

polkit 통합을 사용하여 다음과 같이 정적 변경Something 메서드를 호출할 수 있습니다.

from("direct:a")
  *.bean(MyStaticClass.class, "changeSomething")*
  .to("mock:a");

이 구문은 일반 함수의 호출과 동일하지만, 8080 통합은 Java 리플렉션을 악용하여 메서드를 정적으로 식별하고 MyStaticClass 를 인스턴스화 하지 않고 메서드를 호출합니다.

Red Hat Fuse 컨테이너에 경로가 배포되는 특수한 경우 metrics 통합을 사용하여 OSGi 서비스를 직접 호출할 수 있습니다. 예를 들어 OSGi 컨테이너의 번들 중 하나가 서비스를 내보냈다고 가정하면 org.fusesource.example.HelloWorldOsgiService.NET Framework 통합 코드를 사용하여 sayHello 메서드를 호출할 수 있습니다.

from("file:data/inbound")
  .bean(org.fusesource.example.HelloWorldOsgiService.class, "sayHello")
  .to("file:data/outbound");

다음과 같이 Quarkus 구성 요소를 사용하여 Spring 또는 블루프린트 XML 파일 내에서 OSGi 서비스를 호출할 수도 있습니다.

<to uri="bean:org.fusesource.example.HelloWorldOsgiService?method=sayHello"/>

이 작동 방식은 Apache Camel이 OSGi 컨테이너에 배포될 때 레지스트리 체인을 설정하는 것입니다. 먼저 OSGi 서비스 레지스트리에서 지정된 클래스 이름을 조회합니다. 이 조회가 실패하면 로컬 Spring DM 또는 블루프린트 레지스트리로 대체됩니다.

Java 코드를 사용하여 메시지를 처리할 때(예: Quarkus 클래스 또는 프로세서 클래스에서) 새 교환 인스턴스를 생성해야 하는 경우가 많습니다. Exchange 개체를 만들어야 하는 경우 여기에 설명된 대로 가장 쉬운 방법은 ExchangeBuilder 클래스의 메서드를 호출하는 것입니다.

ExchangeBuilder 클래스의 정규화된 이름은 다음과 같습니다.

org.apache.camel.builder.ExchangeBuilder

ExchangeBuilder 는 exchange 개체 빌드 를 시작하는 데 사용할 수 있는Exchange 를 통해 정적 메서드를 노출합니다.

예를 들어 다음 코드는 메시지 본문 문자열, Hello World!, 사용자 이름 및 암호 인증 정보가 포함된 헤더를 포함하는 새 교환 오브젝트를 생성합니다.

// Java
import org.apache.camel.Exchange;
import org.apache.camel.builder.ExchangeBuilder;
...
Exchange exch = ExchangeBuilder.anExchange(camelCtx)
                    .withBody("Hello World!")
                    .withHeader("username", "jdoe")
                    .withHeader("password", "pass")
                    .build();

ExchangeBuilder 클래스는 다음 메서드를 지원합니다.

속성 자리 표시자 기능을 사용하여 문자열을 다양한 컨텍스트(예: XML DSL 요소의 끝점 URI 및 속성)로 대체할 수 있습니다. 자리 표시자 설정은 Java 속성 파일에 저장됩니다. 이 기능은 다양한 Apache Camel 애플리케이션 간에 설정을 공유하거나 특정 구성 설정을 중앙 집중화하려는 경우 유용할 수 있습니다.

예를 들어 다음 경로는 호스트와 포트가 자리 표시자인 {{remote.host}} 및 {{remote.port}} 로 대체되는 웹 서버에 요청을 보냅니다.

from("direct:start").to("http://{{remote.host}}:{{remote.port}}");

자리 표시자 값은 다음과 같이 Java 속성 파일에서 정의됩니다.

# Java properties file
remote.host=myserver.com
remote.port=8080

PropertyPlaceholders 를 사용하는 Apache Camel은 다음을 지원합니다.

속성 설정은 하나 이상의 Java 속성 파일에 저장되며 표준 Java 속성 파일 형식을 준수해야 합니다. 각 속성 설정은 Key=Value 형식으로 자체 줄에 표시됩니다. 비어 있지 않은 첫 번째 문자가 있는 줄은 주석으로 처리됩니다.

예를 들어, 속성 파일에는 예 2.4. “속성 파일 샘플” 에 표시된 대로 콘텐츠가 있을 수 있습니다.

# Property placeholder settings
# (in Java properties file format)
cool.end=mock:result
cool.result=result
cool.concat=mock:{{cool.result}}
cool.start=direct:cool
cool.showid=true

cheese.end=mock:cheese
cheese.quote=Camel rocks
cheese.type=Gouda

bean.foo=foo
bean.bar=bar

속성 구성 요소는 경로 정의에서 사용하기 전에 하나 이상의 속성 파일의 위치로 구성해야 합니다. 다음 해결 방법 중 하나를 사용하여 속성 값을 제공해야 합니다.

예를 들어, classpath에 있는 com/fusesource/cheese.properties 속성 파일과 com/fusesource/bar.properties 속성 파일을 지정하려면 다음 위치 문자열을 사용합니다.

com/fusesource/cheese.properties,com/fusesource/bar.properties

Java 시스템 속성 및 O/S 환경 변수를 PathName 위치에 포함할 수 있습니다.

Java 시스템 속성은 ${PropertyName} 구문을 사용하여 위치 확인기에 포함될 수 있습니다. 예를 들어 Red Hat Fuse의 루트 디렉터리가 Java 시스템 속성인 karaf.home 에 저장된 경우 다음과 같이 파일 위치에 해당 디렉터리 값을 포함할 수 있습니다.

file:${karaf.home}/etc/foo.properties

O/S 환경 변수는 ${env:VarName} 구문을 사용하여 위치 확인기에 포함될 수 있습니다. 예를 들어, JBoss Fuse의 루트 디렉터리가 환경 변수 SMX_HOME 에 저장된 경우 다음과 같이 파일 위치에 해당 디렉터리 값을 포함할 수 있습니다.

file:${env:SMX_HOME}/etc/foo.properties

속성 자리 표시자 사용을 시작하기 전에 하나 이상의 속성 파일의 위치를 지정하여 속성 구성 요소를 구성해야 합니다.Before you can start using property placeholders, you must configure the properties component, specifying the locations of one or more property files.

Java DSL에서는 다음과 같이 속성 파일 위치를 사용하여 속성 구성 요소를 구성할 수 있습니다.

// Java
import org.apache.camel.component.properties.PropertiesComponent;
...
PropertiesComponent pc = new PropertiesComponent();
pc.setLocation("com/fusesource/cheese.properties,com/fusesource/bar.properties");
context.addComponent("properties", pc);

addComponent() 호출에 표시된 것처럼 속성 구성 요소의 이름을 속성으로 설정해야 합니다.

XML DSL에서는 다음과 같이 전용 propertyPlacholder 요소를 사용하여 속성 구성 요소를 구성할 수 있습니다.

<camelContext ...>
   <propertyPlaceholder
      id="properties"
      location="com/fusesource/cheese.properties,com/fusesource/bar.properties"
   />
</camelContext>

속성 구성 요소가 초기화될 때 누락된 .properties 파일을 무시하도록 하려면 ignoreMissingLocation 옵션을 true 로 설정하면 일반적으로 누락된 .properties 파일이 오류가 발생합니다.

또한 속성 구성 요소가 Java 시스템 속성 또는 O/S 환경 변수를 사용하여 지정된 누락된 위치를 무시하도록 하려면 ignoreMissingLocation 옵션을 true 로 설정할 수 있습니다.

속성 구성 요소를 구성한 후 적절한 컨텍스트에서 자리 표시자를 자동으로 대체합니다.After it is configured, the property component automatically substitutes placeholders (in the appropriate context). 자리 표시자의 구문은 다음과 같이 컨텍스트에 따라 달라집니다.

경로에 끝점 URI 문자열이 표시되는 경우 끝점 URI 구문 분석의 첫 번째 단계는 속성 자리 표시자 구문 분석기를 적용하는 것입니다. 자리 표시자 구문 분석기에서는 이중 중괄호, {{Key}} 사이에 나타나는 속성 이름을 자동으로 대체합니다. 예를 들어 예 2.4. “속성 파일 샘플” 에 표시된 속성 설정이 있는 경우 다음과 같이 경로를 정의할 수 있습니다.

from("{{cool.start}}")
    .to("log:{{cool.start}}?showBodyType=false&showExchangeId={{cool.showid}}")
    .to("mock:{{cool.result}}");

기본적으로 자리 표시자 구문 분석기에서는 레지스트리에서 속성 빈 ID를 조회하여 속성 구성 요소를 찾습니다. 원하는 경우 끝점 URI에서 스키마를 명시적으로 지정할 수 있습니다. 예를 들어 속성 앞에 각 끝점 URI를 접두사로 사용하면 다음과 같은 동등한 경로를 정의할 수 있습니다.

from("properties:{{cool.start}}")
    .to("properties:log:{{cool.start}}?showBodyType=false&showExchangeId={{cool.showid}}")
    .to("properties:mock:{{cool.result}}");

스키마를 명시적으로 지정할 때 속성 구성 요소에 대한 옵션을 지정하는 옵션도 있습니다. 예를 들어 속성 파일 위치를 재정의하려면 다음과 같이 위치 옵션을 설정할 수 있습니다.

from("direct:start").to("properties:{{bar.end}}?location=com/mycompany/bar.properties");

DSL 요소의 다양한 특성을 설정하기 위해 XML DSL에서 속성 자리 표시자를 사용할 수도 있습니다. 이 컨텍스트에서 placholder 구문은 이중 중괄호인 {{Key}} 를 사용합니다. 예를 들어 다음과 같이 속성 자리 표시자를 사용하여 jmxAgent 요소를 정의할 수 있습니다.

<camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
    <propertyPlaceholder id="properties" location="org/apache/camel/spring/jmx.properties"/>

    <!-- we can use property placeholders when we define the JMX agent -->
    <jmxAgent id="agent" registryPort="{{myjmx.port}}"
              usePlatformMBeanServer="{{myjmx.usePlatform}}"
              createConnector="true"
              statisticsLevel="RoutesOnly"
            />

    <route>
        <from uri="seda:start"/>
        <to uri="mock:result"/>
    </route>
</camelContext>

예를 들어 < jmxAgent registryPort="{{myjmx.port}}" …​> …​ >와 같이 xs:string 유형의 속성 값을 지정하는 데 일반 자리 표시자 구문을 사용할 수 있습니다. 그러나 다른 유형의 속성(예: xs:int 또는 xs:boolean)의 경우 특수 구문, prop:AttributeName="Key" 를 사용해야 합니다.

예를 들어 속성 파일에서 stop.flag 속성을 정의하는 경우 true 값을 가지면 이 속성을 사용하여 다음과 같이 stopOnException 부울 속성을 설정할 수 있습니다.

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:prop="http://camel.apache.org/schema/placeholder"
       ... >

    <bean id="illegal" class="java.lang.IllegalArgumentException">
        <constructor-arg index="0" value="Good grief!"/>
    </bean>

    <camelContext xmlns="http://camel.apache.org/schema/spring">

        <propertyPlaceholder id="properties"
                             location="classpath:org/apache/camel/component/properties/myprop.properties"
                             xmlns="http://camel.apache.org/schema/spring"/>

        <route>
            <from uri="direct:start"/>
            <multicast prop:stopOnException="stop.flag">
                <to uri="mock:a"/>
                <throwException ref="damn"/>
                <to uri="mock:b"/>
            </multicast>
        </route>

    </camelContext>

</beans>

Java DSL에서 EIP 명령을 호출할 때 자리 표시자 ("OptionName", "키") 형식의 하위 복제를 추가하여 속성 자리 표시자 의 값을 사용하여 EIP 옵션을 설정할 수 있습니다.

예를 들어 속성 파일에서 stop.flag 속성을 정의하는 경우 true 값을 가지면 이 속성을 사용하여 다음과 같이 멀티 캐스트 EIP의 stopOnException 옵션을 설정할 수 있습니다.

from("direct:start")
    .multicast().placeholder("stopOnException", "stop.flag")
        .to("mock:a").throwException(new IllegalAccessException("Damn")).to("mock:b");

간단한 언어 표현식에서 속성 자리 표시자를 대체할 수도 있지만, 이 경우 자리 표시자의 구문은 ${properties:Key} 입니다. 예를 들어 다음과 같이 Simple 표현식 내에서 cheese.quote 자리 표시자를 대체할 수 있습니다.

from("direct:start")
    .transform().simple("Hi ${body} do you think ${properties:cheese.quote}?");

구문 ${properties:Key:DefaultVal} 구문을 사용하여 속성의 기본값을 지정할 수 있습니다. 예를 들면 다음과 같습니다.

from("direct:start")
    .transform().simple("Hi ${body} do you think ${properties:cheese.quote:cheese is good}?");

${properties-location:Location:Key} 구문을 사용하여 속성 파일의 위치를 재정의할 수도 있습니다. 예를 들어 com/mycompany/bar.properties 속성 파일의 설정을 사용하여 bar.quote 자리 표시자를 대체하려면 다음과 같이 Simple 표현식을 정의할 수 있습니다.

from("direct:start")
    .transform().simple("Hi ${body}. ${properties-location:com/mycompany/bar.properties:bar.quote}.");

이전 릴리스에서는 xs:string 유형 속성이 XML DSL의 자리 표시자를 지원하는 데 사용되었습니다. 예를 들어 timeout 속성은 xs:int 유형입니다. 따라서 문자열 값을 자리 표시자 키로 설정할 수 없습니다.

Apache Camel 2.7 이후부터는 이제 특수 자리 표시자 네임스페이스를 사용하면 됩니다. 다음 예제에서는 네임스페이스에 대한 prop 접두사를 보여줍니다. XML DSL의 특성에서 prop 접두사를 사용할 수 있습니다.

stop=true

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:prop="http://camel.apache.org/schema/placeholder"
       xsi:schemaLocation="
       http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
       http://camel.apache.org/schema/spring http://camel.apache.org/schema/spring/camel-spring.xsd
    ">

    <!-- Notice in the declaration above, we have defined the prop prefix as the Camel placeholder namespace -->

    <bean id="damn" class="java.lang.IllegalArgumentException">
        <constructor-arg index="0" value="Damn"/>
    </bean>

    <camelContext xmlns="http://camel.apache.org/schema/spring">

        <propertyPlaceholder id="properties"
                             location="classpath:org/apache/camel/component/properties/myprop.properties"
                             xmlns="http://camel.apache.org/schema/spring"/>

        <route>
            <from uri="direct:start"/>
            <!-- use prop namespace, to define a property placeholder, which maps to
                 option stopOnException={{stop}} -->
            <multicast prop:stopOnException="stop">
                <to uri="mock:a"/>
                <throwException ref="damn"/>
                <to uri="mock:b"/>
            </multicast>
        </route>

    </camelContext>

</beans>

Red Hat Fuse OSGi 컨테이너에 경로를 배포하는 경우 Apache Camel 속성 자리 표시자 메커니즘을 JBoss Fuse의 블루프린트 속성 자리 표시자 메커니즘과 통합할 수 있습니다(실제로 통합은 기본적으로 활성화됨). 다음과 같이 통합을 설정하는 두 가지 기본 방법이 있습니다.

OSGi 블루프린트 파일 내에 camelContext 요소를 정의하면 Apache Camel 속성 자리 표시자 메커니즘이 블루프린트 속성 자리 표시자 메커니즘과 자동으로 통합됩니다. 즉, camelContext 범위 내에 표시되는 Apache Camel 구문(예: {{cool.end}})을 따르는 자리 표시자는 블루프린트 속성 자리 표시자 메커니즘을 확인하여 암시적으로 해결됩니다.

예를 들어, 경로의 마지막 끝점이 속성 자리 표시자인 {{result}}:에 의해 정의된 OSGi 블루프린트 파일에 다음 경로를 고려하십시오.

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.0.0"
           xsi:schemaLocation="
           http://www.osgi.org/xmlns/blueprint/v1.0.0 https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">

    <!-- OSGI blueprint property placeholder -->
    <cm:property-placeholder id="myblueprint.placeholder" persistent-id="camel.blueprint">
        <!-- list some properties for this test -->
        <cm:default-properties>
            <cm:property name="result" value="mock:result"/>
        </cm:default-properties>
    </cm:property-placeholder>

    <camelContext xmlns="http://camel.apache.org/schema/blueprint">
        <!-- in the route we can use {{ }} placeholders which will look up in blueprint,
             as Camel will auto detect the OSGi blueprint property placeholder and use it -->
        <route>
            <from uri="direct:start"/>
            <to uri="mock:foo"/>
            <to uri="{{result}}"/>
        </route>
    </camelContext>

</blueprint>

블루프린트 속성 자리 표시자 메커니즘은 cm:property-placeholder hieradata를 생성하여 초기화됩니다. 이전 예에서 cm:property-placeholder hieradata는 camel.blueprint 영구 ID와 연결되어 있습니다. 여기서 영구 ID는 OSGi 구성 관리자 서비스의 관련 속성 그룹을 참조하는 표준 방법입니다. 즉, cm:property-placeholder hieradata는 camel.blueprint 영구 ID 아래에 정의된 모든 속성에 대한 액세스를 제공합니다. 또한 일부 속성( nested cm:property 요소 사용)에 기본값을 지정할 수도 있습니다.

블루프린트 컨텍스트에서 Apache Camel 자리 표시자 메커니즘은 8080 레지스트리에서 cm:property-placeholder 인스턴스를 검색합니다. 이러한 인스턴스를 찾으면 Apache Camel 자리 표시자 메커니즘을 자동으로 통합하여, {{result}} 와 같은 자리 표시자 메커니즘은 블루프린트 속성 자리 표시자 메커니즘에서 키를 조회하여 해결됩니다(이 예에서는 myblueprint.placeholder chain을 통해).

Apache Camel 속성 자리 표시자 메커니즘에서 해당 속성을 찾는 위치를 더 많이 제어하려면 propertyPlaceholder 요소를 정의하고 확인자 위치를 명시적으로 지정할 수 있습니다.

예를 들어 명시적 propertyPlaceholder 인스턴스를 생성한다는 점에서 이전 예제와 다른 다음 블루프린트 구성을 고려하십시오.

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.0.0"
           xsi:schemaLocation="
           http://www.osgi.org/xmlns/blueprint/v1.0.0 ">https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">

    <!-- OSGI blueprint property placeholder -->
    <cm:property-placeholder id="myblueprint.placeholder" persistent-id="camel.blueprint">
        <!-- list some properties for this test -->
        <cm:default-properties>
            <cm:property name="result" value="mock:result"/>
        </cm:default-properties>
    </cm:property-placeholder>

    <camelContext xmlns="http://camel.apache.org/schema/blueprint">

        <!-- using Camel properties component and refer to the blueprint property placeholder by its id -->
        <propertyPlaceholder id="properties" location="blueprint:myblueprint.placeholder"/>

        <!-- in the route we can use {{ }} placeholders which will lookup in blueprint -->
        <route>
            <from uri="direct:start"/>
            <to uri="mock:foo"/>
            <to uri="{{result}}"/>
        </route>

    </camelContext>

</blueprint>

이전 예에서 propertyPlaceholder 요소는 위치를 블루프린트:myblueprint.placeholder 로 설정하여 사용할 cm:property-placeholder hieradata를 명시적으로 지정합니다. 즉, 블루프린트: resolver는 cm:property-placeholder hieradata의 ID, myblueprint.placeholder 임을 명시적으로 참조합니다.

이 구성 스타일은 블루프린트 파일에 정의된 cm:property-placeholder hieradata가 두 개 이상 있고 사용할 구성을 지정해야 하는 경우 유용합니다. 또한 쉼표로 구분된 위치 목록을 지정하여 여러 위치에서 속성을 소스할 수 있습니다. 예를 들어 cm:property-placeholder hieradata와 속성 파일 myproperties.properties 에서 속성을 조회하려면 classpath에서 propertyPlaceholder 요소를 다음과 같이 정의할 수 있습니다.

<propertyPlaceholder id="properties"
  location="blueprint:myblueprint.placeholder,classpath:myproperties.properties"/>

Spring XML 파일에서 XML DSL을 사용하여 Apache Camel 애플리케이션을 정의하는 경우 org.apache.camel.spring.spi.BridgePropertyPlaceConfigurer 유형의 Spring 메가바이트를 선언하여 Apache Camel 속성 자리 표시자 메커니즘을 Spring 속성 자리 표시자 메커니즘과 통합할 수 있습니다.

Apache Camel의 property Placeholder element 및 Spring's ctx:property-placeholder 요소를 Spring XML 파일에서 모두 대체하는 BridgeProperty Placeholder를 정의합니다. 그런 다음 Spring ${PropName} 구문 또는 Apache Camel {{PropName }} 구문을 사용하여 구성된 속성을 참조할 수 있습니다.

예를 들어 cheese.properties 파일에서 속성 설정을 읽는 브리지 속성 자리 표시자를 정의합니다.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:ctx="http://www.springframework.org/schema/context"
    xsi:schemaLocation="
        http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd">

  <!-- Bridge Spring property placeholder with Camel -->
  <!-- Do not use <ctx:property-placeholder ... > at the same time -->
  <bean id="bridgePropertyPlaceholder"
        class="org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer">
    <property name="location"
              value="classpath:org/apache/camel/component/properties/cheese.properties"/>
  </bean>

  <!-- A bean that uses Spring property placeholder -->
  <!-- The ${hi} is a spring property placeholder -->
  <bean id="hello" class="org.apache.camel.component.properties.HelloBean">
    <property name="greeting" value="${hi}"/>
  </bean>

  <camelContext xmlns="http://camel.apache.org/schema/spring">
    <!-- Use Camel's property placeholder {{ }} style -->
    <route>
      <from uri="direct:{{cool.bar}}"/>
      <bean ref="hello"/>
      <to uri="{{cool.end}}"/>
    </route>
  </camelContext>

</beans>

Apache Camel 스레딩 모델은 Sun의 JDK 1.5에서 먼저 사용 가능하게 된 강력한 Java 동시성 API인 Package java.util.concurrent 를 기반으로 합니다. 이 API의 주요 인터페이스는 스레드 풀을 나타내는 ExecutorService 인터페이스입니다. 동시성 API를 사용하면 다양한 시나리오를 대상으로 다양한 종류의 스레드 풀을 생성할 수 있습니다.

Apache Camel 스레드 풀 API는 Apache Camel 애플리케이션의 모든 스레드 풀에 대해 중앙 팩토리( org.apache.camel.spi.ExecutorServiceManager 유형)를 제공하여 Java 동시성 API를 기반으로 빌드됩니다. 이러한 방식으로 스레드 풀 생성을 중앙 집중화하면 다음과 같은 몇 가지 이점이 있습니다.

일부 Apache Camel 구성 요소는 SEDA, JMS 및 Cryostatty Cryostat-의 경우 본질적으로 다중 스레드로 분류됩니다. 이러한 구성 요소는 모두 Apache Camel 스레딩 모델 및 스레드 풀 API를 사용하여 구현되었습니다.

자체 Apache Camel 구성 요소를 구현하려는 경우 스레드 코드를 Apache Camel 스레딩 모델과 통합하는 것이 좋습니다. 예를 들어 구성 요소에 스레드 풀이 필요한 경우 CamelContext의 ExecutorServiceManager 오브젝트를 사용하여 생성하는 것이 좋습니다.

Apache Camel의 표준 프로세서 중 일부는 기본적으로 자체 스레드 풀을 생성합니다. 이러한 스레딩 인식 프로세서는 Apache Camel 스레딩 모델과 통합되며 사용하는 스레드 풀을 사용자 지정할 수 있는 다양한 옵션을 제공합니다.

표 2.8. “프로세서 스레드 옵션” Apache Camel에 내장된 스레드 인식 프로세서에서 스레드 풀을 제어하고 설정하는 다양한 옵션을 보여줍니다.

parallelProcessing()
executorService()
executorServiceRef()

@parallelProcessing
@executorServiceRef

parallelProcessing()
executorService()
executorServiceRef()

@parallelProcessing
@executorServiceRef

parallelProcessing()
executorService()
executorServiceRef()

@parallelProcessing
@executorServiceRef

parallelProcessing()
executorService()
executorServiceRef()

@parallelProcessing
@executorServiceRef

executorService()
executorServiceRef()
poolSize()
maxPoolSize()
keepAliveTime()
timeUnit()
maxQueueSize()
rejectedPolicy()

@executorServiceRef
@poolSize
@maxPoolSize
@keepAliveTime
@timeUnit
@maxQueueSize
@rejectedPolicy

wireTap(String uri, ExecutorService executorService)
wireTap(String uri, String executorServiceRef)

@executorServiceRef

스레드 프로세서는 스레드 풀을 경로에 도입하는 데 사용할 수 있는 범용 DSL 명령입니다. 스레드 풀을 사용자 지정하는 다음 옵션을 지원합니다.

스레드 인식 프로세서 중 하나에 대한 기본 스레드 풀을 생성하려면 XML DSL에서 parallelProcessing () 하위 복제 또는 병렬Processing 특성을 사용하여 parallelProcessing 옵션을 활성화합니다.

예를 들어 Java DSL에서는 다음과 같이 기본 스레드 풀(스레드 풀이 동시에 멀티 캐스트 대상을 처리하는 데 사용되는) 멀티캐스트 프로세서를 호출할 수 있습니다.

from("direct:start")
  .multicast().parallelProcessing()
    .to("mock:first")
    .to("mock:second")
    .to("mock:third");

다음과 같이 XML DSL에서 동일한 경로를 정의할 수 있습니다.

<camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
    <route>
        <from uri="direct:start"/>
        <multicast parallelProcessing="true">
            <to uri="mock:first"/>
            <to uri="mock:second"/>
            <to uri="mock:third"/>
        </multicast>
    </route>
</camelContext>

기본 스레드 풀은 기본 스레드 풀 프로필에서 설정을 사용하는 스레드 팩토리에 의해 자동으로 생성됩니다. 기본 스레드 풀 프로필에는 표 2.9. “기본 스레드 풀 프로필 설정” 에 표시된 설정이 있습니다(애플리케이션 코드에서 이러한 설정을 수정하지 않은 것으로 가정).

모든 후속 기본 스레드 풀이 사용자 지정 설정으로 생성되도록 기본 스레드 풀 프로필 설정을 변경할 수 있습니다. Java 또는 Spring XML에서 프로필을 변경할 수 있습니다.

예를 들어 Java DSL에서는 다음과 같이 기본 스레드 풀 프로필에서 poolSize 옵션과 maxQueueSize 옵션을 사용자 지정할 수 있습니다.

// Java
import org.apache.camel.spi.ExecutorServiceManager;
import org.apache.camel.spi.ThreadPoolProfile;
...
ExecutorServiceManager manager = context.getExecutorServiceManager();
ThreadPoolProfile defaultProfile = manager.getDefaultThreadPoolProfile();

// Now, customize the profile settings.
defaultProfile.setPoolSize(3);
defaultProfile.setMaxQueueSize(100);
...

XML DSL에서는 다음과 같이 기본 스레드 풀 프로필을 사용자 지정할 수 있습니다.

<camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
    <threadPoolProfile
        id="changedProfile"
        defaultProfile="true"
        poolSize="3"
        maxQueueSize="100"/>
    ...
</camelContext>

이전 XML DSL 예에서 defaultProfile 속성을 true 로 설정하는 것이 중요합니다. 그러지 않으면 스레드 풀 프로파일은 기본 스레드 풀 프로필을 대체하는 대신 사용자 지정 스레드 풀 프로필로 처리됩니다( “사용자 정의 스레드 풀 프로필 생성”참조).

executorService 또는 executorServiceRef 옵션을 사용하여 스레딩 인식 프로세서에 대한 스레드 풀을 더 직접 지정할 수도 있습니다(이러한 옵션은 parallelProcessing 옵션 대신 사용됨). 다음과 같이 프로세서의 스레드 풀을 사용자 지정하는 데 사용할 수 있는 두 가지 방법이 있습니다.

executorServiceRef 옵션에 빈 ID를 전달하면 스레드링 인식 프로세서는 먼저 레지스트리에서 해당 ID가 있는 사용자 지정 스레드 풀을 찾습니다. 해당 ID에 등록된 스레드 풀이 없는 경우 프로세서는 레지스트리에서 사용자 지정 스레드 풀 프로필을 조회하고 사용자 지정 스레드 풀 프로필을 사용하여 사용자 지정 스레드 풀을 인스턴스화합니다.

사용자 지정 스레드 풀은 java.util.concurrent.ExecutorService 유형의 스레드 풀일 수 있습니다. Apache Camel에서는 스레드 풀 인스턴스를 생성하는 방법을 사용하는 것이 좋습니다.

결국 ThreadPoolBuilder 는 ExecutorServiceManager 인스턴스를 사용하여 정의되기 때문에 두 가지 접근 방식에는 크게 차이가 없습니다. 일반적으로 ThreadPoolBuilder 는 더 간단한 접근 방식을 제공하기 때문에 선호됩니다. 그러나 ExecutorServiceManager 인스턴스에 직접 액세스하여 생성할 수 있는 스레드 종류( ScheduledExecutorService)가 하나 이상 있습니다.

표 2.10. “스레드 풀 빌더 옵션” 새 사용자 지정 스레드 풀을 정의할 때 설정할 수 있는 ThreadPoolBuilder 클래스에서 지원하는 옵션을 표시합니다.

Java DSL에서는 다음과 같이 ThreadPoolBuilder 를 사용하여 사용자 지정 스레드 풀을 정의할 수 있습니다.

// Java
import org.apache.camel.builder.ThreadPoolBuilder;
import java.util.concurrent.ExecutorService;
...
ThreadPoolBuilder poolBuilder = new ThreadPoolBuilder(context);
ExecutorService customPool = poolBuilder.poolSize(5).maxPoolSize(5).maxQueueSize(100).build("customPool");
...

from("direct:start")
  .multicast().executorService(customPool)
    .to("mock:first")
    .to("mock:second")
    .to("mock:third");

다음과 같이 개체 참조 customPool 을 executorService() 옵션에 직접 전달하는 대신, Quarkus ID를 executorServiceRef() 옵션에 전달하여 레지스트리의 스레드 풀을 조회할 수 있습니다.

// Java
from("direct:start")
  .multicast().executorServiceRef("customPool")
    .to("mock:first")
    .to("mock:second")
    .to("mock:third");

XML DSL에서는 threadPool 요소를 사용하여 ThreadPoolBuilder 에 액세스합니다. 그런 다음 executorServiceRef 특성을 사용하여 사용자 지정 스레드 풀을 참조하여 다음과 같이 Spring 레지스트리에서 ID로 스레드 풀을 조회할 수 있습니다.

<camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
    <threadPool id="customPool"
                poolSize="5"
                maxPoolSize="5"
                maxQueueSize="100" />

    <route>
        <from uri="direct:start"/>
        <multicast executorServiceRef="customPool">
            <to uri="mock:first"/>
            <to uri="mock:second"/>
            <to uri="mock:third"/>
        </multicast>
    </route>
</camelContext>

생성할 사용자 지정 스레드 풀 인스턴스가 많은 경우 스레드 풀에 대해 팩토리 역할을 하는 사용자 지정 스레드 풀 프로필을 정의하는 것이 더 편리합니다. 스레드 인식 프로세서의 스레드 풀 프로필을 참조할 때마다 프로세서는 프로필을 자동으로 사용하여 새 스레드 풀 인스턴스를 만듭니다. Java DSL 또는 XML DSL에서 사용자 지정 스레드 풀 프로필을 정의할 수 있습니다.

예를 들어 Java DSL에서는 빈 ID, customProfile 을 사용하여 사용자 지정 스레드 풀 프로필을 생성하고 다음과 같이 경로 내에서 참조할 수 있습니다.

// Java
import org.apache.camel.spi.ThreadPoolProfile;
import org.apache.camel.impl.ThreadPoolProfileSupport;
...
// Create the custom thread pool profile
ThreadPoolProfile customProfile = new ThreadPoolProfileSupport("customProfile");
customProfile.setPoolSize(5);
customProfile.setMaxPoolSize(5);
customProfile.setMaxQueueSize(100);
context.getExecutorServiceManager().registerThreadPoolProfile(customProfile);
...
// Reference the custom thread pool profile in a route
from("direct:start")
  .multicast().executorServiceRef("customProfile")
    .to("mock:first")
    .to("mock:second")
    .to("mock:third");

XML DSL에서 threadPoolProfile 요소를 사용하여 사용자 지정 풀 프로필을 만듭니다(기본 스레드 풀 프로필이 아니므로 defaultProfile 옵션이 false 로 설정되도록 합니다). metrics ID, customProfile 을 사용하여 사용자 정의 스레드 풀 프로필을 생성하고 다음과 같이 경로 내에서 참조할 수 있습니다.

<camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
    <threadPoolProfile
                id="customProfile"
                poolSize="5"
                maxPoolSize="5"
                maxQueueSize="100" />

    <route>
        <from uri="direct:start"/>
        <multicast executorServiceRef="customProfile">
            <to uri="mock:first"/>
            <to uri="mock:second"/>
            <to uri="mock:third"/>
        </multicast>
    </route>
</camelContext>

일부 표준 폴링 기반 구성 요소는 File 및 FTP해야 할 구성 요소와 같이 사용할 스레드 풀을 지정할 수 있습니다. 이를 통해 여러 구성 요소가 동일한 스레드 풀을 공유하여 JVM의 전체 스레드 수를 줄일 수 있습니다.

예를 들어 Apache Camel 구성 요소 참조 가이드의 File2 참조 가이드와 Apache Camel 구성 요소 참조 가이드 의 Ftp2 는 구성 요소의 ExecutorService 오브젝트를 지정하는 데 사용할 수 있는 scheduledExecutorService 속성을 노출합니다.

애플리케이션 로그를 더 읽기 쉽게 만들려면 종종 스레드 이름을 사용자 지정하는 것이 좋습니다(로그에서 스레드를 식별하는 데 사용됨). 스레드 이름을 사용자 지정하려면 ExecutorServiceStrategy 클래스 또는 ExecutorServiceManager 클래스에서 setThreadNamePattern 메서드를 호출하여 스레드 이름 패턴 을 구성할 수 있습니다. 또는 스레드 이름 패턴을 설정하는 더 쉬운 방법은 CamelContext 오브젝트에 threadNamePattern 속성을 설정하는 것입니다.

다음 자리 표시자는 스레드 이름 패턴에서 사용할 수 있습니다.

다음은 스레드 이름 패턴의 일반적인 예입니다.

Camel (#camelId#) thread #counter# - #name#

다음 예제에서는 XML DSL을 사용하여 Camel 컨텍스트에서 threadNamePattern 속성을 설정하는 방법을 보여줍니다.

<camelContext xmlns="http://camel.apache.org/schema/spring"
              threadNamePattern="Riding the thread #counter#" >
  <route>
    <from uri="seda:start"/>
    <to uri="log:result"/>
    <to uri="mock:result"/>
  </route>
</camelContext>

기본적으로 Apache Camel 애플리케이션( CamelContext 인스턴스에 표시된 대로)이 시작되고 Apache Camel 애플리케이션이 종료되면 경로가 자동으로 종료됩니다. 중요하지 않은 배포의 경우 종료 순서의 세부 사항은 일반적으로 중요하지 않습니다. 그러나 프로덕션 환경에서는 데이터 손실을 방지하기 위해 기존 작업을 종료 중에 완료해야 하는 경우가 많습니다. 또한 일반적으로 경로가 종료되는 순서를 제어하여 종속 항목이 위반되지 않도록 합니다(기존 작업이 완료되지 않도록).

이러한 이유로 Apache Camel은 애플리케이션의 정상 종료 를 지원하는 일련의 기능을 제공합니다. 정상 종료를 사용하면 경로 중지 및 시작을 완전히 제어할 수 있으므로 경로 종료 순서를 제어하고 현재 작업을 완료할 수 있습니다.

각 경로에 경로 ID를 할당하는 것이 좋습니다. 로깅 메시지 및 관리 기능을 보다 효과적으로 활용할 뿐만 아니라 경로 ID를 사용하면 경로 중지 및 시작을 보다 효과적으로 제어할 수 있습니다.

예를 들어 Java DSL에서는 다음과 같이 routeId() 명령을 호출하여 경로 ID인 myCustomerRouteId 를 경로에 할당할 수 있습니다.

from("SourceURI").routeId("myCustomRouteId").process(...).to(TargetURI);

XML DSL에서 다음과 같이 경로 요소의 id 속성을 설정합니다.

<camelContext id="CamelContextID" xmlns="http://camel.apache.org/schema/spring">
  <route id="myCustomRouteId" >
    <from uri="SourceURI"/>
    <process ref="someProcessorId"/>
    <to uri="TargetURI"/>
  </route>
</camelContext>

기본적으로 CamelContext가 시작 시 알고 있는 모든 경로가 자동으로 시작됩니다. 그러나 특정 경로의 시작을 수동으로 제어하려는 경우 해당 경로에 대한 자동 시작을 비활성화할 수 있습니다.

Java DSL 경로가 자동으로 시작되는지 여부를 제어하려면 부울 인수(true 또는 false) 또는 문자열 인수(true 또는 false)를 사용하여 autoStartup 명령을 호출합니다. 예를 들어 다음과 같이 Java DSL에서 경로 자동 시작을 비활성화할 수 있습니다.

from("SourceURI")
  .routeId("nonAuto")
  .autoStartup(false)
  .to(TargetURI);

다음과 같이 autoStartup 속성을 false 로 설정하여 XML DSL에서 경로 자동 시작을 비활성화할 수 있습니다.

<camelContext id="CamelContextID" xmlns="http://camel.apache.org/schema/spring">
  <route id="nonAuto" autoStartup="false">
    <from uri="SourceURI"/>
    <to uri="TargetURI"/>
  </route>
</camelContext>

CamelContext 인스턴스에서 startRoute() 및 stopRoute() 메서드를 호출하여 언제든지 Java에서 경로를 수동으로 시작하거나 중지할 수 있습니다. 예를 들어, 경로 ID가 non auto인 경로를 시작하려면 다음과 같이 CamelContext 인스턴스인 context 에서 startRoute() 메서드를 호출합니다.

// Java
context.startRoute("nonAuto");

경로 ID가 아닌 자동 경로가 있는 경로를 중지하려면 다음과 같이 CamelContext 인스턴스인 context 에서 stopRoute() 메서드를 호출합니다.

// Java
context.stopRoute("nonAuto");

기본적으로 Apache Camel은 결정적이지 않은 순서로 경로를 시작합니다. 그러나 일부 애플리케이션에서는 시작 순서를 제어하는 것이 중요할 수 있습니다. Java DSL에서 시작 순서를 제어하려면 양의 정수 값을 인수로 사용하는 startupOrder() 명령을 사용합니다. 가장 낮은 정수 값이 있는 경로가 먼저 시작되고 그 뒤에 시작 순서가 더 높은 경로가 있습니다.

예를 들어 다음 예에서 처음 두 경로는 seda:buffer 엔드포인트를 통해 함께 연결됩니다. 다음과 같이 시작 순서 (2 및 1)를 할당하여 두 번째 경로 세그먼트 이후 첫 번째 경로 세그먼트가 시작되도록 할 수 있습니다.

from("jetty:http://fooserver:8080")
    .routeId("first")
    .startupOrder(2)
    .to("seda:buffer");

from("seda:buffer")
    .routeId("second")
    .startupOrder(1)
    .to("mock:result");

// This route's startup order is unspecified
from("jms:queue:foo").to("jms:queue:bar");

또는 Spring XML에서는 다음과 같이 경로 요소의 startupOrder 특성을 설정하여 동일한 효과를 얻을 수 있습니다.

<route id="first" startupOrder="2">
    <from uri="jetty:http://fooserver:8080"/>
    <to uri="seda:buffer"/>
</route>

<route id="second" startupOrder="1">
    <from uri="seda:buffer"/>
    <to uri="mock:result"/>
</route>

<!-- This route's startup order is unspecified -->
<route>
    <from uri="jms:queue:foo"/>
    <to uri="jms:queue:bar"/>
</route>

각 경로에 고유한 시작 순서 값을 할당해야 합니다. 1000보다 작은 양의 정수 값을 선택할 수 있습니다. 1000개 이상의 값은 Apache Camel용으로 예약되어 있으며, 명시적 시작 값 없이 이러한 값을 경로에 자동으로 할당합니다. 예를 들어 위 예제의 마지막 경로에 시작 값 1000이 자동으로 할당되므로 처음 두 경로 후에 시작됩니다.

CamelContext 인스턴스가 종료되면 Apache Camel은 플러그형 종료 전략을 사용하여 종료 순서를 제어합니다. 기본 shutdown 전략은 다음과 같은 종료 순서를 구현합니다.

경로는 시작 순서의 반대로 종료됩니다. 즉, 시작 순서가 startupOrder() 명령(Java DSL에서) 또는 startupOrder 특성( XML DSL에서)을 사용하여 정의되는 경우 종료되는 첫 번째 경로는 시작 순서에 의해 할당되는 가장 높은 정수 값을 가진 경로이며 종료할 마지막 경로는 시작 순서에 의해 할당되는 가장 낮은 정수 값을 가진 경로입니다.

예를 들어 예 2.5. “Java DSL의 시작 순서” 에서 종료할 첫 번째 경로 세그먼트는 ID가 첫 번째인 경로입니다. 두 번째 경로 세그먼트는 ID가 있는 경로이고 두 번째 경로 세그먼트는 ID가 있는 경로입니다. 이 예제에서는 경로를 종료할 때 관찰해야 합니다. 외부에서 액세스 가능한 소비자 끝점을 노출하는 경로는 먼저 종료되어야 합니다. 이는 나머지 경로 그래프를 통한 메시지 흐름을 방지하는 데 도움이 되기 때문입니다.

종료 시 경로가 계속 메시지를 처리하는 경우 shutdown 전략은 일반적으로 경로를 종료하기 전에 현재 활성 교환이 처리를 완료할 때까지 기다립니다. 이 동작은 다음 값 중 하나를 사용할 수 있는 shutdownRunningTask 옵션을 사용하여 각 경로에 구성할 수 있습니다.

예를 들어 파일 소비자 끝점을 정상적으로 종료하려면 다음 Java DSL 조각에 표시된 것처럼 CompleteAllTasks 옵션을 지정해야 합니다.

// Java
public void configure() throws Exception {
    from("file:target/pending")
        .routeId("first").startupOrder(2)
        .shutdownRunningTask(ShutdownRunningTask.CompleteAllTasks)
        .delay(1000).to("seda:foo");

    from("seda:foo")
        .routeId("second").startupOrder(1)
        .to("mock:bar");
}

다음과 같이 XML DSL에 동일한 경로를 정의할 수 있습니다.

<camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
    <!-- let this route complete all its pending messages when asked to shut down -->
    <route id="first"
           startupOrder="2"
           shutdownRunningTask="CompleteAllTasks">
        <from uri="file:target/pending"/>
        <delay><constant>1000</constant></delay>
        <to uri="seda:foo"/>
    </route>

    <route id="second" startupOrder="1">
        <from uri="seda:foo"/>
        <to uri="mock:bar"/>
    </route>
</camelContext>

종료 시간 초과의 기본값은 300초입니다. shutdown 전략에서 setTimeout() 메서드를 호출하여 시간 초과 값을 변경할 수 있습니다. 예를 들어 다음과 같이 시간 초과 값을 600초로 변경할 수 있습니다.

// Java
// context = CamelContext instance
context.getShutdownStrategy().setTimeout(600);

사용자 지정 Apache Camel 구성 요소( org.apache.camel.Service 인터페이스에서 상속됨)를 구현하는 경우 사용자 정의 코드가 org.apache.camel.spi.ShutdownPrepared 인터페이스를 구현하여 종료 알림을 받을 수 있습니다. 그러면 구성 요소에 종료를 준비하여 사용자 정의 코드를 실행할 수 있습니다.

OnCompletion DSL 이름은 작업 단위 가 완료될 때 수행할 작업을 정의하는 데 사용됩니다. 작업 단위는 전체 교환을 포함하는 Camel 개념입니다. 34.1절. “교환”을 참조하십시오. onCompletion 명령에는 다음과 같은 기능이 있습니다.

교환에 onCompletion DSL이 지정되면 Camel이 새 스레드를 구동합니다. 이를 통해 onCompletion 작업의 간섭 없이 원래 스레드를 계속할 수 있습니다. 경로는 하나의 onCompletion 만 지원합니다. 다음 예에서 onCompletion 은 교환이 성공 또는 실패로 완료되었는지 여부를 트리거합니다. 기본 동작입니다.

from("direct:start")
     .onCompletion()
         // This route is invoked when the original route is complete.
         // This is similar to a completion callback.
         .to("log:sync")
         .to("mock:sync")
     // Must use end to denote the end of the onCompletion route.
     .end()
     // here the original route contiues
     .process(new MyProcessor())
     .to("mock:result");

XML의 경우 형식은 다음과 같습니다.

<route>
    <from uri="direct:start"/>
    <!-- This onCompletion block is executed when the exchange is done being routed. -->
    <!-- This callback is always triggered even if the exchange fails. -->
    <onCompletion>
        <!-- This is similar to an after completion callback. -->
        <to uri="log:sync"/>
        <to uri="mock:sync"/>
    </onCompletion>
    <process ref="myProcessor"/>
    <to uri="mock:result"/>
</route>

실패 시 onCompletion 을 트리거하려면 onFailureOnly 매개변수를 사용할 수 있습니다. 마찬가지로 성공 시 onCompletion 을 트리거하려면 onCompleteOnly 매개변수를 사용합니다.

from("direct:start")
     // Here onCompletion is qualified to invoke only when the exchange fails (exception or FAULT body).
     .onCompletion().onFailureOnly()
         .to("log:sync")
         .to("mock:sync")
     // Must use end to denote the end of the onCompletion route.
     .end()
     // here the original route continues
     .process(new MyProcessor())
     .to("mock:result");

XML의 경우 onFailureOnly 및 onCompleteOnly 는 onCompletion 태그에서 부울로 표시됩니다.

<route>
    <from uri="direct:start"/>
    <!-- this onCompletion block will only be executed when the exchange is done being routed -->
    <!-- this callback is only triggered when the exchange failed, as we have onFailure=true -->
    <onCompletion onFailureOnly="true">
        <to uri="log:sync"/>
        <to uri="mock:sync"/>
    </onCompletion>
    <process ref="myProcessor"/>
    <to uri="mock:result"/>
</route>

두 개 이상의 경로에 대한 onCompletion 을 정의하려면 다음을 수행합니다.

// define a global on completion that is invoked when the exchange is complete
 onCompletion().to("log:global").to("mock:sync");

 from("direct:start")
     .process(new MyProcessor())
     .to("mock:result");

특정 상황에서 onCompletion 을 트리거하려면 on When 서술자를 사용합니다. 다음 예제는 메시지 본문에 Hello:이라는 단어가 포함된 경우 onCompletion 을 트리거합니다.

/from("direct:start")
     .onCompletion().onWhen(body().contains("Hello"))
         // this route is only invoked when the original route is complete as a kind
         // of completion callback. And also only if the onWhen predicate is true
         .to("log:sync")
         .to("mock:sync")
     // must use end to denote the end of the onCompletion route
     .end()
     // here the original route contiues
     .to("log:original")
     .to("mock:result");

Camel 2.14부터는 기본적으로 스레드 풀을 사용하지 않습니다. 스레드 풀을 강제로 사용하려면 executorService 를 설정하거나 parallelProcessing 을 true로 설정합니다. 예를 들어 Java DSL에서는 다음 형식을 사용합니다.

onCompletion().parallelProcessing()
     .to("mock:before")
     .delay(1000)
     .setBody(simple("OnComplete:${body}"));

XML의 경우 형식은 다음과 같습니다.

<onCompletion parallelProcessing="true">
   <to uri="before"/>
   <delay><constant>1000</constant></delay>
   <setBody><simple>OnComplete:${body}<simple></setBody>
 </onCompletion>

executorServiceRef 옵션을 사용하여 특정 스레드 풀을 참조합니다.

<onCompletion executorServiceRef="myThreadPool"
   <to uri="before"/>
   <delay><constant>1000</constant></delay>
   <setBody><simple>OnComplete:${body}</simple></setBody>
 </onCompletion>>

OnCompletion 은 다음 두 가지 모드로 실행할 수 있습니다.

예를 들어 헤더로 생성된 를 응답에 추가하려면 다음과 같이 modeBeforeConsumer() 를 사용합니다.

.onCompletion().modeBeforeConsumer()
     .setHeader("createdBy", constant("Someone"))
 .end()

XML의 경우 mode 속성을 BeforeConsumer 로 설정합니다.

<onCompletion mode="BeforeConsumer">
   <setHeader headerName="createdBy">
     <constant>Someone</constant>
   </setHeader>
 </onCompletion>

Camel 2.14 사용 가능

Camel은 Camel 경로에 많은 기존 메트릭 통합을 제공하는 반면 Codahale 지표가 추가되었습니다. 이를 통해 최종 사용자는 Codahale 메트릭을 사용하여 수집하는 기존 데이터와 함께 Camel 라우팅 정보를 원활히 제공할 수 있습니다.

Codahale 메트릭을 사용하려면 다음이 필요합니다.

성능 메트릭은 표시 방법이 있는 경우에만 사용할 수 있습니다. metrics를 통해 사용할 수 있으므로, Cryostat와 통합할 수 있는 모든 종류의 모니터링 툴을 사용할 수 있습니다. 또한 실제 데이터는 100% Codehale JSON입니다.

단일 경로에 대한 Codahale 메트릭을 얻는 것은 경로별로 MetricsRoutePolicy 를 정의하여 수행할 수 있습니다.

Java에서 경로 정책으로 할당할 MetricsRoutePolicy 인스턴스를 생성합니다. 이는 아래에 표시되어 있습니다.

from("file:src/data?noop=true").routePolicy(new MetricsRoutePolicy()).to("jms:incomingOrders");

XML DSL에서 경로 정책으로 지정된 <bean >을 정의합니다. 예를 들면 다음과 같습니다.

<bean id="policy" class="org.apache.camel.component.metrics.routepolicy.MetricsRoutePolicy"/>

<camelContext xmlns="http://camel.apache.org/schema/spring">
  <route routePolicyRef="policy">
    <from uri="file:src/data?noop=true"/>
[...]

이 팩토리를 사용하면 Codahale 메트릭을 사용하여 경로 사용률 통계를 노출하는 각 경로에 RoutePolicy 를 추가할 수 있습니다. 아래 예제로 Java 및 XML에서 이 팩토리를 사용할 수 있습니다.

Java에서 다음과 같이 CamelContext 에 팩토리를 추가합니다.

context.addRoutePolicyFactory(new MetricsRoutePolicyFactory());

XML DSL에서 다음과 같이 < bean> 을 정의합니다.

<!-- use camel-metrics route policy to gather metrics for all routes -->
<bean id="metricsRoutePolicyFactory" class="org.apache.camel.component.metrics.routepolicy.MetricsRoutePolicyFactory"/>

다음과 같이 Java 코드에서 org.apache.camel.component.metrics.routepolicy.MetricsRegistryService 에서 com.codahale.metrics.MetricRegistry Registry를 유지할 수 있습니다.

MetricRegistryService registryService = context.hasService(MetricsRegistryService.class);
if (registryService != null) {
  MetricsRegistry registry = registryService.getMetricsRegistry();
  ...
}

MetricsRoutePolicyFactory 및 MetricsRoutePolicy 는 다음 옵션을 지원합니다.

Apache Camel을 사용하면 관리 이름 패턴을 정의하여 CamelContext 8080의 이름을 Cryostat에 표시할 수 있습니다. 예를 들어 다음과 같이 XML CamelContext 인스턴스의 이름 패턴을 사용자 지정할 수 있습니다.

<camelContext id="myCamel" managementNamePattern="#name#">
    ...
</camelContext>

CamelContext 8080의 이름 패턴을 명시적으로 설정하지 않으면 Apache Camel이 기본 이름 지정 전략으로 되돌아갑니다.

기본적으로 OSGi 번들에 배포된 CamelContext 8080의 Cryostat 이름은 번들의 OSGi 심볼릭 이름과 동일합니다. 예를 들어 OSGi 심볼릭 이름이 MyCamelBundle 인 경우 Cryostat 이름은 MyCamelBundle 입니다. 번들에 CamelContext 가 두 개 이상 있는 경우 counter 값을 접미사로 추가하여 Cryostat 이름을 모호하게 합니다. 예를 들어 MyCamelBundle 번들에 Camel 컨텍스트가 여러 개인 경우 해당 Cryostat의 이름이 다음과 같이 지정됩니다.

MyCamelBundle-1
MyCamelBundle-2
MyCamelBundle-3
...

기본 이름 지정 전략의 한 가지 단점은 지정된 CamelContext 8080이 실행 사이에 동일한 Cryostat 이름을 갖도록 보장할 수 없다는 것입니다. 실행 간에 일관성을 높이려면 CamelContext 인스턴스에 대한 Cryostat 이름 패턴을 정의하여 더 정확하게 이름을 제어할 수 있습니다.

Java의 CamelContext 에 이름 패턴을 지정하려면 다음과 같이 setNamePattern 메서드를 호출합니다.

// Java
context.getManagementNameStrategy().setNamePattern("#name#");

XML의 CamelContext 에 이름 패턴을 지정하려면 다음과 같이 camelContext 요소에 managementNamePattern 속성을 설정합니다.

<camelContext id="myCamel" managementNamePattern="#name#">

리터럴 텍스트와 다음 토큰 중 하나를 혼합하여 Cryostat 이름 패턴을 구성할 수 있습니다.

다음은 지원되는 토큰을 사용하여 정의할 수 있는 몇 가지 예제입니다.

<camelContext id="fooContext" managementNamePattern="FooApplication-#name#">
    ...
</camelContext>
<camelContext id="myCamel" managementNamePattern="#bundleID#-#symbolicName#-#name#">
    ...
</camelContext>

사용자 정의 이름 지정 패턴은 기본 이름 지정 전략을 재정의하므로 이 접근 방식을 사용하여 모호한 Cryostat 이름을 정의할 수 있습니다. 예를 들면 다음과 같습니다.

<camelContext id="foo" managementNamePattern="SameOldSameOld"> ... </camelContext>
...
<camelContext id="bar" managementNamePattern="SameOldSameOld"> ... </camelContext>

이 경우 시작 시 Apache Camel이 실패하고 Cryostat가 이미 예외가 존재하는 것으로 보고했습니다. 따라서 모호한 이름 패턴을 정의하지 않도록 주의해야 합니다.

allowUseOriginalMessage 옵션 기본 설정은 false 이며, 필요하지 않은 경우 원본 메시지에서 생성되는 복사본을 잘라냅니다. allowUseOriginalMessage 옵션을 활성화하려면 다음 명령을 사용합니다.

Apache Camel은 이 책의 대부분의 패턴, Gregor needhpe 및 Cryostatby Woolf의 Enterprise Integration Patterns 를 지원합니다.

표 3.1. “메시징 시스템” 에 표시된 메시징 시스템 패턴에는 메시징 시스템을 구성하는 기본 개념과 구성 요소가 도입되었습니다.

메시징 채널은 메시징 시스템의 참가자를 연결하는 데 사용되는 기본 구성 요소입니다. 표 3.2. “메시징 채널” 의 패턴은 사용 가능한 다양한 종류의 메시징 채널을 설명합니다.

표 3.3. “메시지 구조” 에 표시된 메시지 구성 패턴은 시스템을 통과하는 메시지의 다양한 양식과 기능을 설명합니다.

표 3.4. “메시지 라우팅” 에 표시된 메시지 라우팅 패턴은 메시지 스트림에 적용할 수 있는 다양한 알고리즘을 포함하여 메시지 채널을 함께 연결하는 다양한 방법을 설명합니다(메시지 본문을 수정하지 않음).

표 3.5. “메시지 Cryostat” 에 표시된 메시지 변환 패턴은 다양한 용도로 메시지 내용을 수정하는 방법을 설명합니다.

메시징 끝점은 메시징 채널과 애플리케이션 간의 연결 지점을 나타냅니다. 표 3.6. “메시징 끝점” 에 표시된 메시징 끝점 패턴은 끝점에서 구성할 수 있는 다양한 기능과 서비스 특성을 설명합니다.

표 3.7. “System Management” 에 표시된 시스템 관리 패턴은 메시징 시스템을 모니터링, 테스트 및 관리하는 방법을 설명합니다.

Apache Camel은 Camel 애플리케이션에서 REST 서비스를 정의하기 위한 다양한 접근 방식과 구성 요소를 제공합니다. 이 섹션에서는 이러한 다양한 접근 방식과 구성 요소에 대한 간략한 개요를 제공하여 요구 사항에 가장 적합한 구현 및 API를 결정할 수 있습니다.

REST( Representational State Transfer )는 GET,POST,PUT, DELETE 의 네 가지 기본 HTTP 동사만 사용하여 HTTP를 통해 데이터 전송을 중심으로 하는 분산 애플리케이션을 위한 아키텍처입니다.

HTTP를#159 메시지의 전송 프로토콜로 처리하는 Cryostat와 같은 프로토콜과 달리 REST 아키텍처는 HTTP를 직접 사용합니다. 주요 통찰력은 몇 가지 간단한 규칙에 의해 보강된 HTTP 프로토콜 자체는 분산 애플리케이션의 프레임워크 역할을 수행하기에 매우 적합합니다.

REST 아키텍처는 표준 HTTP 동사를 기반으로 빌드되므로 대부분의 경우 일반 브라우저를 REST 클라이언트로 사용할 수 있습니다. 예를 들어 호스트와 포트 localhost:9091 에서 실행되는 간단한 Hello World REST 서비스를 호출하려면 브라우저에서 다음과 같은 URL로 이동할 수 있습니다.

http://localhost:9091/say/hello/Garp

그런 다음 Hello World REST 서비스는 다음과 같은 응답 문자열을 반환할 수 있습니다.

Hello Garp

브라우저 창에 표시됩니다. 표준 브라우저(또는 curl 명령줄 유틸리티)를 사용하지 않고 REST 서비스를 쉽게 호출할 수 있는 것은 REST 프로토콜이 빠르게 인기를 얻는 많은 이유 중 하나입니다.

다음 REST 래퍼 계층은 REST 서비스를 정의하는 간단한 구문을 제공하며 다양한 REST 구현에 계층화할 수 있습니다.

Apache Camel은 다음 구성 요소를 통해 다양한 REST 구현을 제공합니다.

Cryostat -RS ( RESTful Web Services에 대한 Java API)는 REST 요청을 Java 오브젝트에 바인딩하기 위한 프레임워크입니다. 이 프레임워크는 바인딩을 정의하기 위해 Java 클래스를 Cryostat-RS 주석으로 데코레이팅해야 합니다. Cryostat-RS 프레임워크는 비교적 성숙하며 REST 서비스 개발을 위한 정교한 프레임워크를 제공하지만, 프로그래밍은 다소 복잡합니다.

Apache Camel과의 Cryostat-RS 통합은 Apache CXF를 통해 계층화된 CXFRS 구성 요소에 의해 구현됩니다. 개요에서 Cryostat-RS는 다음 주석을 사용하여 Java 클래스에 REST 요청을 바인딩합니다. 이 주석은 사용 가능한 많은 주석의 불완전한 샘플일 뿐입니다.

REST 요청 또는 REST 응답의 본문은 일반적으로 XML(190) 데이터 형식이어야 합니다. 그러나 Apache CXF는 JSON 메시지도 구문 분석할 수 있도록 JSON 형식으로 JSON 형식의 변환을 지원합니다.

자세한 내용은 Apache Camel 구성 요소 참조 가이드 및 Apache CXF 개발 가이드 의 CXFRS 를 참조하십시오.

REST DSL은 효과적으로 Java DSL 또는 XML DSL(Domain Specific Language)에서 REST 서비스를 정의하기 위한 간소화된 구문을 제공하는 facade 입니다. REST DSL은 실제로 REST 구현을 제공하지 않으며, 기존 REST 구현에 대한 래퍼일 뿐입니다(Apache Camel에 여러 가지가 있음).

REST DSL 래퍼 계층은 다음과 같은 이점을 제공합니다.

REST DSL은 실제 REST 구현이 아니므로 가장 먼저 수행해야 하는 작업 중 하나는 기본 구현을 제공하기 위해 Camel 구성 요소를 선택하는 것입니다. 현재 다음 Camel 구성 요소가 REST DSL과 통합되어 있습니다.

REST 구현을 지정하려면 restConfiguration() 빌더(Java DSL) 또는 restConfiguration 요소( XML DSL)를 사용합니다. 예를 들어 Spark-Rest 구성 요소를 사용하도록 REST DSL을 구성하려면 Java DSL에서 다음과 같은 빌더 표현식을 사용합니다.

restConfiguration().component("spark-rest").port(9091);

XML DSL에서 다음과 같은 요소를 사용합니다( camelContext의 자식으로).

<restConfiguration component="spark-rest" port="9091"/>

REST 서비스를 정의하는 Java DSL 구문은 다음과 같습니다.

rest("BasePath").Option().
    .Verb("Path").Option().[to() | route().CamelRoute.endRest()]
    .Verb("Path").Option().[to() | route().CamelRoute.endRest()]
    ...
    .Verb("Path").Option().[to() | route().CamelRoute];

CamelRoute 는 선택적 임베디드 Camel 경로입니다(라이스에 표준 Java DSL 구문을 사용하여 정의됨).

REST 서비스 정의는 rest() 키워드로 시작한 다음 특정 URL 경로 세그먼트를 처리하는 하나 이상의 동사 절을 사용합니다. HTTP 동사는 get(), head(), put(), post(), delete(), patch() 또는 verb() 중 하나일 수 있습니다. 각 verb 절은 다음 구문 중 하나를 사용할 수 있습니다.

Java에서 REST DSL을 사용하여 서비스를 정의하려면 일반 Apache Camel 경로와 마찬가지로 RouteBuilder.configure() 메서드 본문에 REST 정의를 배치합니다. 예를 들어, Spark-Rest 구성 요소와 함께 REST DSL을 사용하여 간단한 Hello World 서비스를 정의하려면 다음 Java 코드를 정의합니다.

restConfiguration().component("spark-rest").port(9091);

rest("/say")
    .get("/hello").to("direct:hello")
    .get("/bye").to("direct:bye");

from("direct:hello")
    .transform().constant("Hello World");
from("direct:bye")
    .transform().constant("Bye World");

이전 예제에서는 세 가지 종류의 빌더를 제공합니다.

XML에서 XML DSL을 사용하여 서비스를 정의하려면 rest 요소를 camelContext 요소의 자식으로 정의합니다. 예를 들어, Spark-Rest 구성 요소와 함께 REST DSL을 사용하여 간단한 Hello World 서비스를 정의하려면 다음 XML 코드( 블루프린트에서)를 정의합니다.

<camelContext xmlns="http://camel.apache.org/schema/blueprint">
  <restConfiguration component="spark-rest" port="9091"/>

  <rest path="/say">
    <get uri="/hello">
      <to uri="direct:hello"/>
    </get>
    <get uri="/bye">
      <to uri="direct:bye"/>
    </get>
  </rest>

  <route>
    <from uri="direct:hello"/>
    <transform>
      <constant>Hello World</constant>
    </transform>
  </route>
  <route>
    <from uri="direct:bye"/>
    <transform>
      <constant>Bye World</constant>
    </transform>
  </route>
</camelContext>

rest() 키워드(Java DSL) 또는 rest 요소의 path 속성( XML DSL)을 사용하면 기본 경로를 정의할 수 있으며, 기본 경로 앞에 모든 동사 절이 추가됩니다. 예를 들어 다음 Java DSL 조각이 제공됩니다.

rest("/say")
    .get("/hello").to("direct:hello")
    .get("/bye").to("direct:bye");

또는 다음 XML DSL 조각이 제공됩니다.

<rest path="/say">
  <get uri="/hello">
    <to uri="direct:hello"/>
  </get>
  <get uri="/bye" consumes="application/json">
    <to uri="direct:bye"/>
  </get>
</rest>

REST DSL 빌더는 다음과 같은 URL 매핑을 제공합니다.

/say/hello
/say/bye

기본 경로는 선택 사항입니다. 원하는 경우 각 동사 절에 전체 경로를 지정할 수 있습니다.

rest()
    .get("/say/hello").to("direct:hello")
    .get("/say/bye").to("direct:bye");

REST DSL은 toD 동적 매개 변수를 지원합니다. 이 매개변수를 사용하여 URI를 지정합니다.

예를 들어 JMS에서 동적 엔드포인트 URI는 다음과 같은 방식으로 정의할 수 있습니다.

public void configure() throws Exception {
   rest("/say")
     .get("/hello/{language}").toD("jms:queue:hello-${header.language}");
}

XML DSL에서 다음과 같은 세부 정보가 표시됩니다.

<rest uri="/say">
  <get uri="/hello//{language}">
    <toD uri="jms:queue:hello-${header.language}"/>
  </get>
<rest>

toD 동적 매개 변수에 대한 자세한 내용은 “동적 대상” 을 참조하십시오.

동사 인수에서는 이름이 지정된 속성( Camel 메시지 헤더에 매핑됨)에서 특정 경로 세그먼트를 캡처할 수 있는 URI 템플릿을 지정할 수 있습니다. 예를 들어 Hello World 애플리케이션을 이름별로 호출하도록 사용자 지정하려는 경우 다음과 같은 REST 서비스를 정의할 수 있습니다.

rest("/say")
    .get("/hello/{name}").to("direct:hello")
    .get("/bye/{name}").to("direct:bye");

from("direct:hello")
    .transform().simple("Hello ${header.name}");
from("direct:bye")
    .transform().simple("Bye ${header.name}");

URI 템플릿은 {name} 경로 세그먼트의 텍스트를 캡처하고 이 캡처된 텍스트를 이름 메시지 헤더에 복사합니다. /say/hello/Joe 로 끝나는 URL로 GET HTTP 요청을 전송하여 서비스를 호출하면 HTTP 응답은 Hello ctlplane 입니다.

to() 키워드(Java DSL) 또는 to 요소( XML DSL)로 verb 절을 종료하는 대신 route() 키워드(Java DSL) 또는 경로 요소( XML DSL)를 사용하여 Apache Camel 경로를 REST DSL에 직접 포함할 수 있습니다. route() 키워드를 사용하면 다음 구문을 사용하여 동사 절에 경로를 포함할 수 있습니다.

RESTVerbClause.route("...").CamelRoute.endRest()

여기서 endRest() 키워드(Java DSL만 해당)는 동사 절을 분리할 수 있는 필수 문장 부호입니다( rest() 빌더에 두 개 이상의 동사 절이 있는 경우).

예를 들어 Java DSL에서 다음과 같이 포함된 Camel 경로를 사용하도록 Hello World 예제를 리팩터링할 수 있습니다.

rest("/say")
    .get("/hello").route().transform().constant("Hello World").endRest()
    .get("/bye").route().transform().constant("Bye World");

XML DSL의 예는 다음과 같습니다.

<camelContext xmlns="http://camel.apache.org/schema/blueprint">
  ...
  <rest path="/say">
    <get uri="/hello">
      <route>
        <transform>
          <constant>Hello World</constant>
        </transform>
      </route>
    </get>
    <get uri="/bye">
      <route>
        <transform>
          <constant>Bye World</constant>
        </transform>
      </route>
    </get>
  </rest>
</camelContext>

HTTP 전송 구성 요소를 명시적으로 구성하지 않으면 REST DSL은 classpath에서 사용 가능한 구성 요소를 확인하여 사용할 HTTP 구성 요소를 자동으로 검색합니다. REST DSL은 모든 HTTP 구성 요소의 기본 이름을 찾고 찾은 첫 번째 구성 요소를 사용합니다. classpath에 HTTP 구성 요소가 없고 HTTP 전송을 명시적으로 구성하지 않은 경우 기본 HTTP 구성 요소는 camel-http 입니다.

consumes() 를 사용하여 HTTP 요청 및 응답의 콘텐츠 유형을 필터링하고 Java에서 () 옵션을 생성하거나 XML로 속성을 사용하고 생성할 수 있습니다. 예를 들어, 몇 가지 일반적인 콘텐츠 유형(알림적으로 인터넷 미디어 유형)은 다음과 같습니다.

콘텐츠 유형은 REST DSL의 동사 절에 옵션으로 지정됩니다. 예를 들어, text/plain HTTP 요청만 수락하고 text/html HTTP 응답만 전송하도록 verb 절을 제한하려면 다음과 같은 Java 코드를 사용합니다.

rest("/email")
    .post("/to/{recipient}").consumes("text/plain").produces("text/html").to("direct:foo");

XML에서는 다음과 같이 사용 및 특성을 생성할 수 있습니다.

<camelContext xmlns="http://camel.apache.org/schema/blueprint">
  ...
  <rest path="/email">
    <post uri="/to/{recipient}" consumes="text/plain" produces="text/html">
      <to "direct:foo"/>
    </get>
  </rest>
</camelContext>

사용할 인수를 지정하거나 ( )를 쉼표 로 구분된 목록으로 지정할 수도 있습니다. 예를 들어 "text/plain, application/json"을 사용합니다.

일부 HTTP 서버 구현은 추가 HTTP 메서드를 지원합니다. REST DSL의 표준 동사 세트인 get(), head(), put(), post(), delete(), patch(). 추가 HTTP 메서드에 액세스하려면 일반 키워드인 verb() 를 Java DSL 및 일반 요소인 verb 에서 XML DSL로 사용할 수 있습니다.

예를 들어 Java에서 TRACE HTTP 메서드를 구현하려면 다음을 수행합니다.

rest("/say")
    .verb("TRACE", "/hello").route().transform();

여기서 transform() 은 IN 메시지의 본문을 OUT 메시지의 본문으로 복사하므로 HTTP 요청을 에코합니다.

XML에서 TRACE HTTP 메서드를 구현하려면 다음을 수행합니다.

<camelContext xmlns="http://camel.apache.org/schema/blueprint">
  ...
  <rest path="/say">
    <verb uri="/hello" method="TRACE">
      <route>
        <transform/>
      </route>
    </get>
</camelContext>

REST 서비스에서 응답으로 오류 메시지를 보내야 하는 경우 다음과 같이 사용자 정의 HTTP 오류 메시지를 정의할 수 있습니다.

다음 Java 예제에서는 사용자 정의 오류 메시지를 정의하는 방법을 보여줍니다.

// Java
// Configure the REST DSL, with JSON binding mode
restConfiguration().component("restlet").host("localhost").port(portNum).bindingMode(RestBindingMode.json);

// Define the service with REST DSL
rest("/users/")
    .post("lives").type(UserPojo.class).outType(CountryPojo.class)
        .route()
            .choice()
                .when().simple("${body.id} < 100")
                    .bean(new UserErrorService(), "idTooLowError")
                .otherwise()
                    .bean(new UserService(), "livesWhere");

이 예에서 입력 ID가 100보다 작으면 다음과 같이 구현된 UserErrorService pin을 사용하여 사용자 지정 오류 메시지를 반환합니다.

// Java
public class UserErrorService {
    public void idTooLowError(Exchange exchange) {
        exchange.getIn().setBody("id value is too low");
        exchange.getIn().setHeader(Exchange.CONTENT_TYPE, "text/plain");
        exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE, 400);
    }
}

UserErrorService pin에서 사용자 지정 오류 메시지를 정의하고 HTTP 오류 코드를 400 으로 설정합니다.

들어오는 Camel 메시지의 헤더에 기본값을 지정할 수 있습니다.

쿼리 매개변수에 대한 상세 정보와 같은 키워드를 사용하여 기본값을 지정할 수 있습니다. 예를 들어 아래 코드에서 기본값은 false 입니다. 즉, verbose 키가 있는 헤더에 다른 값이 제공되지 않으면 false 가 기본값으로 삽입됩니다.

rest("/customers/")
    .get("/{id}").to("direct:customerDetail")
    .get("/{id}/orders")
      .param()
	.name("verbose")
	.type(RestParamType.query)
	.defaultValue("false")
	.description("Verbose order details")
      .endParam()
        .to("direct:customerOrders")
    .post("/neworder").to("direct:customerNewOrder");

사용자 지정 오류 메시지를 반환할 수 있는 일반적인 경우는 JsonParserException 예외를 래핑하기 위한 것입니다. 예를 들어 다음과 같이 Camel 예외 처리 메커니즘을 편리하게 악용하여 HTTP 오류 코드 400을 사용하여 사용자 정의 HTTP 오류 메시지를 생성할 수 있습니다.

// Java
onException(JsonParseException.class)
    .handled(true)
    .setHeader(Exchange.HTTP_RESPONSE_CODE, constant(400))
    .setHeader(Exchange.CONTENT_TYPE, constant("text/plain"))
    .setBody().constant("Invalid json data");

일반적으로 REST DSL 옵션은 다음과 같이 서비스 정의의 기본 부분(즉, 즉시 rest())에 직접 적용할 수 있습니다.

rest("/email").consumes("text/plain").produces("text/html")
    .post("/to/{recipient}").to("direct:foo")
    .get("/for/{username}").to("direct:bar");

이 경우 지정된 옵션은 모든 하위 동사 절에 적용됩니다. 또는 옵션은 다음과 같이 각 동사 절에 적용할 수 있습니다.

rest("/email")
    .post("/to/{recipient}").consumes("text/plain").produces("text/html").to("direct:foo")
    .get("/for/{username}").consumes("text/plain").produces("text/html").to("direct:bar");

지정된 옵션은 관련 동사 절에만 적용되는 경우 기본 부분의 설정을 재정의합니다.

표 4.1. “REST DSL 옵션” REST DSL에서 지원하는 옵션을 요약합니다.

REST 프로토콜을 사용하는 가장 일반적인 방법 중 하나는 메시지 본문에 Java 빈의 내용을 전송하는 것입니다. 이 기능이 작동하려면 적절한 데이터 형식으로 Java 개체를 마샬링하는 메커니즘이 필요합니다. Java 오브젝트 인코딩에 적합한 다음 데이터 형식은 REST DSL에서 지원합니다.

물론 메시지 본문을 Java 개체로 변환하거나 직접 변환하는 데 필요한 코드를 작성할 수 있습니다. 그러나 REST DSL은 이러한 변환을 자동으로 수행할 수 있는 편의성을 제공합니다. 특히 JSON 및 CryostatB와 REST DSL을 통합하면 다음과 같은 이점이 있습니다.

Apache Camel은 JSON 및 CryostatB 데이터 형식의 다양한 구현을 제공합니다. 다음 데이터 형식은 현재 REST DSL에서 지원합니다.