Spring Integration과 Camel을 언제 사용해야합니까?

노련한 Spring 사용자로서 Spring Integration이 일부 (JMS) 메시징 기능이 필요한 최근 프로젝트에서 가장 의미가 있다고 가정했습니다 ( 자세한 내용 ). 며칠간 Spring Integration으로 작업 한 후에도 요청 응답 (다른 JMS 큐에 나열) 통신을 설정하기 위해 구성 해야하는 채널의 양이 주어지면 여전히 많은 구성 오버 헤드처럼 느껴집니다.

따라서 Camel이 Spring Integration과 어떻게 다른지에 대한 배경 정보를 찾고 있었지만 꽤 여유가있는 정보처럼 보입니다.

• http://java.dzone.com/articles/spring-integration-and-apache (2009 년 12 월부터 Spring Integration vs. Camel에서 실제 통합 시나리오 구현 간의 매우 중립 비교)
• http://hillert.blogspot.com/2009/10/apache-camel-alternatives.html(2009 년 10 월 낙타를 다른 솔루션과 비교)
• http://raibledesigns.com/rd/entry/taking_apache_camel_for_a(2008 년 10 월 Matt Raible)

질문은 하나의 스택을 다른 스택보다 사용하면서 어떤 경험을 했습니까? Spring Integration에서 지원이 부족한 시나리오는 무엇입니까? 각각의 장단점은 어디에 있습니까? 실제 프로젝트의 조언은 높이 평가됩니다.

유창한 API가 정말 좋기 때문에 Spring-Integration보다 Camel을 선택합니다. 실제로 Spring 프로젝트에서 사용하고 Spring을 사용하여 일부를 구성합니다. 프로그래밍 API는 명확하고 현명한 구성 요소가 많이 있습니다.

우리는 소규모 총격전을했으며 기본적으로 Camel의 요구 사항을 충족했습니다. 주로 ftp / sftp / ...를 사용하여 전송하거나 이메일에 첨부하여 전송하는 형식 변환이 필요한 외부 당사자와 내부 데이터 파일을 전송하는 데 주로 사용합니다.

편집-디버그 디버그주기가 단축되었습니다. groovy를 사용하여 경로 설정을 실험하면 보너스가 추가됩니다.

Spring-Integration도 훌륭한 제품이며 우리의 요구도 충족시킬 것이라고 확신합니다.

Spring 프로젝트가 이미 있고 File, FTP, JMS, JDBC 등을 사용하여 "기본"통합을 추가해야하는 경우 Spring 통합을 권장합니다.

Apache Camel은 두 가지 주요 장점이 있습니다.

1. 더 많은 기술이 지원됩니다.
2. (좋은) XML DSL 외에도 Java, Groovy 및 Scala를위한 유창한 API가 있습니다.

Apache Camel은 Spring과 매우 잘 통합되어 있기 때문에 대부분의 Spring 프로젝트에서 Spring Integration 대신 사용할 것입니다.

더 자세한 정보가 필요하다면 내 블로그 게시물 : Spoiled for Choice : Spring Integration, Mule ESB 또는 Apache Camel 중에서 어떤 통합 프레임 워크를 사용해야합니까?

최근에 Apache Kafka 통합을 목표로 Camel vs Spring Integration 총격전을 수행했습니다 . 열렬한 Spring 개발자 임에도 불구하고 슬프게도 Spring의 계속 증가하는 Project 스택에 대한 의심이 확인되었습니다. Spring은 다른 프레임 워크의 접착제 역할을하는 IOC-Container만큼 훌륭하지만 이러한 프레임 워크 에 대한 실용적인 대안 을 제공하는 데는 실패합니다 . 여기에는 예외가있을 수 있습니다. 즉, MVC와 관련된 모든 것, Spring이 시작된 곳 및 훌륭한 일을하는 곳이지만 컨테이너 기능 위에 새로운 기능을 제공하려는 다른 시도는 세 가지 이유로 짧지 않으며 SI Kafka 사용 사례는 확인합니다 그들 모두 :

