1.2. Basic Java DSL Syntax


1.2.1. DSL이란 무엇입니까?

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의 다음 명령과 동일함).

1.2.2. 라우터 규칙 구문

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

그림 1.1. 로컬 라우팅 규칙

로컬 라우팅 규칙

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

참고

특수 프로세서 유형(예: intercept(), exception() 또는 errorHandler())으로 규칙을 시작하여 글로벌 라우팅 규칙을 정의할 수도 있습니다. 글로벌 규칙은 이 가이드의 범위를 벗어납니다.

1.2.3. 소비자 및 생산자

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

1.2.4. Exchanges

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

  • message Cryostat- Cryostat는 교환에 의해 캡슐화된 현재 메시지입니다. 경로를 통해 교환이 진행됨에 따라 이 메시지가 수정될 수 있습니다. 따라서 경로 시작 시 In 메시지는 일반적으로 경로 끝에 있는 In 메시지와 동일하지 않습니다. org.apache.camel.Message 유형은 다음 부분과 함께 메시지의 일반 모델을 제공합니다.

    • 본문.
    • headers.
    • 첨부 파일.

    이것이 메시지의 일반적인 모델임을 인식하는 것이 중요합니다. Apache Camel은 다양한 프로토콜 및 엔드포인트 유형을 지원합니다. 따라서 메시지 본문 또는 메시지 헤더의 형식을 표준화할 수 없습니다. 예를 들어 JMS 메시지의 본문은 HTTP 메시지 또는 웹 서비스 메시지의 본문과 완전히 다른 형식을 갖습니다. 이러한 이유로 본문과 헤더는 Object 유형으로 선언됩니다. 그런 다음 본문과 헤더의 원래 내용은 교환 인스턴스를 만든 엔드포인트(즉, from() 명령에 나타나는 끝점)에 의해 결정됩니다.

  • Explicit - message는 응답 메시지 또는 변환된 메시지의 임시 유지 영역입니다. 특정 처리 노드(특히 to() 명령)는 In 메시지를 요청으로 처리하고 생산자 엔드포인트로 보낸 다음 해당 끝점에서 응답을 수신하여 현재 메시지를 수정할 수 있습니다. 그런 다음 응답 메시지가 교환의 Out 메시지 슬롯에 삽입됩니다.

    일반적으로 Out 메시지가 현재 노드에서 설정된 경우 Apache Camel은 경로의 다음 노드에 전달할 때 다음과 같이 교환을 수정합니다. 이전 In 메시지는 삭제되고 Out 메시지는 In 메시지 슬롯으로 이동합니다. 따라서 응답은 새 현재 메시지가 됩니다. Apache Camel이 노드를 경로에서 함께 연결하는 방법에 대한 자세한 내용은 2.1절. “파이프라인 처리” 을 참조하십시오.

    그러나 외부 메시지가 다르게 처리되는 특별한 경우가 있습니다. 경로 시작 시 소비자 끝점에 응답 메시지가 예상되는 경우 경로의 맨 끝에 있는 Out 메시지가 소비자 끝점의 응답 메시지(및 더 많은 경우 최종 노드가 아웃 메시지 또는 소비자 끝점이 중단됨)로 이동합니다.

  • message exchange pattern (MEP) Cryostat-propertyffects the interaction between the exchange and endpoints in the route, as follows:

    • 원래 교환을 생성하는 소비자 끝점은 MEP의 초기 값을 설정합니다. 초기 값은 소비자 끝점이 응답을 수신할지(예: InOut MEP)를 수신할지 여부를 나타냅니다(예: InOnly MEP).
    • 생산자 엔드포인트 (MEP)는 경로를 따라 교환이 발생하는 생산자 끝점에 영향을 미칩니다(예: 교환이 to() 노드를 통과하는 경우). 예를 들어 현재 MEP가 InOnly 이면 to() 노드는 끝점에서 응답을 수신할 것으로 예상하지 않습니다. 때때로 교환의 생산자 엔드 포인트와의 상호 작용을 사용자 정의하기 위해 현재 MEP를 변경해야하는 경우가 있습니다. 자세한 내용은 1.4절. “끝점” 에서 참조하십시오.
  • 현재 메시지에 대한 메타데이터를 포함하는 이름이 지정된 속성의 목록 exchange properties that contains metadata for the current message

1.2.5. 메시지 교환 패턴

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

  • InOnly
  • RobustInOnly
  • InOut
  • InOptionalOut
  • OutOnly
  • RobustOutOnly
  • OutIn
  • OutOptionalIn

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

1.2.6. 그룹화된 교환

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

1.2.7. 프로세서

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

1.2.8. 표현식 및 서술자

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

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

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

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.