Spring Integration을 사용하는 시기와낙타?

Spring Integration을 사용하는 시기와낙타?

Spring의 경험이 풍부한 사용자로서 Spring Integration은 몇 가지(JMS) 메시징 기능(상세)을 필요로 하는 최근 프로젝트에서 가장 타당하다고 생각했습니다.Spring Integration을 사용한 지 며칠이 지나도 (다른 JMS 큐에서 리슨) 요구 응답 통신을 확립하기 위해 설정할 필요가 있는 채널의 양을 생각하면 설정 오버헤드가 큰 것처럼 느껴집니다.

그래서 카멜이 스프링 인테그레이션과 어떻게 다른지에 대한 배경 정보를 찾고 있었는데, 정보가 꽤 남아 있는 것 같습니다.

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

질문: 하나의 스택을 다른 스택으로 사용했을 때 어떤 경험을 했습니까?스프링 통합이 지원되지 않는 경우 Camel을 추천하는 시나리오는 무엇입니까?각각의 장단점은 어디에 있습니까?실제 프로젝트의 조언은 매우 감사합니다.

Spring-Integration보다 Camel을 선택한 이유는 유창한 API가 매우 좋기 때문입니다.실제로 Spring 프로젝트에서 사용하고 Spring을 사용하여 일부를 구성합니다.프로그래밍 API는 명확하고 합리적인 컴포넌트 세트가 많이 있습니다.

우리는 작은 규모의 총격전을 벌였고, 기본적으로 그 당시에 카멜이 이겼습니다.주로 내부 데이터 파일을 외부 파티 간에 전송하거나 외부 파티로부터 전송하기 위해 사용합니다.이 경우 보통 ftp/sftp/...를 사용하여 포맷 변환을 해야 합니다.또는 이메일로 첨부하여 발송합니다.

편집-컴파일-디버깅 사이클이 감소했습니다.groovy를 사용하여 경로 설정을 실험하는 것은 보너스가 붙습니다.

Spring-Integration도 훌륭한 제품이며, 당사의 요구도 충분히 충족시킬 수 있을 것이라고 확신합니다.

스프링 통합은 이미 스프링 프로젝트를 가지고 있고 파일, FTP, JMS, JDBC 등을 사용하여 "기본" 통합을 추가해야 하는 경우에만 권장합니다.

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

1. 수많은 테크놀로지가 지원되고 있습니다.
2. 게다가 (좋은) XML DSL에는 Java, Groovy, Scala를 위한 유창한 API가 있습니다.

Apache Camel은 Spring과의 통합이 매우 좋기 때문에 대부분의 Spring 프로젝트에서 Spring Integration 대신 사용합니다.

자세한 내용은 블로그 투고: Spilt for Choice:를 참조하십시오. 스프링 통합, Mull ESB 또는 Apache Camel 중 어떤 통합 프레임워크를 사용해야 합니까?

저는 최근 Apache Kafka를 통합하기 위해 카멜 vs 스프링 인테그레이션의 슛아웃을 실시했습니다.봄철의 열성 개발자인 나는 스프링의 계속 증가하는 프로젝트 스택에 대한 의심을 슬프게 느꼈다.봄은 다른 프레임워크의 접착제 역할을 하는 IOC-컨테이너로서 훌륭하지만, 이러한 프레임워크에 대한 실행 가능한 대안을 제공하는 데는 실패했다.여기에는 예외가 있을 수 있습니다. 즉, MVC와 관련된 모든 것, 즉 스프링이 유래한 곳과 MVC가 잘 작동하는 곳, 그러나 컨테이너 기능 위에 새로운 기능을 제공하려는 다른 시도는 세 가지 이유로 인해 부족하며 SI Kafka 사용 사례는 이러한 모든 것을 확인합니다.

• XML 설정에 DSL을 사용하기 어려운 장황한 기능의 도입.
• 모든 프레임워크 컴포넌트를 배선하기 위한 xml 구성 코드 페이지.
• 전용 프레임워크와 동등한 기능을 제공하기 위한 리소스가 부족합니다.

승부차기의 결과로 돌아가겠습니다.가장 중요한 것은 카멜의 엔드포인트 간 경로의 전체적인 개념에 감명받았습니다.Kafka는 이 개념과 심리스하게 통합되어 있으며 3개의 구성 라인으로 모든 것을 가동할 수 있습니다.프로세스 중에 발생하는 문제는 Stackoverflow에 대한 많은 질문뿐만 아니라 프로젝트 팀의 충분한 문서화를 통해 깔끔하게 해결됩니다.마지막으로 봄으로의 포괄적인 통합이 있어 소원을 이루지 못할 일은 없습니다.

반대로 SI에서는 카프카 통합에 대한 문서가 상당히 강렬하고 카프카 통합 방법을 명확하게 설명하지 못하고 있습니다.Kafka의 통합은 SI 방식의 작업 방식에 강요되어 복잡성이 가중됩니다.Stackoverflow와 같은 다른 문서도 Camel에 비해 풍부하지 않고 도움이 되지 않습니다.

결론: 코블러는 귀사의 사업을 고수합니다. - 스프링은 컨테이너로, 카멜은 시스템 통합 프레임워크로 사용합니다.

