Hey,
Apache Camel이 있다면 Apache ServiceMix 및 Mule과 같은 다른 솔루션을 사용해야하는 이유는 무엇입니까?
Apache Camel이이 제품과 비교할 때 할 수없는 것이 있습니까?
Mule / ServiceMix는 언제 사용하고 Camel은 언제 사용합니까?
답변:
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과 같은 폐쇄 된 커뮤니티보다 더 광범위하고 포괄적이며 궁극적으로 경쟁적인 커뮤니티입니다.
에드 오스트
지금은 2016 년이고 처음 질문을받은 이후 많은 변화가 있었기 때문에 새로운 시청자를 위해 다시 방문하고 싶습니다.
Apache Camel 은 그 뿌리에 충실 했으며 헤비급 또는 완전한 런타임 플랫폼으로 발전하지 않았습니다. 다용도 및 모듈 식이며 다음을 실행할 수 있습니다.
Apache Camel은 제가 OpenHub 에서 추출한이 지점 아래의 그래프로 묘사 된 것처럼 매월 지속적으로 발전하고 견인력과 활동을 얻었습니다 . 사용자 기반도 계속 증가하고 있습니다.
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은 계속 건강하게 추세를 유지하고 있습니다!
원래 질문을했을 때 2010 년 9 월 25 일 이후 Apache Camel의 진화에 대한 몇 가지 기능적 지표를 제공하고자합니다. 이것은 그 시점의 소스 트리였습니다 .
두 제품 모두 지난 5,25 년 동안 많이 발전했습니다! 그러나 Mule ESB와 Apache Camel의 라이선스와 커뮤니티 특성의 차이로 인해 더 이상 서로 비교할 수 없다고 생각합니다.
Apache Camel은 완전 오픈 소스 ❤️이며, Mule ESB Community에서는 사용자가 Mulesoft를 지정하고 Mule을 사용하는 소프트웨어의 소스 코드를 게시하도록 요구합니다. Apache 소프트웨어 라이선스는 비즈니스 친화적 인 라이선스입니다. 귀속이나 기타 요구 사항없이 Camel을 자유롭게 사용할 수 있습니다. 맥주처럼 정말 무료 !
지난 몇 년간의 생각이 새로운 시청자들에게 도움이되기를 바랍니다! :)
면책 조항 : 저는 Apache Camel 프로젝트의 커미터이자 PMC 멤버입니다.
내 블로그 게시물은 다음 질문에 정확히 대답합니다. http://www.kai-waehner.de/blog/2011/06/02/when-to-use-apache-camel/ => Apache Camel은 경량 통합 프레임 워크 인 ServiceMix 및 전체 ESB도 마찬가지입니다.
Camel은 중개 엔진이고 Mule은 경량 통합 플랫폼입니다. 차이점은 Mule이 애플리케이션, REST 및 웹 서비스 배포를위한 컨테이너를 포함하여 ESB의 모든 기능을 제공한다는 것입니다. Mule은 Camel과 같은 방식으로 내장되어 응용 프로그램 개발자가 통합 코드와 함께 응용 프로그램 코드를 내장 할 수 있습니다. 둘 다 Spring과 긴밀하게 통합됩니다.
Mule은 정당한 이유로 JBI 를 사용하지 않으며 이제 JBI 사양이 해체되었으므로 (원래 JBI 사양을 전달한 Oracle 소유의 워킹 그룹이 없음) JBI를 사용할 좋은 전문적 또는 기술적 이유가 없습니다.
Apache Camel에는 http://camel.apache.org/faq 에 대한 일부 정보를 제공하는 FAQ 항목이 있습니다 .
Apache Camel http://camel.apache.org/articles.html 의 링크 모음
커뮤니티의 사람들이 이야기하고 Camel을 다른 프로젝트와 비교할 수있는 링크가 있습니다.
Claus, Camel FAQ에는 많은 실수가 있습니다. 당연히 우리에게 유리한 것은 없습니다. :)
먼저 Service Mix는 Apache Camel 코드를 실행할 수있는 컨테이너와 같고 Mule ESB는 그 자체로 별도의 제품이라는 것을 이해해야합니다.
ESB 제품간에 제공 할 수있는 많은 차별화가있을 수 있습니다.
차별화를보기 전에 몇 가지 사항을 알아야합니다. 그들은
위의 내용은 선택하기 전에 검토해야 할 가장 좋은 요소입니다. 위의 내용은 대부분의 제품 선택에 일반적이며 여기에서도 특별한주의가 필요합니다.
Secondary 제품의 차이점은 도구와 해당 도메인에 따라 다르며, 이는 귀하가 찾고있는 답변 일 가능성이 높습니다. 선택하기 전에 조사해야하는 목록을 찾으십시오.
이것은 아마도 차이점을 선택하기 위해 스스로해야 할 연구 일 것입니다. 어떤 방식 으로든 시장에서 최고라고 말하기보다는 조직에 적합한 제품을 만드는 많은 부가가치가 있습니다.
Apache camel 또는 기타 ESB에 관해서. 만들 차이는