• XML 구성을 위해 오래 사용하기 어려운 DSL을 소개합니다.
• 모든 프레임 워크 구성 요소를 연결하는 xml 구성 코드 페이지
• 전용 프레임 워크와 동등한 기능을 제공 할 리소스가 없습니다.

이제 총격전 결과로 돌아갑니다. 가장 중요한 것은 엔드 포인트 사이 의 경로 에 대한 낙타의 전반적인 개념에 깊은 인상을 받았습니다 . Kafka는이 개념과 완벽하게 통합되며 3 개의 구성 라인으로 모든 것을 실행하고 실행하기에 충분합니다. 프로세스 중에 발생하는 문제 는 프로젝트 팀의 풍부한 문서 와 Stackoverflow에 대한 많은 질문으로 깔끔하게 해결됩니다 . 마지막 으로, Spring에 포괄적으로 통합되어 소원을 충족시키지 않습니다.

반대로 SI를 사용하면 Kafka 통합에 대한 문서는 상당히 강렬 하며 여전히 Kafka를 통합하는 방법을 명확하게 설명하지 못합니다. Kafka의 통합은 작업을 수행하는 SI 방식으로 압축 되어 더욱 복잡해집니다. Stackoverflow와 같은 다른 문서도 Camel보다 유용성이 적고 유용하지 않습니다.

내 결론 : cobbler는 거래에 충실합니다-Spring을 컨테이너로 사용하고 Camel을 시스템 통합 프레임 워크로 사용하십시오.

실제로 당신이하고 싶은 것에 달려 있습니다. 자체 메시징 솔루션을 구축하기 위해 무언가를 확장해야하는 경우 Spring Integration에는 더 나은 프로그래밍 모델이 있습니다. 커스텀 코드없이 많은 프로토콜을 지원하는 것이 필요하다면 Camel은 Spring Integration보다 앞서있다.

소규모 총격전을 갖는 것은 매우 좋은 생각입니다. 프로젝트에서 일반적으로 수행하는 작업을 수행하고 있는지 확인하십시오.

-면책 조항 : 저는 Spring Integration 커미터입니다.

내가 본 Camel과 SI의 대부분의 비교는 다음을 고려하지 않습니다.

1.) Spring Boot가 Spring Integration의 개발자 생산성에 미치는 영향

2.) Spring XD의 효과는 코드 컴파일없이 Spring Integration 애플리케이션을 사용할 수있게하는 데 영향을 미쳤다. Spring XD 소스 및 싱크는 Spring XD를 확장 할 때 단순히 Spring Integration 채널 어댑터이다.

3.) Spring XD의 효과는 Spring 통합, Spring Batch, Spring Data (+ Hadoop!)를 단일 스택으로 통합하여 배치 및 스트림 처리, HDFS / Apache Hadoop 지원 등을 Spring Integration에 효과적으로 가져 오는 데 영향을 미쳤습니다.

4.) 곧 출시 될 Spring Integration 4.0 Java DSL의 효과 https://github.com/spring-projects/spring-integration-extensions/wiki/Spring-Integration-Java-DSL-Reference

당신의 고려를 위해

/ Pieter (Pivotal에서 일하는 면책 조항)

우리는 애플리케이션에 Spring Integration을 사용하고 있으며 Spring Integration 프레임 워크에서 많은 문제가 발생함에 따라 Apache Camel 로의 전환을 고려하고 있습니다. 다음은 몇 가지 문제입니다.

1. Spring이 제공하는 CachingConnectionFactory는 IBM MQ에서 1000의 유휴 연결을 열고 이러한 연결이 재사용된다는 보장은 없습니다. 그리고 여전히 이러한 연결은 영원히 열려있어 MQ 측에 문제가 발생합니다. 연결을 새로 고치기 위해 낮은 환경에서 매주 응용 프로그램을 다시 시작해야했습니다. Apache Camel은 캐싱도 제공하며로드에 따라 연결이 올라가거나 내려가는 것 같습니다.