정말 하고 싶은 거에 달렸어요.독자적인 메시징 솔루션을 구축하기 위해 무언가를 확장해야 하는 경우 Spring Integration은 보다 나은 프로그래밍 모델을 제공합니다.커스텀 코드 없이 많은 프로토콜을 지원하는 것이 필요하다면 Camel이 Spring Integration보다 앞선다.

소규모 슛아웃을 하는 것은 매우 좋은 아이디어입니다.프로젝트에서는 통상적으로 할 수 있는 일을 하고 있는 것을 확인해 주세요.

--실행자:저는 스프링 통합 커미셔너입니다.

지금까지 본 Camel과 SI의 대부분의 비교에서는 다음 사항이 고려되지 않습니다.

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

2) Spring XD의 효과는 코드 컴파일 없이 스프링 통합 애플리케이션을 사용할 수 있게 하는 데 있습니다.또한 스프링 XD의 소스와 싱크도 스프링 통합 채널 어댑터입니다.스프링 XD의 연장을 검토하고 있는 경우에는 스프링 통합 채널 어댑터입니다.

3. Spring XD의 효과는 Spring Integration, Spring Batch, Spring Data(+Hadoop!)를 하나의 스택으로 통합하여 배치 및 스트림 처리, HDFS/Apache Hadoop 지원 등을 효과적으로 스프링 통합에 가져다 줍니다.

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

참고하시기 바랍니다.

/피터(Pivotal에서 일하는 해고자)

어플리케이션에 Spring Integration을 사용하고 있으며 Spring Integration 프레임워크에서 많은 문제가 발생했기 때문에 Apache Camel로의 이행을 검토하고 있습니다.여기 몇 가지 문제가 있습니다.

1. Spring이 제공하는 CachingConnectionFactory는 IBM MQ에서 1000개의 유휴 연결을 열며 이러한 연결이 재사용된다는 보장은 없습니다.이러한 접속은 계속 열려 있기 때문에 MQ측에서 문제가 발생합니다.접속을 갱신하기 위해서, 저환경에서는 매주 애플리케이션을 재기동할 필요가 있었습니다.Apache Camel은 캐싱도 제공하며 부하에 따라 연결이 올라가거나 내려가는 것처럼 보입니다.

2. 스프링은 QoS 파라미터의 맵퍼를 제공하지 않습니다.QoS를 유효하게 해도, 전달 모드와 유효기간/시간 계측의 속성이 없어집니다(이것에 대해 JIRA의 문제를 제기합니다).Apache Camel은 이를 처리하며 QoS 파라미터는 업스트림애플리케이션으로 전송되며 폐기되지 않습니다.

저는 지금 Apache Camel과의 예외 처리 및 AOP로 Spring이 더 잘 처리할 것 같았던 거래에 대해 연구하고 있습니다.

Apache Camel은 매우 좋은 프레임워크이며 매우 완벽합니다.하지만 만약 당신의 어플리케이션이 스프링을 사용한다면, 제 개인적인 조언은 스프링 인테그레이션을 사용하는 것입니다.

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

Apache Camel을 사용하기 위한 Spring 연동 어플리케이션의 또 다른 장점은 Spring 연동 어플리케이션 컨텍스트를 하나만 사용할 수 있다는 것입니다.Camel Context는 Spring Context입니다.만약 당신이 새로운 스프링 버전을 사용할 기회가 있다면, 나는 설정에 Spring Integration Java DSL을 사용할 것을 제안합니다.새 프로젝트에 사용하고 있는데 더 읽기 쉽고 선명하게 느껴져요.이 반성이 당신의 평가에 도움이 되기를 바랍니다.

사실 FTP는 잠복기가 지났다고 생각합니다.SI 포럼/J에서 간단한 검색을 할 수 있습니다.IRA를 통해 구현된 새로운 기능과 수정된 버그를 확인할 수 있습니다.여러 가지 채팅으로 보아 이미 어느 정도의 생산 용도가 있는 것 같기 때문에 다시 한 번 살펴보고 물론 다음 방법으로 고객님의 우려를 전달해 주시기 바랍니다.

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

치어스 올레그

면책사항:저는 스프링 통합 커미티터입니다.

Camel over Spring Integration을 사용하는 이유 중 하나는 보다 기능적인 EIP 세트가 필요한 경우입니다.Spring Integration은 Thread Pool 등의 추상화를 제공하지 않습니다.

Camel은 이를 위한 추가 구성 요소를 제공하여 동시 코드로 작업하는 일부 측면을 단순화합니다.

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

파일, JMS, FTP 엔드포인트 등을 접속하는 것만으로, 이러한 것이 필요 없는 경우는, 다음과 같습니다.스프링 인테그레이션을 사용하면 됩니다.

Camel은 데이터 모델링, 메시지 값 변환 및 메시지 안무를 수행할 수 있는 애플리케이션용 미들웨어 역할을 합니다.

현재 사용 중인 애플리케이션이 봄에 EIP의 Spring Integration에서 지원되는 기능을 필요로 하는 경우 Spring Integration이 가장 좋은 옵션입니다.그렇지 않으면 서드파티 지원/프로토콜/파일 형식 등이 더 필요합니다.

언급URL : https://stackoverflow.com/questions/3034054/when-to-use-spring-integration-vs-camel