Apache Camel 및 기타 ESB 제품


81

Hey,
Apache Camel이 있다면 Apache ServiceMix 및 Mule과 같은 다른 솔루션을 사용해야하는 이유는 무엇입니까?
Apache Camel이이 제품과 비교할 때 할 수없는 것이 있습니까?
Mule / ServiceMix는 언제 사용하고 Camel은 언제 사용합니까?

답변:


73

Apache Camel은 EIP (엔터프라이즈 통합 패턴)를 구현하는 라이브러리입니다. Spring을 IOC 프레임 워크로 사용할 수 있지만 Spring에 의존하지도 않으므로 완전히 플랫폼 독립적입니다. 그것은 "그냥"도서관입니다. 따라서 간단한 jvm, servlet, ejb, osgi와 같은 모든 JVM 환경에서 실행할 수 있습니다. 노새와 같은 컨테이너의 이점 (또는 오버 헤드)을 가져 오지 않습니다. 제 생각에는이 분야에 대한 우려의 분리가 더 명확 해졌습니다.

Mule은 다른 환경에도 내장 될 수 있지만 Mule은 EIP 라이브러리를 컨테이너에 결합하는 장점과 단점을 모두 가지고 있다고 생각합니다. 서블릿 또는 ejb 환경 내에 Mule을 배포 할 때 Mule 컨테이너의 모든 수하물을 운반하고 싶습니까? 저는 Mule 전문가가 아니므로 비교적 약간의 노력을 기울이고 일부 중복 기능을 제거 할 수있을 것입니다. (이것은 모든 경우에 나쁜 기능은 아니며 다른 컨테이너 내부에 포함 된 경우에만 중복됩니다.)

Apache ServiceMix는 Camel을 사용하여 EIP를 ESB의 기반으로 구현하는 OSGI 컨테이너입니다. ServiceMix는 역사적으로 JBI에 뿌리를두고 시작했지만 JBI에서 벗어나 OSGI 컨테이너에서 동종 최고의 Apache CXF, Camel 및 ActiveMQ를 결합한 멋진 계층 구조 인 (IMO)로 발전했습니다. 여기서 주요 가치는 실제로 ServiceMix 및 JBI 지원이 아니라 기본 OSGI 컨테이너 표준입니다.웹 서비스 용 CXF 및 JMS 용 ActiveMQ와 같은 입증 된 Apache 전송과 결합됩니다. OSGI는 .NET이 출현하기 전에 Microsoft를 괴롭혔던 동일한 유형의 "DLL"지옥을 처리하는 컨테이너를 제공하는 성숙한 표준입니다. .NET이나 OSGI는 근본적인 문제의 본질적인 복잡성을 해결하지 못하지만 적어도 문제를 해결할 수있는 수단을 제공합니다. OSGI에는 다른 이점도 있지만 제품 선택 관점에서 표준 기반 컨테이너가 기본이며 Mule (및 일반적으로 Java)이 다루지 않는 필수 기능은 종속성 관리입니다.

Mule과 Apache 커뮤니티를 비교할 때 유의해야 할 몇 가지 중요한 사항입니다. Mule은 오픈 소스 라이선스이지만 실제로는 오픈 커뮤니티가 아니라는 점에서 Redhat과 같습니다. 누구나 Apache에 참여할 수 있지만 MuleSoft는 Mule 커뮤니티와 최종 로드맵을 소유합니다. 둘째, Mule 커뮤니티는 꽤 활동적이지만 Apache 커뮤니티가 훨씬 더 크다고 생각합니다 (그리고 당연히 게이트 커뮤니티가 아니기 때문에). 두 접근법 모두 장단점이 있습니다. Apache 접근 방식에 대한 한 가지 긍정적 인 점은 Camel, CXF, ActiveMQ 및 OSGI를 기반으로하는 ESB에 대한 여러 공급 업체가 있다는 것입니다. 예를 들어 Talend는 ServiceMix JBI 기록없이 동일한 핵심 기술에 ESB를 제공합니다. 여기에는 Apache 커뮤니티 내에서 장점과 단점이 모두 있습니다. 하지만 진짜 요점은 Apache와 Mule의 차이점을 강조하는 것입니다. Mule 커뮤니티에서 여러 공급 업체를 찾을 수 없습니다. 따라서 Talend 또는 ServiceMix와 같은 Apache ESB 인 IMO는 Mule과 같은 폐쇄 된 커뮤니티보다 더 광범위하고 포괄적이며 궁극적으로 경쟁적인 커뮤니티입니다.

