Apache Camel은 정확히 무엇입니까?
답변:
5 분에서 10 분 정도의 시간이 있다면 일반적으로 Jonathan Anstey의 Apache Camel과의 통합 을 읽는 것이 좋습니다 . Camel의 일부 개념에 대한 간략한 소개와 개요를 제공하는 잘 작성된 기사이며 코드 샘플과 함께 유스 케이스를 구현합니다. 그 안에 Jonathan은 다음과 같이 씁니다.
Apache Camel은 개발자가보다 쉽게 통합 할 수 있도록하는 오픈 소스 Java 프레임 워크입니다. 다음을 제공하여이를 수행합니다.
- 널리 사용되는 모든 EIP ( Enterprise Integration Patterns ) 의 구체적인 구현
- 다양한 전송 및 API에 대한 연결
- DSL (Domain Specific Languages)을 사용하여 EIP와 전송을 함께 연결
첫 번째 장에서 낙타를 소개하는 Camel in Action 의 무료 장도 있습니다. Jonathan은 저와 저 책의 공동 저자입니다.
좀 더 접근하기 쉬운 방법으로 설명하려고합니다.
Apache Camel이 무엇인지 이해하려면 Enterprise Integration Patterns가 무엇인지 이해해야합니다.
우리가 이미 알고있는 것으로 시작해 봅시다 : 싱글 톤 패턴, 팩토리 패턴 등; 문제에 대한 솔루션을 구성하는 방법 일 뿐이지 만 솔루션 자체는 아닙니다. 이 패턴들은 그들의 책 : Design Patterns 을 출판했을 때, Gang of Four에 의해 나머지 사람들을 위해 분석되고 추출되었습니다 . 그들은 코드를 가장 잘 구성하는 방법을 생각하는 데 엄청난 노력을 아끼지 않았습니다.
많은 네의 갱처럼, 그레고르 Hohpe 바비 울프는 책을 저술 엔터프라이즈 통합 패턴 들이 제안하고 새로운 패턴의 집합 문서화하는 (EIP) 청사진 우리가 할 수 방법에 대한 최고의 디자인 대형 컴포넌트 기반 시스템, 구성 요소가 될 수있는 곳을 동일한 프로세스 또는 다른 시스템에서 실행 중입니다.
그들은 기본적으로 시스템을 메시지 지향 으로 구성 할 것을 제안합니다 . 구성 요소는 메시지를 입력 및 출력으로 사용하고 다른 것은 전혀 사용하지 않고 구성 요소가 서로 통신합니다. 전체 시스템을 구성하는 다양한 구성 요소에서 선택하고 구현할 수있는 완전한 패턴 세트를 보여줍니다.
그렇다면 Apache Camel은 무엇입니까?
Apache Camel은 EIP에 대한 인터페이스, 기본 객체, 일반적으로 필요한 구현, 디버깅 도구, 구성 시스템 및 기타 많은 헬퍼를 제공하여 EIP를 따르기 위해 솔루션을 구현할 때 많은 시간을 절약 할 수 있습니다.
MVC를 가져 가라. MVC는 이론상 매우 간단하며 프레임 워크 도움없이 구현할 수 있습니다. 그러나 훌륭한 MVC 프레임 워크는 즉시 사용할 수있는 구조를 제공하며, 큰 MVC 프로젝트를 만들 때 필요한 다른 모든 "측면"을 고려하여 가장 많이 사용하는 이유입니다.
이것이 바로 Apache Camel이 EIP를위한 것입니다. EIP를 준수하기 위해 솔루션을 구현하려는 사람들을위한 완벽한 프로덕션 준비 프레임 워크입니다.
프로젝트 설명을 작성하는 것은 복잡하지 않아야합니다.
내가 말하다:
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을 사용하여 표준화 된 방식으로 수행 할 수 있습니다 (이미 개발 된 대부분의 커넥터가 있으므로 프로세스를 설정하고 논리를 프로세스하면됩니다).
낙타가 당신을 도울 것입니다 :
- 모든 소스 / 포맷에서 데이터 소비
- 이 데이터 처리
- 모든 소스 / 포맷으로 데이터 출력
Apache Camel을 사용하면 시스템을 다른 개발자에게 쉽게 이해 / 유지 / 확장 할 수 있습니다.
Apache Camel은 Enterprise Integration Patterns로 개발되었습니다. 패턴은 시스템을 좋은 방법으로 통합하는 데 도움이됩니다.
Camel은 A에서 B로 메시지를 보냅니다.
왜 이것이 전체 프레임 워크입니까? 글쎄, 당신이 가지고 있다면 :
- 많은 발신자와 수신자
- 프로토콜 다스 (
ftp,http,jms등) - 많은 복잡한 규칙
- 수신자 A와 B에게만 메시지 A 보내기
- 메시지 B를 수신자 C 에 XML로 보내지 만, 부분적으로 변환 하고, 보강 하고 (메타 데이터 추가) IF 조건 X 를 수신자 D에도 CSV 로 보내십시오 .
이제 다음이 필요합니다.
- 프로토콜 간 번역
- 접착제구성 요소를 서로
- 경로 정의- 어디로 가는가
- 어떤 경우에는 몇 가지를 필터링
낙타는 상자에서 위와 같은 것을 제공합니다.
무엇과 방법을 정의 할 수있는 멋진 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");
}
분석에 기초
항공사 소유주 (예 : American Airlines, Jet Airways)의 신발을 착용하면 낙타 기반 노선을 쉽게 이해할 수 있습니다.
'항공사'의 목적은 '도시'에서 다른 도시로 '승객'을 '운반'하는 것입니다. 승객을 운송하기 위해 Boeing, Airbus, HAL과 같은 다른 '항공 회사'의 항공기를 사용합니다.
항공사는 출발 도시의 '공항'을 사용하여 승객을 탑승시키고 출발 도시의 공항을 사용하여 탑승자를 탑승시킵니다. 승객은 여러 도시로 '여행'할 수 있지만 항공사의 항공기와 도시 사이를 여행하려면 공항을 통과해야하는 모든 곳이 있습니다.
도시에서 출발하는 승객은 본질적으로 항공사의 항공기에 '도착'됩니다. 그리고 도시로 '도착'하는 통행인은 본질적으로 항공기에서 출발합니다. 우리는 항공사 소유자의 입장에 있기 때문에 '도착 승객'과 '출국 승객'이라는 용어는 도시의 관점에 기초한 기존의 개념과 반대입니다.
각 도시의 동일한 '공항'인프라는 '출발'승객과 '도착'승객이 사용합니다. 공항은 출발 승객에게 '출발 인프라'를 제공하며, 이는 도착 승객에게 제공되는 '도착 인프라'와 다릅니다.
승객은 여행 중에 항공사가 항공기 내부에서 제공하는 다양한 '시설'로 인해 하루 종일 활동을 계속할 수 있습니다.
또한 항공사는 '현지 언어 이해'또는 '여행'준비와 같은 특별 대우를위한 라운지 시설도 제공합니다.
위에서 사용한 몇 가지 단어 / 구절을 다음과 같이 바꾸자.
귀하의 항공사 : Apache Camel
항공기 회사 : 운송 메커니즘
항공사의 항공기 : Apache Camel의 기본 운송 메커니즘
캐리 : 경로
승객 : 메시지;
도시 : 시스템;
공항 : 낙타 구성 요소;
현지 언어 이해 : 유형 변환;
출발 : 생산, 생산
도착 : 소비, 소비
여행 : 라우팅
편의 시설 : 제공
단어를 바꾸면 다음과 같은 결과가 나타납니다.
'아파치 낙타'의 목적 메시지'를 하나의 '시스템'에서 다른 시스템으로 라우팅하는 것입니다. Apache camel은 메시지 라우팅에 다른 전송 메커니즘을 사용합니다.
Apache Camel은 'from'시스템의 'Camel based Component'를 사용하여 메시지를 선택하고 'to'시스템의 'Camel based Component'를 사용하여 메시지를 삭제합니다. 메시지는 여러 시스템으로 라우팅 될 수 있지만 'Apache Camel의 기본 전송 메커니즘'과 시스템 사이를 이동하려면 'Camel based Components'를 거쳐야합니다.
시스템에서 '생성 된'메시지는 기본적으로 Apache Camel의 기본 전송 메커니즘에 '소비'됩니다. 그리고 시스템이 소비하는 메시지는 본질적으로 'Apache Camel의 기본 전송 메커니즘'에 의해 생성됩니다.
우리는 Camel을 이해하려고 노력하고 있기 때문에 Camel의 관점에서 생각해야합니다. '소비자 메시지'와 '제작자 메시지'라는 용어의 의미는 시스템의 관점을 기반으로하는 기존의 개념과 반대입니다.
'생산자 메시지'와 '소비자 메시지'에서 동일한 'Camel based Component'의 코딩 인프라가 사용됩니다. 'Camel based Component'는 '생산자 메시지'에 대한 '생산자 엔드 포인트'와 '소비자 메시지'에 대한 '소비자 엔드 포인트'를 제공합니다.
메시지가 라우팅 될 때 Camel이 메시지를 처리 할 수 있습니다.
이 라우팅 외에도 Camel은 'Type Conversion'과 같은 특별한 기능을 제공합니다.
Apache Camel을 이해하기 전에 이해해야 할 사항 중 하나는 엔터프라이즈 통합 패턴입니다. 현장의 모든 사람이 실제로 알고있는 것은 아닙니다. 엔터프라이즈 통합 패턴 책을 확실히 읽을 수는 있지만 빠른 속도를내는 방법은 엔터프라이즈 응용 프로그램 통합 에 대한 Wikipedia 기사와 같은 것을 읽는 것 입니다.
주제 영역을 읽고 이해했다면 Apache Camel의 목적을 훨씬 더 잘 이해할 것입니다
HTH
다른 관점에서의 정의 :
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은 Java Domain Specific Language 또는 DSL 을 사용하여 아래 나열된 다양한 DSL (Domain-Specific Language)로 엔터프라이즈 통합 패턴 또는 라우트를 작성합니다.
Java DSL- 유창한 빌더 스타일을 사용하는 Java 기반 DSL.
엔터프라이즈 통합 패턴 이야기는 다음 개념을 해결합니다.
메시지, 엔드 포인트, 프로듀서, 소비자, 라우팅, 버스, 변환 및 프로세스 .
실시간 사용 사례 중 하나에 대해서는 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 pattern)이며 여기에 잘 설명되어 있습니다 . Apache camel은 EIP를 사용하여 솔루션을 구현하는 데 도움이됩니다.
통합 프레임 워크의 강점은 EIP 또는 기타 패턴, 전송 및 구성 요소 수, Apache 낙타가 목록의 최상위에있는 개발 용이성을 통해 우리를 용이하게하는 기능입니다
각 프레임 워크에는 고유 한 장점이 있습니다. Apache 낙타의 일부 특수 기능은 다음과 같습니다.
- 많은 DSL, 즉 Java DSL 및 Spring xml 기반 DSL에 코딩이 널리 사용됩니다.
- 사용하기 쉽고 사용하기 쉽습니다.
- 퓨즈 IDE는 UI를 통해 코딩하는 데 도움이되는 제품입니다
평범한 영어로, 낙타는 많은 보일러 판 코드없이 (많은) 일을합니다.
아래에 제공된 Java DSL은 관점을 제공하기 위해 제품 목록으로 구성된 XML을 수락하여 여러 제품으로 분할하고 BrandProcessor의 Process 메소드를 호출 할 수있는 REST 엔드 포인트를 작성합니다. 그리고 .parallelProcessing (주석 처리 된 부분 참고)을 추가하면 모든 제품 개체를 병렬 처리합니다. (제품 클래스는 입력 xml이 제한되어있는 XSD에서 JAXB / XJC 생성 Java 스텁입니다.)이 많은 코드 (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을 살펴보십시오 .
101 단어 소개
Camel은 응용 프로그램을 통합하기위한 일관된 API 및 프로그래밍 모델을 갖춘 프레임 워크입니다. API는 엔터프라이즈 통합 패턴의 이론 , 즉 메시징을 사용하는 경향이있는 디자인 패턴에 기반합니다. 이 패턴은 대부분의 패턴을 즉시 구현할 수 있으며 200 개 이상의 서로 다른 구성 요소 와 함께 제공됩니다. 모든 종류의 다른 시스템과 쉽게 대화하는 데 사용할 수있는 됩니다. Camel을 사용하려면 먼저 POJO로 비즈니스 로직을 작성하고 메시지 중심의 간단한 인터페이스를 구현하십시오. 그런 다음 Camel의 DSL을 사용하여 응용 프로그램을 함께 붙이기위한 규칙 집합 인 "경로"를 만듭니다.
확장 된 소개
표면적으로 Camel의 기능은 전통적인 Enterprise Service Bus 제품과 경쟁합니다. 우리는 일반적으로 Camel Route를 서버 측에있는 "중재"(일명 오케스트레이션) 구성 요소로 생각하지만 Java 라이브러리이기 때문에 포함하기 쉽고 클라이언트 측 앱에서도 작동하고 통합 할 수 있습니다. 포인트 투 포인트 서비스 (일명 안무)와 함께. Camel 라우트 내부의 메시지를 처리하는 POJO를 가져 와서 독립적 인 단일 소비자 프로세스로 쉽게 분리 할 수 있습니다 (예 : 독립적으로 하나만 확장해야하는 경우). Camel을 사용하여 필요에 따라 다양한 원격 전송 / 프로토콜을 통해 경로 또는 프로세서를 연결할 수 있습니다. 매우 효율적이고 빠른 이진 프로토콜이 필요하십니까? 또는 사람이 더 읽기 쉽고 디버깅하기 쉬운 것입니까? 전환하려면 어떻게해야합니까? Camel을 사용하면 일반적으로 경로에서 한두 줄을 변경하고 비즈니스 로직을 전혀 변경하지 않는 것처럼 쉽습니다. 또는 둘 다 지원할 수 있습니다-낙타 컨텍스트에서 한 번에 많은 경로를 자유롭게 실행할 수 있습니다.
단일 프로세스 또는 JVM에서 작동하는 간단한 응용 프로그램에 실제로 Camel을 사용할 필요는 없습니다. 그러나 직접 작성하는 코드보다 개념적으로 어렵지 않습니다. 또한 요구 사항이 변경되면 비즈니스 로직과 글루 코드가 분리되어 시간이 지남에 따라 유지 관리가 쉬워집니다. Camel API를 배우면 Swiss-Army 나이프처럼 쉽게 사용할 수 있으며 여러 상황에서 빠르게 적용하여 다른 방법으로 작성해야 할 사용자 정의 코드의 양을 줄일 수 있습니다. 하나의 특징 인 Java DSL (예 : 서로 연결하기 쉬운 유창한 API)을 배우고 다른 특징을 쉽게 선택할 수 있습니다.
마이크로 서비스를 수행하려는 경우 전체 낙타가 적합합니다. 프로토콜, 전송 및 기타 시스템 통합 문제에 대한 어렵고 "잘못 이해하기 쉬운"결정을 문제 도메인에 대해 더 많이 알 때까지 연기 할 수 있기 때문에 진화론 적 아키텍처에는 매우 유용합니다. EIP와 핵심 비즈니스 로직에 중점을두고 자세히 배울 때 "올바른"구성 요소로 새로운 경로로 전환하십시오.
예, 아마도 조금 늦었을 것입니다. 그러나 다른 사람들의 의견에 덧붙일 한 가지는 Camel이 실제로 완전한 기능 세트가 아니라 도구 상자라는 것입니다. 개발할 때이 점을 명심하고 다양한 변환 및 프로토콜 변환을 수행해야합니다.
낙타 자체는 다른 프레임 워크에 의존하기 때문에 때로는 귀하의 요구에 가장 적합한 것을 이해하기 위해 프레임 워크를 이해해야합니다. 예를 들어 REST를 처리하는 여러 가지 방법이 있습니다. 처음에는 약간 혼란 스러울 수 있지만 일단 사용하고 테스트하기 시작하면 안심하고 다른 개념에 대한 지식이 높아집니다.
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>당신의 질문에오고
- 정확히 무엇입니까? Ans :-엔터프라이즈 통합 패턴을 구현하는 프레임 워크입니다.
- Java로 작성된 응용 프로그램과 어떻게 상호 작용합니까? 답변 :-http, ftp, amqp 등과 같은 사용 가능한 프로토콜과 상호 작용할 수 있습니다.
- 서버와 함께 제공되는 것입니까? Ans : Tomcat과 같은 컨테이너에 배포하거나 Java 프로세스로 독립적으로 배포 할 수 있습니다
- 독립 프로그램입니까? 답변 :-가능합니다.
그것이 도움이되기를 바랍니다.
Apache Camel은 모든 엔터프라이즈 통합 패턴을 구현하는 경량 통합 프레임 워크입니다. 필요한 패턴을 사용하여 다른 응용 프로그램을 쉽게 통합 할 수 있습니다. Java, Spring XML, Scala 또는 Groovy를 사용할 수 있습니다.
Apache Camel은 JVM (Java Virtual Machine)에서 실행됩니다. ... Apache Camel의 핵심 기능은 라우팅 엔진입니다. 관련 경로를 기반으로 메시지를 할당합니다. 경로에는 흐름 및 통합 논리가 포함됩니다. EIP 및 특정 DSL을 사용하여 구현됩니다.
파이프 라인 연결처럼
From---->Tou 사이에 많은 채널과 파이프를 추가 할 수 있습니다. 수도꼭지는 데이터 흐름을위한 자동 또는 수동 유형과 흐름을 채널 화하는 경로 일 수 있습니다.
모든 유형과 종류의 처리를 지원하고 구현합니다. 동일한 처리를 위해서는 많은 구성 요소가 있으며 각 구성 요소는 다른 방법을 사용하여 원하는 출력을 제공 할 수 있기 때문에 많은 접근 방식이 필요합니다.
예를 들어, 파일 전송은 파일이 이동 또는 복사 된 유형과 함께 낙타에서 수행 될 수 있으며 폴더, 서버 또는 대기열에서도 수행 될 수 있습니다.
-from-->To
- from-->process-->to
- from-->bean-->to
- from-->process-->bean-->to
-from-->marshal-->process-->unmarshal-->toFrom / to ---- folder, direct, seda, vm은 무엇이든 될 수 있습니다
또 다른 관점 (보다 기본적인 수학적 주제에 기초)
가장 일반적인 컴퓨팅 플랫폼은 [ https://en.wikipedia.org/wiki/Turing_machine]입니다.
튜링 기계에 문제가 있습니다. 모든 입력 / 출력 데이터는 튜링 머신 내부에 유지됩니다. 실제로는 튜링 머신 외부에 입력 소스 및 출력 싱크가 있으며 일반적으로 제어 외부의 시스템에 의해 관리됩니다. 즉, 이러한 외부 시스템은 원하는 데이터 스케줄러와 함께 원하는 형식으로 원하는대로 데이터를 송수신 할 수 있습니다.
질문 : 독립적 인 튜링 머신이 가장 일반적인 방식으로 서로 대화하도록 각 튜링 머신이 피어를 입력 데이터 소스 또는 출력 데이터 싱크로 인식하도록하려면 어떻게해야합니까?
답변 : 낙타, 노새, BizTalk 또는 다른 ESB와 같은 것을 사용하여 별개의 "물리적"(또는 가상 소프트웨어) 튜링 머신을 완성하는 것 사이의 데이터 처리를 추상화합니다.