2. Spring은 QoS 매개 변수에 대한 매퍼를 제공하지 않습니다. QoS를 활성화하더라도 배달 모드 및 만료 / timetolive 속성이 손실됩니다 (JIRA 문제를 제기하겠습니다). Apache Camel은이를 처리하고 QoS 매개 변수는 업스트림 애플리케이션으로 전송되며 삭제하지 않습니다.

Spring이 AOP에서 더 잘 처리하는 것처럼 보이는 Apache Camel과의 예외 및 트랜잭션을 처리하는 문제에 대해 지금 연구하고 있습니다.

실제로 FTP가 잠복기를 졸업했다고 말할 수 있습니다. SI 포럼 / JIRA에서 간단한 검색을 수행하여 구현 된 새로운 기능과 수정 된 버그를 확인할 수 있습니다. 다양한 채터에서 이미 일부 프로덕션 사용법이있는 것 같습니다. 따라서 두 번째 모양을 제시하고 물론 귀하의 우려 사항을 통해 알려주십시오.

http://forum.springsource.org/forumdisplay.php?42-Integration
https://jira.springsource.org/browse/INT

건배 올렉

면책 조항 : 저는 Spring Integration 커미터입니다.

Apache Camel은 매우 훌륭한 프레임 워크이며 매우 완벽합니다. 그러나 애플리케이션이 스프링을 사용하는 경우 개인적으로 스프링 통합을 사용하는 것이 좋습니다.

Spring Integration은 Spring-Source 생태계의 통합 EIP 불만 프레임 워크입니다. 에코 시스템과의 탁월한 통합 성을 제공합니다 : Spring boot, Batch, XD; 코어는 스프링 프레임 워크 4부터 동일한 추상화를 사용한다. 스프링 통합의 기본 메시징 추상화가 매우 강력하다는 증거로 메시징 추상화 중 일부가 프레임 워크에서 이동되었다. 예를 들어 Spring 프레임 워크는 Spring Web, 웹 소켓 지원에 대한 메시징 추상화를 사용합니다.

Apache Camel 사용과 관련하여 Spring 통합을 사용하는 Spring 애플리케이션의 또 다른 좋은 점은 Spring 통합에서는 하나의 애플리케이션 컨텍스트 만 사용할 수 있다는 것입니다. 낙타 컨텍스트는 스프링 컨텍스트입니다. 새로운 Spring 버전을 사용할 기회가 있다면 Spring Integration Java DSL을 사용하여 구성하는 것이 좋습니다. 나는 새 프로젝트에서 사용하며 더 읽기 쉽고 명확합니다. 이 성찰이 귀하의 평가에 도움이되기를 바랍니다.

Camel over Spring Integration을 사용하는 한 가지 이유는보다 기능적인 EIP 세트가 필요할 때입니다. Spring Integration은 ThreadPool과 같은 것들에 대한 추상화를 제공하지 않습니다.

Camel은 동시 코드 작업의 일부 측면을 단순화하기위한 추가 구성을 제공합니다.

http://camel.apache.org/camel-23-threadpool-configuration.html

이런 종류의 것을 필요로하지 않고 파일, JMS, FTP 엔드 포인트 등을 연결하려면 Spring Integration을 사용하십시오.

Camel은 데이터 모델링, 메시지 값 변환 및 메시지 구성을 수행 할 수있는 응용 프로그램의 미들웨어 역할을합니다.

현재 애플리케이션이 Spring에 있고 EIP의 Spring Integration에서 지원하는 기능이 필요한 경우 Spring Integration이 가장 좋은 옵션입니다. 그렇지 않으면 더 많은 타사 지원 / 프로토콜 / 파일 형식 등이 필요합니다