에드 오스트


76

지금은 2016 년이고 처음 질문을받은 이후 많은 변화가 있었기 때문에 새로운 시청자를 위해 다시 방문하고 싶습니다.

전략적으로 말하면

  • Apache Camel 은 그 뿌리에 충실 했으며 헤비급 또는 완전한 런타임 플랫폼으로 발전하지 않았습니다. 다용도 및 모듈 식이며 다음을 실행할 수 있습니다.

    1. 임베디드 자바 컨테이너 (서블릿 컨테이너, 애플리케이션 서버, 봄 부팅) 모든 종류의에.
    2. Java 프로세스로 독립형 .
    3. OSGi 환경 ( Apache Karaf ) 내부 .
  • Apache Camel은 제가 OpenHub 에서 추출한이 지점 아래의 그래프로 묘사 된 것처럼 매월 지속적으로 발전하고 견인력과 활동을 얻었습니다 . 사용자 기반도 계속 증가하고 있습니다.

매월 Apache Camel 기여자

  • 2012 년 Red Hat은 Apache Camel, ActiveMQ, ServiceMix 및 CXF의 주요 프로모터이자 개발자 중 하나 인 FuseSource를 인수했습니다 . 이제 Red Hat은 여러 커미터와 PMC 멤버를 고용하여 Apache Camel을 작업합니다.

  • 뮬 ESB가 제공하는 그들의 제품의 두 가지 버전 : 커뮤니티 합니다 (CPAL의 라이센스하에 무료) 및 엔터프라이즈 (지불). 커뮤니티 버전을 다음과 같이 정의합니다 .

평가 또는 사전 제작 사용에 이상적입니다.

=> 프로덕션 사용을 위해 유료 엔터프라이즈 구독 을 취득해야 함을 의미 합니다.

  • 실제로 Mule ESB Community Edition은 CPAL 라이선스에 따라 배포됩니다 . 즉, 여전히이 버전을 사용하기로 결정한 경우 Mule은 다음을 요구 합니다 .

    • 실행 파일 및 소스 코드 또는 더 큰 저작물이 시작되거나 처음 실행될 때마다 최종 사용자가 해당 코드에 액세스하기 위해 사용하는 그래픽 사용자 인터페이스에 Mulesoft의 저작자 표시 정보가 눈에 잘 띄게 표시되어야합니다 (스플래시 화면 표시가 포함될 수 있음). ), 만약에 어떠한. => 기본적으로 Mule로 빌드 한 모든 것이 Mule에서 실행되고 있음 을 광고 해야합니다 .

    • Mule ESB 배포가 네트워크를 통해 액세스되는 경우 (통합 플랫폼이므로 항상 그렇습니다!) 배포 소스를 액세스하는 모든 사람이 사용할 수 있도록해야합니다.

  • 위에서 언급 한 다른 누군가와 마찬가지로 Apache Camel은 완전히 개방 된 프로젝트이며 커뮤니티를 위해 커뮤니티가 주도 합니다 . 모든 소스 코드는 공개적으로 사용 가능하며 모든 사람이 풀 요청을 보내고 구성 요소를 제공하고 포럼에서 도움을 받거나 문의 할 수 있습니다. 반대로 Mule 커뮤니티는 게이트 커뮤니티 입니다.

  • 마지막으로 중요합니다. 아마도 가장 중요한 부분 일 것입니다. 다음은 Mule ESB 대 Apache Camel에 대해 Google Trends가 말하는 내용 입니다. 표준 쿼리 키워드 보다 정확도를 높이기 위해 새로운 의미 론적 주제 측정을 사용하고 있습니다 . 그런 식으로 우리는 동물 (뮬 대 낙타)의 인기가 아니라 소프트웨어의 인기를 측정합니다! 해석 : Mule은 2007 년부터 2011 년까지 크게 하락한 반면 Apache Camel은 상승했습니다. 2011 년 이후로 Mule은 정체 상태에 있으며 Apache Camel은 계속 건강하게 추세를 유지하고 있습니다!

