나는 Camel 이 정확히 무엇을 하는지 이해하지 못합니다.
Camel에 대한 소개를 101 단어로 제공할 수 있다면:
- 정확히 무엇입니까?
- Java로 작성된 응용 프로그램과 어떻게 상호 작용합니까?
- 서버와 함께 하는 것인가요?
- 독립 프로그램인가요?
Camel이 무엇인지 설명해주세요.
질문자 :Myy
나는 Camel 이 정확히 무엇을 하는지 이해하지 못합니다.
Camel에 대한 소개를 101 단어로 제공할 수 있다면:
Camel이 무엇인지 설명해주세요.
더 접근하기 쉬운 방식으로 이것을 설명하기 위해 내 생각은 ...
Apache Camel이 무엇인지 이해하려면 엔터프라이즈 통합 패턴 이 무엇인지 이해해야 합니다.
우리가 이미 알고 있는 것부터 시작합시다: Singleton 패턴 , Factory 패턴 등; 그것들은 문제에 대한 솔루션을 구성하는 방법일 뿐이지 솔루션 자체는 아닙니다. 이 패턴은 Gang of Four가 저서: Design Patterns를 출판할 때 분석하고 추출했습니다. 그들은 코드를 가장 잘 구성하는 방법에 대해 생각하는 엄청난 노력을 절약했습니다.
Gang of Four와 마찬가지로 Gregor Hohpe와 Bobby Woolf는 EIP(Enterprise Integration Patterns) 라는 책을 저술하여 구성 요소를 사용할 수 있는 대규모 구성 요소 기반 시스템을 가장 잘 설계할 수 있는 방법에 대한 일련의 새로운 패턴과 청사진을 제안하고 문서화합니다. 동일한 프로세스 또는 다른 시스템에서 실행 중입니다.
그들은 기본적으로 우리가 메시지 지향적으로 시스템을 구성할 것을 제안합니다. 여기서 구성 요소는 메시지를 입력 및 출력으로 사용하고 다른 것은 전혀 사용하지 않고 서로 통신합니다. 그것들은 우리가 전체 시스템을 함께 형성할 다양한 구성 요소에서 선택하고 구현할 수 있는 완전한 패턴 세트를 보여줍니다.
그렇다면 Apache Camel은 무엇입니까?
Apache Camel은 EIP, 기본 개체, 일반적으로 필요한 구현, 디버깅 도구, 구성 시스템 및 EIP를 따르도록 솔루션을 구현하려는 경우 많은 시간을 절약할 수 있는 기타 여러 도우미에 대한 인터페이스를 제공합니다.
MVC를 가져 가라. MVC는 이론상 매우 간단하며 프레임워크의 도움 없이 구현할 수 있습니다. 그러나 좋은 MVC 프레임워크는 바로 사용할 수 있는 구조를 제공하고 대규모 MVC 프로젝트를 생성할 때 필요한 다른 모든 "측면" 요소를 고려하여 대부분의 시간을 사용하는 이유입니다.
이것이 바로 Apache Camel이 EIP를 위한 것입니다. EIP를 따르기 위해 솔루션을 구현하려는 사람들을 위한 완전한 프로덕션 준비 프레임워크입니다.
5~10분의 시간이 있다면 일반적으로 Jonathan Anstey의 이 Integration with Apache Camel을 읽을 것을 권장합니다. Camel의 일부 개념에 대한 간략한 소개와 개요를 제공하고 코드 샘플을 사용하여 사용 사례를 구현하는 잘 작성된 글입니다. 그 안에 조나단은 다음과 같이 쓰고 있습니다.
Apache Camel은 개발자가 더 쉽고 쉽게 통합할 수 있도록 하는 데 중점을 둔 오픈 소스 Java 프레임워크입니다. 다음을 제공하여 이를 수행합니다.
- 널리 사용되는 모든 EIP( Enterprise Integration Pattern)의 구체적인 구현
- 다양한 전송 및 API에 대한 연결
- EIP와 전송을 함께 연결하기 위해 사용하기 쉬운 DSL(Domain Specific Languages)
Camel in Action 의 무료 챕터(Camel in Action, 2nd ed. is here )도 첫 번째 챕터에서 Camel을 소개합니다. Jonathan은 나와 함께 그 책의 공동 저자입니다.
프로젝트 설명을 작성하는 것은 복잡하지 않아야 합니다.
내가 말하다:
Apache Camel은 라우팅이 포함된 메시징 기술 접착제입니다. 메시징 시작점과 끝점을 함께 결합하여 다른 소스에서 다른 대상으로 메시지를 전송할 수 있습니다. 예: JMS -> JSON, HTTP -> JMS 또는 퍼널링 FTP -> JMS, HTTP -> JMS, JSON -> JMS
위키피디아에서는 다음과 같이 말합니다.
Apache Camel은 라우팅 및 중개 규칙을 구성하기 위해 API(또는 선언적 Java 도메인 특정 언어)를 사용하여 엔터프라이즈 통합 패턴의 Java 개체 기반 구현을 제공하는 규칙 기반 라우팅 및 중개 엔진입니다. 도메인 특정 언어는 Apache Camel이 대량의 XML 구성 파일 없이 일반 Java 코드를 사용하여 IDE에서 라우팅 규칙의 유형 안전 스마트 완성을 지원할 수 있음을 의미합니다. Spring 내부의 XML 구성도 지원됩니다.
보다? 어렵지 않던데요?
간단히 말해서:
시스템 연결/통합에 대한 요구 사항이 있는 경우 일부 데이터 소스에 연결한 다음 비즈니스 요구 사항에 맞게 이 데이터를 처리해야 할 수 있습니다.
그렇게 하려면:
1) 당신은 그것을 할 사용자 정의 프로그램을 개발할 수 있습니다 (다른 개발자를 위해 유지하는 데 시간이 많이 걸리고 이해하기 어려울 수 있음)
2) 또는 Apache Camel을 사용하여 표준화된 방식으로 수행할 수 있습니다(대부분의 커넥터가 이미 개발되어 있으므로 설정하고 로직을 연결하기만 하면 됩니다 - Process라고 함).
낙타는 당신을 도울 것입니다:
Apache Camel을 사용하면 시스템을 쉽게 이해/유지/확장할 수 있습니다.
Apache Camel은 엔터프라이즈 통합 패턴으로 개발되었습니다. 패턴은 시스템을 좋은 방식으로 통합하는 데 도움이 됩니다 :-)
낙타는 A에서 B로 메시지를 보냅니다.
왜 이것을 위한 전체 프레임워크인가? 글쎄, 당신이 가지고있는 경우 :
ftp
, http
, jms
등)이제 다음이 필요합니다.
Camel은 기본적으로 위(및 그 이상)를 제공합니다.
무엇을, 어떻게 정의할 수 있는 멋진 DSL 언어로:
new DefaultCamelContext().addRoutes(new RouteBuilder() { public void configure() { from("jms:incomingMessages") .choice() // start router rules .when(header("CamelFileName") .endsWith(".xml")) .to("jms:xmlMessages") .when(header("CamelFileName") .endsWith(".csv")) .to("ftp:csvMessages"); }
this and this 및 Camel in Action도 참조하십시오(다른 사람들이 말했듯이, 훌륭한 책입니다!)
다이어그램은 수천 개의 설명보다 낫습니다. 이 다이어그램은 Camel의 아키텍처를 보여줍니다.
유추 기반
낙타 기반 라우팅은 항공사 소유자(예: American Airlines, Jet Airways)의 입장에서 생각해 보면 훨씬 쉽게 이해할 수 있습니다.
'귀하의 항공사'의 목적은 세계의 한 '도시'에서 다른 '도시'로 '승객'을 '운송'하는 것입니다. 보잉(Boeing), 에어버스(Airbus), HAL과 같은 다양한 '항공기 회사'의 항공기를 승객 수송에 사용합니다.
귀하의 항공사는 출발 도시의 '공항'을 사용하여 승객을 태우고 도착 도시의 공항을 사용하여 승객을 내립니다. 승객은 여러 도시로 '여행'할 수 있지만 항공사의 항공기와 도시 사이를 여행하려면 어디에서나 공항을 거쳐야 합니다.
도시에서 '출발'하는 승객은 본질적으로 귀하의 항공사 항공기에 '도착'한다는 점에 유의하십시오. 그리고 도시로 '도착'하는 승객은 본질적으로 항공기에서 출발합니다. 항공사 오너 입장에서 '도착여객'과 '출발여객'이라는 용어는 기존의 도시적 관점에서 탈피한 것이다.
각 도시의 동일한 '공항' 인프라는 '출발' 승객과 '도착' 승객이 사용합니다. 공항은 출발하는 승객을 위한 '출발 인프라'를 제공하는데, 이는 도착하는 승객에게 제공되는 '도착 인프라'와 다릅니다.
승객은 여행하는 동안 항공사에서 항공기 내부에 제공하는 다양한 '어메니티'로 인해 일상 활동을 계속할 수 있습니다.
또한, 귀하의 항공사는 '현지 언어 이해' 및 또는 '여행' 준비와 같은 특별 대우를 위한 라운지 시설도 제공합니다.
위에서 사용된 몇 가지 단어/구를 다음으로 대체할 수 있습니다.
귀하의 항공사: Apache Camel
항공기 회사: 운송 메커니즘
항공사 항공기: Apache Camel의 기본 운송 메커니즘
나르다: 경로
승객: 메시지;
도시: 시스템;
공항: 낙타 구성 요소;
현지 언어 이해: 유형 변환;
출발: 생산, 생산
도착하다: 소비하다, 소비하다
여행: 라우팅
어메니티: 제공
단어를 바꾼 후 다음을 얻습니다.
'Apache Camel'의 목적은 세계의 한 '시스템'에서 다른 '시스템'으로 '메시지'를 라우팅하는 것입니다. Apache camel은 메시지 라우팅에 다른 전송 메커니즘을 사용합니다.
Apache Camel은 'from' 시스템의 'Camel based Component'를 사용하여 메시지를 선택하고 'to' 시스템의 'Camel based Component'를 사용하여 메시지를 삭제합니다. 메시지는 여러 시스템으로 라우팅될 수 있지만 모든 곳에서 'Apache Camel의 기본 전송 메커니즘'과 시스템 사이를 이동하기 위해 'Camel 기반 구성 요소'를 거쳐야 합니다.
시스템에서 '생성된' 메시지는 기본적으로 Apache Camel의 기본 전송 메커니즘으로 '소비'됩니다. 그리고 시스템이 소비하는 메시지는 기본적으로 'Apache Camel의 기본 전송 메커니즘'에 의해 생성됩니다.
우리는 Camel을 이해하려고 하므로 여기서부터는 Camel의 관점에서 생각해야 합니다. 따라서 '소비자 메시지'와 '생산자 메시지'라는 용어의 의미는 시스템 관점에 기반한 기존의 개념과 반대입니다.
'생산자 메시지'와 '소비자 메시지'는 동일한 'Camel 기반 구성 요소' 코딩 인프라를 사용합니다. 'Camel based Component'는 'producer message'를 위한 'producer endpoint'와 'consumer message'를 위한 'consumer endpoint'를 제공한다.
메시지가 라우팅될 때 Camel에서 처리할 수 있습니다.
이 라우팅 위에 Camel은 '유형 변환'과 같은 특수 기능과 더 많은 기능을 제공합니다...
Apache Camel을 이해하기 전에 이해해야 할 사항 중 하나는 엔터프라이즈 통합 패턴입니다. 현장의 모든 사람들이 실제로 그것들을 알고 있는 것은 아닙니다. Enterprise Integration Patterns 책을 확실히 읽을 수는 있지만 더 빨리 익히는 방법은 Enterprise Application Integration 에 대한 Wikipedia 기사와 같은 것을 읽는 것입니다.
주제 영역을 읽고 이해했다면 Apache Camel의 목적을 훨씬 더 이해할 수 있을 것입니다.
HTH
엔터프라이즈 통합 패턴을 알고 있다면 Apache Camel은 모든 EIP를 구현하는 하나의 통합 프레임워크입니다.
그리고 Camel을 웹 컨테이너에 독립 실행형 애플리케이션으로 배포할 수 있습니다.
기본적으로 서로 다른 프로토콜과 기술로 여러 응용 프로그램을 통합해야 하는 경우 Camel을 사용할 수 있습니다.
다른 관점에서 정의:
Apache Camel은 통합 프레임워크입니다. Java 플랫폼에서 통합 문제를 구현하는 데 도움이 되는 일부 Java 라이브러리로 구성됩니다. 이것이 의미하는 바와 API가 한쪽에 있고 ESB(Enterprise Service Bus)와 어떻게 다른지는 내 기사 " Apache Camel을 사용하는 경우 "에 설명되어 있습니다.
정확히 무엇입니까?
Apache Camel 은 많은 엔터프라이즈 통합 패턴을 구현하는 경량 통합 프레임워크입니다. 필요한 패턴을 사용하여 다양한 애플리케이션을 쉽게 통합할 수 있습니다.
Java, Spring XML, Scala 또는 Groovy를 사용할 수 있습니다. HTTP, FTP, JMS, EJB, JPA, RMI, JMS, JMX, LDAP, Netty 등과 같이 상상할 수 있는 거의 모든 기술을 사용할 수 있습니다.
이 기사 와 EIP 패턴 기사를 살펴보십시오.
Java로 작성된 응용 프로그램과 어떻게 상호 작용합니까?
Camel은 아래 나열된 다양한 도메인 특정 언어(DSL)로 엔터프라이즈 통합 패턴 또는 경로를 생성하기 위해 Java 도메인 특정 언어 또는 DSL을 사용합니다.
Java DSL - 유창한 빌더 스타일을 사용하는 Java 기반 DSL입니다.
Enterprise Integration Pattern의 이야기는 다음 개념을 해결합니다.
메시지, 끝점, 생산자, 소비자, 라우팅, 버스, 변환 및 프로세스 .
실시간 사용 사례 중 하나는 Anirban Konar의 이 기사를 참조하십시오.
서버와 함께 하는 것인가요?
여러 엔터프라이즈 하위 시스템을 연결하는 다리 역할을 합니다.
독립 프로그램인가요?
통합 프레임워크인 Apache Camel은 다양한 독립 애플리케이션을 통합합니다.
Camel의 주요 장점 : 모든 통합에 동일한 개념을 사용하여 다른 기술(및 다른 프로토콜)을 사용하여 다른 응용 프로그램을 통합할 수 있습니다.
컴퓨팅에서 대부분의 "새로운" 것은 실제로 전혀 새로운 것이 아니며 이미 잘 알려진 무언가를 둘러싼 신비로운 포장지일 뿐입니다. 때있는 거 누군가가 새로운 언어 용어를 발명하기로 결정하거나 다른 목적으로 기존의 용어 식민지 때문에, 그것은 보통이다 (그 좋은 예는 무엇을 "클라이언트"와 "서버"평균의 X 개발자 '반전입니다.) 이해하기 어려운
Camel은 애플리케이션 간 미들웨어를 위한 Java 기반 래퍼/API입니다.
미들웨어는 공통 언어나 데이터 유형을 공유하지 않는 엔터티 간에 통역 서비스를 제공하는 소프트웨어의 총칭입니다.
그것이 낙타가 무엇인지, 맨 아래에 있습니다. EIP 유형 미들웨어를 제공한다는 점을 참고하여 설명을 구체화할 수 있습니다.
애플리케이션이 통신해야 하는 세부 사항을 알 수 없기 때문에 미들웨어 자체를 제공하지 않습니다. 그러나 해당 미들웨어의 불변 부분을 생성하기 위한 API를 제공합니다(시작점 생성, 끝점 생성, 시작 및 종료 조건 생성 등).
도움이 되기를 바랍니다.
여기에 또 다른 시도가 있습니다.
Webmethods, ICAN Seebeyond, Tibco BW, IBM Broker와 같은 것들이 어떻게 존재하는지 알고 있습니다. 그들은 모두 기업의 통합 솔루션을 도왔습니다. 이러한 도구는 일반적으로 EAI(Enterprise Application Integration) 도구라는 이름으로 알려져 있습니다.
대부분 이러한 기술을 기반으로 구축된 드래그 드롭 도구가 있었고 일부는 Java로 어댑터를 작성해야 했습니다. 이러한 어댑터 코드는 테스트되지 않았거나 테스트와 관련된 도구/자동화가 열악했습니다.
프로그래밍의 디자인 패턴과 마찬가지로 일반적인 통합 솔루션에 대한 엔터프라이즈 통합 패턴이 있습니다. 그들은 Gregor Hohpe와 Bobby Woolf의 같은 이름의 책으로 유명해졌습니다.
하나 또는 여러 EIP를 사용하는 통합 솔루션을 구현하는 것이 가능하지만 Camel은 XML, Java, Groovy 또는 Scala 중 하나를 사용하여 코드 기반 내에서 이를 수행하려는 시도입니다.
Camel은 풍부한 DSL 및 라우팅 메커니즘을 통해 책에 나열된 모든 엔터프라이즈 통합 패턴을 지원합니다.
따라서 Camel은 통합 코드 테스트를 더 잘 지원하는 다른 EAI 도구와 경쟁하는 기술입니다. DSL(Domain Specific Languages) 때문에 코드가 간결합니다. 비즈니스 사용자도 읽을 수 있으며 무료이며 생산성을 높여줍니다.
메시징 및 메시징 문제 해결을 용이하게 하는 많은 프레임워크가 있습니다. 그러한 제품 중 하나가 Apache Camel입니다.
대부분의 일반적인 문제는 디자인 패턴이라고 하는 입증된 솔루션을 가지고 있습니다. 메시징을 위한 디자인 패턴은 여기에 잘 설명된 EIP(Enterprise Integration Patterns)입니다. Apache camel은 EIP를 사용하여 솔루션을 구현하는 데 도움이 됩니다.
통합 프레임워크의 강점은 EIP 또는 기타 패턴, 전송 및 구성 요소의 수, Apache camel이 목록의 맨 위에 있는 개발 용이성을 통해 우리를 용이하게 하는 능력입니다.
각 프레임워크에는 고유한 장점이 있습니다. Apache camel의 일부 특수 기능은 다음과 같습니다.
평범한 영어로 낙타는 보일러 플레이트 코드 없이 (많은) 일을 합니다.
관점을 제공하기 위해 아래에 제공된 Java DSL은 제품 목록으로 구성된 XML을 수락하고 이를 여러 제품으로 분할하고 BrandProcessor의 Process 메소드를 호출할 수 있는 REST 엔드포인트를 생성합니다. 그리고 .parallelProcessing(주석 처리된 부분 참고)을 추가하면 모든 제품 개체를 병렬 처리합니다. (제품 클래스는 입력 xml이 제한된 XSD에서 생성된 JAXB/XJC입니다.) 이 많은 코드(몇몇 Camel 종속성과 함께)는 100줄의 Java 코드를 사용하는 데 사용되는 작업을 완료합니다.
from("servlet:item-delta?matchOnUriPrefix=true&httpMethodRestrict=POST") .split(stax(Product.class)) /*.parallelProcessing()*/ .process(itemDeltaProcessor);
경로 ID 및 로깅 구문을 추가한 후
from("servlet:item-delta?matchOnUriPrefix=true&httpMethodRestrict=POST") .routeId("Item-DeltaRESTRoute") .log(LoggingLevel.INFO, "Item Delta received on Item-DeltaRESTRoute") .split(stax(Product.class)) .parallelProcessing() .process(itemDeltaProcessor);
이것은 샘플일 뿐이며 Camel은 REST 엔드포인트 그 이상입니다. 플러그인 가능한 구성 요소 목록을 살펴보십시오. http://camel.apache.org/components.html
Amazon과 같은 전자 상거래 회사를 만들고 판매할 제품의 전략/선택에만 집중하려고 한다고 가정합니다. 아마존 배송 함대와 달리 판매자에서 창고로 상품 이동을 직접 처리하는 대신 포장과 같이 창고에서 변경하여 다른 도시 및 고객에게 발송합니다. 이 모든 작업을 수행하는 회사를 고용하고 모든 창고 위치, 차량 유형, 배송 위치 및 언제 무엇을 해야 하는지에 대한 정보만 제공합니다. 그런 다음 그들은 그것을 스스로 처리합니다. Apache Camel이 될 것입니다. 그들은 물건을 한 쪽 끝에서 다른 쪽 끝으로 옮기는 일을 처리합니다. 일단 물건을 넘겨주면 다른 일에 자유롭게 집중할 수 있습니다.
낙타는 라우팅, 변환, 모니터링에 도움이 됩니다.
경로를 사용합니다. 다음과 같이 설명할 수 있습니다.
서비스 버스는 특정 메시지를 수신하면 대기열/주제와 같은 서비스/브로커 대상을 통해 라우팅하지 않습니다. 이 경로를 경로라고 합니다.
예: 귀하의 주식 응용 프로그램은 분석가의 일부 입력을 받았고 응용 프로그램/웹 구성 요소를 통해 처리된 다음 특정 주식 업데이트에 대해 관심/등록된 모든 회원에게 결과가 게시됩니다.
Camel은 애플리케이션을 함께 통합하기 위한 일관된 API 및 프로그래밍 모델이 있는 프레임워크입니다. API는 엔터프라이즈 통합 패턴의 이론, 즉 메시징을 사용하는 경향이 있는 디자인 패턴을 기반으로 합니다. 대부분의 이러한 패턴의 즉시 사용 가능한 구현을 제공하며 모든 종류의 다른 시스템과 쉽게 통신하는 데 사용할 수 있는 200개 이상의 다양한 구성 요소가 추가로 제공됩니다. Camel을 사용하려면 먼저 POJO에 비즈니스 로직을 작성하고 메시지를 중심으로 간단한 인터페이스를 구현하십시오. 그런 다음 Camel의 DSL을 사용하여 응용 프로그램을 함께 연결하기 위한 규칙 집합인 "경로"를 만듭니다.
표면적으로 Camel의 기능은 기존 Enterprise Service Bus 제품과 경쟁합니다. 우리는 일반적으로 Camel Route를 서버 측에 있는 "중재"(일명 오케스트레이션) 구성 요소라고 생각하지만 Java 라이브러리이기 때문에 포함하기 쉽고 클라이언트 측 앱에도 있을 수 있으며 통합하는 데 도움이 됩니다. 포인트 투 포인트 서비스(일명 안무)를 사용합니다. Camel 경로 내에서 메시지를 처리하는 POJO를 가져와서 자체 원격 소비자 프로세스로 쉽게 분리할 수도 있습니다(예: 한 조각만 독립적으로 확장해야 하는 경우). Camel을 사용하여 필요에 따라 다양한 원격 전송/프로토콜을 통해 경로 또는 프로세서를 연결할 수 있습니다. 매우 효율적이고 빠른 바이너리 프로토콜이 필요하십니까? 아니면 사람이 읽기 쉽고 디버그하기 쉬운 프로토콜이 필요하십니까? 전환하고 싶다면? Camel을 사용하면 일반적으로 경로에서 한두 줄을 변경하고 비즈니스 로직을 전혀 변경하지 않는 것만큼 쉽습니다. 또는 둘 다 지원할 수 있습니다. Camel 컨텍스트에서 한 번에 많은 경로를 자유롭게 실행할 수 있습니다.
단일 프로세스 또는 JVM에서 실행될 간단한 애플리케이션에는 Camel을 사용할 필요가 없습니다. 그러나 개념적으로는 직접 작성할 수 있는 코드보다 어렵지 않습니다. 요구 사항이 변경되는 경우 비즈니스 로직과 글루 코드를 분리하면 시간이 지남에 따라 유지 관리가 더 쉬워집니다. Camel API를 배우면 스위스군용 칼처럼 사용하기 쉽고 다양한 컨텍스트에서 빠르게 적용하여 작성해야 하는 사용자 지정 코드의 양을 줄일 수 있습니다. 하나의 특징(예: 함께 연결하기 쉬운 유창한 API와 같은 Java DSL)을 배우고 다른 특징을 쉽게 선택할 수 있습니다.
전반적으로 Camel은 마이크로 서비스를 수행하려는 경우 적합합니다. 문제 영역에 대해 더 많이 알 때까지 프로토콜, 전송 및 기타 시스템 통합 문제에 대한 어렵고 "잘못되기 쉬운" 결정을 많이 미룰 수 있기 때문에 진화적 아키텍처에 매우 중요하다는 것을 알았습니다. EIP와 핵심 비즈니스 로직에 집중하고 "올바른" 구성 요소가 포함된 새로운 경로로 전환하면 됩니다.
Apache Camel은 엔터프라이즈 통합을 위한 Java 프레임워크입니다. 예:- 많은 공급업체 API와 상호 작용하는 웹 애플리케이션을 구축하는 경우 낙타를 외부 통합 도구로 사용할 수 있습니다. 사용 사례에 따라 더 많은 작업을 수행할 수 있습니다. Manning 출판물의 Camel in Action은 Camel을 배우기에 좋은 책입니다. 통합은 아래와 같이 정의할 수 있습니다.
자바 DSL
from("jetty://0.0.0.0:8080/searchProduct").routeId("searchProduct.products").threads() .log(LoggingLevel.INFO, "searchProducts request Received with body: ${body}") .bean(Processor.class, "createSearchProductsRequest").removeHeaders("CamelHttp*") .setHeader(Exchange.HTTP_METHOD, constant(org.apache.camel.component.http4.HttpMethods.POST)) .to("http4://" + preLiveBaseAPI + searchProductsUrl + "?apiKey=" + ApiKey + "&bridgeEndpoint=true") .bean(Processor.class, "buildResponse").log(LoggingLevel.INFO, "Search products finished");
이것은 외부 API를 호출하고 다시 요청을 보내는 REST API 엔드포인트를 생성하는 것입니다.
스프링 DSL
<route id="GROUPS-SHOW"> <from uri="jetty://0.0.0.0:8080/showGroups" /> <log loggingLevel="INFO" message="Reqeust receviced service to fetch groups -> ${body}" /> <to uri="direct:auditLog" /> <process ref="TestProcessor" /> </route>
귀하의 질문에 온다
도움이 되기를 바랍니다.
예, 이것은 아마도 조금 늦을 것입니다. 그러나 다른 모든 사람의 의견에 추가해야 할 한 가지는 Camel이 실제로 완전한 기능 세트라기보다는 도구 상자라는 것입니다. 개발할 때 이를 염두에 두고 다양한 변환 및 프로토콜 변환을 수행해야 합니다.
Camel 자체는 다른 프레임워크에 의존하므로 때로는 어떤 프레임워크가 귀하의 요구에 가장 적합한지 이해하기 위해 이러한 프레임워크도 이해해야 합니다. 예를 들어 REST를 처리하는 여러 가지 방법이 있습니다. 이것은 처음에는 약간 혼란스러울 수 있지만 일단 사용하고 테스트하기 시작하면 편안함을 느끼고 다양한 개념에 대한 지식이 증가할 것입니다.
Apache Camel은 모든 엔터프라이즈 통합 패턴을 구현하는 경량 통합 프레임워크입니다. 필요한 패턴을 사용하여 다양한 애플리케이션을 쉽게 통합할 수 있습니다. Java, Spring XML, Scala 또는 Groovy를 사용할 수 있습니다.
Apache Camel은 JVM(Java Virtual Machine)에서 실행됩니다. ... Apache Camel의 핵심 기능은 라우팅 엔진입니다. 관련 경로를 기반으로 메시지를 할당합니다. 경로에는 흐름 및 통합 논리가 포함됩니다. EIP와 특정 DSL을 사용하여 구현됩니다.
파이프라인을 연결하는 것과 같습니다.
From---->To
그 사이에 많은 채널과 파이프를 추가할 수 있습니다. 수도꼭지는 데이터의 흐름과 흐름을 채널화하는 경로를 위한 자동 또는 수동 모든 유형이 될 수 있습니다.
모든 유형 및 종류의 처리를 지원하고 구현합니다. 그리고 동일한 처리에 대해 많은 구성 요소가 있고 각 구성 요소는 그 아래에 다른 방법을 사용하여 원하는 출력을 제공할 수 있기 때문에 많은 접근 방식을 사용합니다.
예를 들어, 파일 전송은 이동 또는 복사된 파일 유형과 폴더, 서버 또는 대기열에서 낙타로 수행할 수 있습니다.
-from-->To - from-->process-->to - from-->bean-->to - from-->process-->bean-->to -from-->marshal-->process-->unmarshal-->to
From/to----folder, direct, seda, vm은 무엇이든 될 수 있습니다.
또 다른 관점(보다 근본적인 수학 주제에 기반)
가장 일반적인 컴퓨팅 플랫폼은 Turing Machine 입니다.
튜링 기계에 문제가 있습니다. 모든 입/출력 데이터는 튜링 기계 내부에 유지됩니다. 현실 세계에는 Turing 기계 외부에 입력 소스와 출력 싱크가 있으며 일반적으로 우리가 제어할 수 없는 시스템에 의해 관리됩니다. 즉, 이러한 외부 시스템은 원하는 데이터 스케줄러를 사용하여 원하는 형식으로 데이터를 송수신합니다.
질문: 독립적인 튜링 머신이 가장 일반적인 방식으로 서로 말하도록 하여 각 튜링 머신이 동료를 입력 데이터의 소스 또는 출력 데이터의 싱크로 볼 수 있도록 하려면 어떻게 해야 합니까?
답변: 낙타, 노새, BizTalk 또는 별개의 "물리적"(또는 가상 소프트웨어) 튜링 머신을 완성하는 사이의 데이터 처리를 추상화하는 기타 ESB를 사용합니다.
출처 : http:www.stackoverflow.com/questions/8845186/what-exactly-is-apache-camel
뷰 컨트롤러 간에 데이터 전달 (0) | 2022.03.07 |
---|---|
Python 스크립트를 어떻게 프로파일링할 수 있습니까? (0) | 2022.03.07 |
GitHub 리포지토리에서 단일 폴더 또는 디렉터리 다운로드 (0) | 2022.03.07 |
파일을 만들고 쓰는 방법은 무엇입니까? (0) | 2022.03.07 |
Android 회전 시 활동 다시 시작 (0) | 2022.03.07 |