2장. 경로 빌드의 기본 사항

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 메시지로 복사됩니다.