Google 트렌드의 뮬 대 낙타

Apache Camel의 기술적 진화

원래 질문을했을 때 2010 년 9 월 25 일 이후 Apache Camel의 진화에 대한 몇 가지 기능적 지표를 제공하고자합니다. 이것은 그 시점의 소스 트리였습니다 .

  • 당시 Camel에는 88 개의 구성 요소가 있었지만 이제는 Facebook, Twitter, Salesforce, Apache Ignite , Apache Cassandra , AWS, Apache Kafka , MongoDB, Apache Spark 등과의 통합을 포함하여 220 개의 구성 요소가 있습니다 .
  • 수많은 기술적 개선 사항 : 비동기 라우팅 엔진, 메시지 기록, 회로 차단기 EIP, 집계, 분할, 동적 라우팅 등과 같은 EIP에 대한 많은 개선 및 개선 사항
  • 생태계는 이제로 성장했다 Hawtio를 모니터링 및 관리 fabric8 등 배포
  • 그 이후로 새로운 기능, 개선 사항, 버그 등을 포함하여 5500 개 이상의 티켓 이 해결되었습니다.
  • 그리고 훨씬 더!

최종 노트

두 제품 모두 지난 5,25 년 동안 많이 발전했습니다! 그러나 Mule ESB와 Apache Camel의 라이선스와 커뮤니티 특성의 차이로 인해 더 이상 서로 비교할 수 없다고 생각합니다.

Apache Camel은 완전 오픈 소스 ❤️이며, Mule ESB Community에서는 사용자가 Mulesoft를 지정하고 Mule을 사용하는 소프트웨어의 소스 코드를 게시하도록 요구합니다. Apache 소프트웨어 라이선스는 비즈니스 친화적 인 라이선스입니다. 귀속이나 기타 요구 사항없이 Camel을 자유롭게 사용할 수 있습니다. 맥주처럼 정말 무료 !

지난 몇 년간의 생각이 새로운 시청자들에게 도움이되기를 바랍니다! :)


면책 조항 : 저는 Apache Camel 프로젝트의 커미터이자 PMC 멤버입니다.


3
Camel과 Mule 간의 추가 키 차별화 요소 (IMHO)와 함께 Raul의 탁월한 답변에 대한 추가 의견이 포함 된 블로그 게시물을 게시했습니다.- davsclaus.com
Claus Ibsen

2
업데이트에 대해 Raul에게 감사드립니다. 먼저 Claus의 블로그를 읽고 댓글을 달고 여기에 질문을 올릴 것입니다. Apache Camel의 상용 구현을 Talend 또는 JBossFuse와 같은 런타임 또는 Mule의 Anypoint와 유사한 런타임과 비교하는 것이 더 나을 것이라고 생각하지 않습니까? 그렇지 않으면 언급했듯이 Camel은 오픈 소스이고 Mule은 돈에 관한 것이므로 이미 제품이 진화하는 방식에 영향을 미치는 차이점이 있습니다.
Souciance Eqdam Rashti

1
문제는 제품이 아니라 프로젝트를 비교하고 있다는 것입니다. 사실 Mule은 프로젝트이자 제품이기 때문에 분리가 불가능합니다. 사실, 공정한 것은 Mule과 (Apache Camel + JBoss Fuse + Talend ESB)를 비교하는 것입니다. 그러면 Camel 생태계에 대해 더 높은 메트릭을 얻을 수 있습니다! 그러나 내 데이터에 따르면 대부분의 Camel 사용자가 어쨌든 바닐라 Apache Camel 사용자이기 때문에 분석을 그렇게 추진하고 싶지 않았습니다. 이해가 되길 바랍니다.
raulk

사실입니다.하지만 내 말은 Mule을 사용하고 엔터프라이즈 에디션을 사용하는 대부분의 기업은 런타임, 개발 및 모니터링 환경 등을 제공합니다. 기본적으로 완전한 패키지이므로 JBoss 또는 Talend를 비교하는 것이 더 합리적 일 수 있습니다. 기능 비교를 통해 기능을 수행합니다. 개방성과 커뮤니티 기여는 중요하지만 통합 계층을 선택할 때 결정적인 요소는 아닙니다.
Souciance Eqdam Rashti


5

Camel은 중개 엔진이고 Mule은 경량 통합 플랫폼입니다. 차이점은 Mule이 애플리케이션, REST 및 웹 서비스 배포를위한 컨테이너를 포함하여 ESB의 모든 기능을 제공한다는 것입니다. Mule은 Camel과 같은 방식으로 내장되어 응용 프로그램 개발자가 통합 코드와 함께 응용 프로그램 코드를 내장 할 수 있습니다. 둘 다 Spring과 긴밀하게 통합됩니다.

Mule은 정당한 이유로 JBI 사용하지 않으며 이제 JBI 사양이 해체되었으므로 (원래 JBI 사양을 전달한 Oracle 소유의 워킹 그룹이 없음) JBI를 사용할 좋은 전문적 또는 기술적 이유가 없습니다.


2
낙타는 봄과 잘 작동하지만, 통합되지 않습니다 tighly 봄과 함께.
Xiao Peng-ZenUML.com

4
Camel은 JBI를 사용하지 않으며 사용한 적이 없습니다.
raulk


0

Claus, Camel FAQ에는 많은 실수가 있습니다. 당연히 우리에게 유리한 것은 없습니다. :)

  • Mule의 UMO 모델은 더 이상 Mule에 없습니다. 우리는 Mule 2에서 그 모델에서 벗어나기 시작했고 Mule 3에서 완전히 변경되었습니다. 이제 매우 간단한 메시지 프로세서 모델이 있습니다.
  • Mule은 몇 년 동안 명시적인 유형 변환을 해왔지만 이것은 Camel의 차별화 요소가 아닙니다.
  • Mule은 OSI 승인 CPAL 1.0 라이선스에 따라 라이선스가 부여됩니다 . 이것은 상업용 라이선스가 아닌 오픈 소스 라이선스입니다. 최대한 빨리 업데이트하십시오

Mule 1.x / 2.x를 기반으로 설명하도록 FAQ를 업데이트했습니다. 이것은 James가 FAQ 항목을 썼을 때였습니다.
Claus Ibsen

0

먼저 Service Mix는 Apache Camel 코드를 실행할 수있는 컨테이너와 같고 Mule ESB는 그 자체로 별도의 제품이라는 것을 이해해야합니다.

ESB 제품간에 제공 할 수있는 많은 차별화가있을 수 있습니다.

차별화를보기 전에 몇 가지 사항을 알아야합니다. 그들은

  1. 제품 개발 방법
  2. 라이선스
  3. 지원 기능
  4. 오픈 소스 여부
  5. 오픈 소스가 소스를 수정하고 사용할 수 있다면 등등.

위의 내용은 선택하기 전에 검토해야 할 가장 좋은 요소입니다. 위의 내용은 대부분의 제품 선택에 일반적이며 여기에서도 특별한주의가 필요합니다.

Secondary 제품의 차이점은 도구와 해당 도메인에 따라 다르며, 이는 귀하가 찾고있는 답변 일 가능성이 높습니다. 선택하기 전에 조사해야하는 목록을 찾으십시오.

  1. 커뮤니티 지원
  2. 제품 스택
  3. 자신의 코드 수정 측면에서 확장 성
  4. 학습 가능성 및 유용성
  5. 기업용으로 구매시 제품 지원

이것은 아마도 차이점을 선택하기 위해 스스로해야 할 연구 일 것입니다. 어떤 방식 으로든 시장에서 최고라고 말하기보다는 조직에 적합한 제품을 만드는 많은 부가가치가 있습니다.

Apache camel 또는 기타 ESB에 관해서. 만들 차이는

  1. 운송 대수
  2. Mule을 통해 다양한 DSL을 제공하는 Apache Camel은 Camel에서와 같이 다중 DSL이 없다는 것입니다.
  3. 제품 스택의 Mule에는 API 관리 및 사내 클라우드 커넥터가 포함되어 있습니다. 여기서 Apache Camel은 FUSE ESB를 고려할 때 프레임 워크이므로 JBoss Stack은 귀하의 선택을 보완 할 수있는 상당한 양의 다른 제품을 제공합니다.
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.