Kiedy używać Spring Integration, a kiedy Camel?

138

Jako doświadczony użytkownik Spring zakładałem, że Spring Integration będzie najbardziej sensowny w niedawnym projekcie wymagającym pewnych funkcji przesyłania wiadomości (JMS) ( więcej szczegółów ). Po kilku dniach pracy z Spring Integration nadal wydaje się, że jest dużo narzutów związanych z konfiguracją, biorąc pod uwagę liczbę kanałów, które musisz skonfigurować, aby zapewnić komunikację żądanie-odpowiedź (nasłuchiwanie na różnych kolejkach JMS).

Dlatego szukałem podstawowych informacji, czym Camel różni się od Spring Integration, ale wygląda na to, że informacje są dość skąpe, znalazłem:

Pytanie brzmi: jakie masz doświadczenia ze stosowaniem jednego stosu nad drugim? W jakich scenariuszach poleciłbyś Camel, gdyby Spring Integration nie miał wsparcia? Gdzie widzisz zalety i wady każdego z nich? Wszelkie porady z rzeczywistych projektów są wysoko cenione.

ngeek
źródło
5
Biorąc pod uwagę absolutnie niesamowitą integrację, jaką Camel ma ze Spring, nie widzę żadnego powodu, aby nawet spojrzeć na Spring Integration. Camel wyróżnia się w każdej dziedzinie: zwięzły, intuicyjny, mocny, ... zabawny. Możesz osiągnąć tak wiele za pomocą jednej linii kodu, że czasami czuję się winny, że nie napisałem wystarczającej ilości kodu, aby uzasadnić tę funkcjonalność.
Pavel Lechev,

Odpowiedzi:

75

Wybieramy Camel zamiast Spring-Integration, ponieważ płynny interfejs API jest naprawdę fajny. W rzeczywistości używamy go w projektach Springa i używamy Springa do konfigurowania jego części. Programistyczne interfejsy API są przejrzyste i zawiera duży zestaw rozsądnych komponentów.

Zrobiliśmy strzelaninę na małą skalę iw zasadzie w tym czasie wygrał Camel. Używamy go głównie do przesyłania wewnętrznych plików danych do / od podmiotów zewnętrznych, co zwykle wymaga konwersji formatu, wysyłając je za pomocą ftp / sftp / ... lub dołączając je do wiadomości e-mail i wysyłając.

Znaleźliśmy skrócony cykl edycji-kompilacji-debugowania. Używanie groovy do eksperymentowania z konfigurowaniem tras to dodatkowe bonusy.

Spring-Integration to również świetny produkt i jestem pewien, że zaspokoiłby również nasze potrzeby.

Peter Tillemans
źródło
1
Dzięki Peter za podzielenie się swoimi uwagami, czy kiedykolwiek próbowałeś wykorzystać możliwości JMS Camela, wydaje się, że odpowiednie komponenty są również dość elastyczne i mają takie samo bogactwo jak Spring Integration? Mówiąc „strzelanina na małą skalę” masz na myśli lepsze wyniki?
ngeek
1
Shootout: była to głównie gra deweloperska. Nasze potrzeby w zakresie wydajności nie są zbyt duże. Tak, używamy wielu JMS jako podstawy. Do przesyłania wiadomości używane są zarówno ActiveMQ, jak i JBossMQ.
Peter Tillemans,
czy możesz rzucić okiem na stackoverflow.com/questions/46930494/… ?
gstackoverflow,
67

Polecam Spring Integration tylko wtedy, gdy masz już projekt Spring i musisz tylko dodać „podstawową” integrację za pomocą plików, FTP, JMS, JDBC i tak dalej.

Apache Camel ma dwie główne zalety:

  1. Obsługiwanych jest wiele, wiele innych technologii.
  2. Poza tym (dobry) XML DSL, istnieją płynne API dla Java, Groovy i Scala.

Ponieważ Apache Camel ma bardzo dobrą integrację ze Springem, użyłbym go nawet zamiast Spring Integration w większości projektów Spring.

Jeśli potrzebujesz więcej szczegółów, możesz przeczytać moje doświadczenia w moim wpisie na blogu: Spoiled for Choice: Której platformy integracji użyć - Spring Integration, Mule ESB czy Apache Camel?

Kai Wähner
źródło
31

Niedawno przeprowadziłem strzelaninę Camel vs Spring Integration, aby zintegrować Apache Kafka . Pomimo tego, że jestem zapalonym programistą Spring, niestety znalazłem swoje podejrzenia w stale rosnącym stosie projektów Spring : Wiosna jest niesamowita jako IOC-Container, która służy jako klej dla innych frameworków, ale nie zapewnia realnych alternatyw dla tych frameworków . Mogą być wyjątki od tej reguły, a mianowicie wszystko, co ma związek z MVC, skąd pochodzi Spring i gdzie wykonuje świetną robotę, ale inne próby zapewnienia nowej funkcjonalności oprócz funkcji kontenera są nieudane z trzech powodów, a przypadek użycia SI Kafka potwierdza wszyscy:

  • Wprowadzenie długotrwałego, trudnego w użyciu DSL do konfiguracji XML.
  • Strony kodu konfiguracyjnego XML, aby uzyskać połączenie przewodowe wszystkich składników platformy.
  • Brakujące zasoby zapewniające funkcjonalność na równi z dedykowanymi platformami.

A teraz wracając do wyników mojej strzelaniny: co najważniejsze jestem pod wrażeniem ogólnej koncepcji Camels dotyczącej tras między punktami końcowymi . Kafka bezproblemowo integruje się z tą koncepcją, a trzy linie konfiguracji wystarczą, aby wszystko było gotowe do pracy. Problemy napotkane podczas procesu są starannie rozwiązywane dzięki obszernej dokumentacji zespołu projektowego, a także wielu pytaniom dotyczącym Stackoverflow. Wreszcie, mamy do czynienia z kompleksową integracją z Spring, która nie pozostawia niespełnionych życzeń.

W przypadku SI wręcz przeciwnie, dokumentacja dotycząca integracji Kafki jest dość obszerna i nadal nie wyjaśnia jasno, jak zintegrować Kafkę. Integracja Kafki jest wciskana w sposób robienia rzeczy w SI, co dodaje dodatkowej złożoności. Inna dokumentacja, np. Dotycząca Stackoverflow, jest również mniej obfita i mniej pomocna niż w przypadku Camel.

Mój wniosek: szewc trzymaj się swojego zawodu - użyj Springa jako kontenera i Camela jako ramy integracji systemu.

Fritz Duchardt
źródło
3
Dzięki, Fritz, za podzielenie się swoimi doświadczeniami! Całkowicie zgadzam się z twoimi spostrzeżeniami: Camel jest bardzo czysty pod względem swoich podstawowych koncepcji, a także zapewnia ekosystem wykonalnych komponentów do wielu zadań (względnie pozwala na łatwe podłączenie, jeśli chcesz dostosować określone procedury).
ngeek
15

To naprawdę zależy od tego, co chcesz robić. Jeśli potrzebujesz czegoś rozszerzyć, aby zbudować własne rozwiązanie do obsługi wiadomości, Spring Integration ma lepszy model programowania. Jeśli potrzebujesz czegoś, co obsługuje wiele protokołów bez własnego kodu, Camel wyprzedza Spring Integration.

Strzelanina na małą skalę to bardzo dobry pomysł, po prostu upewnij się, że próbujesz robić rzeczy, które zwykle robisz w projekcie.

--disclaimer: Jestem zwolennikiem Spring Integration

iwein
źródło
9

Większość porównań Camel i SI, które widziałem, nie bierze pod uwagę następujących kwestii:

1.) Wpływ, jaki Spring Boot wywarł na produktywność programistów w integracji Spring

2.) Wpływ Spring XD na udostępnienie aplikacji Spring Integration bez kompilacji kodu - także źródła i ujścia Spring XD są po prostu adapterami kanałów Spring Integration, jeśli chcesz rozszerzyć Spring XD.

3.) Efekt Spring XD wpłynął na ujednolicenie integracji Spring, Spring Batch, Spring Data (+ Hadoop!) W jednym stosie, skutecznie wprowadzając przetwarzanie wsadowe i strumieniowe, obsługę HDFS / Apache Hadoop i wiele więcej do Spring Integration.

4.) Efekt nadchodzącej premiery Spring Integration 4.0 Java DSL https://github.com/spring-projects/spring-integration-extensions/wiki/Spring-Integration-Java-DSL-Reference

Do rozważenia,

/ Pieter (wyłączenie odpowiedzialności Pracuję w Pivotal)

PivotalPieter
źródło
3
Java DSL wymaga dużo pracy i jeszcze więcej dokumentacji, zanim zostanie uwzględniona.
cuttcards
Jest już od jakiegoś czasu wydany ... spring.io/blog/2014/11/24/…
Peter Szanto
6

Używamy Spring Integration dla naszej aplikacji i teraz rozważamy przejście do Apache Camel, ponieważ napotkaliśmy wiele problemów z frameworkiem Spring Integration. Oto kilka problemów.

  1. CachingConnectionFactory udostępniona przez Spring otwiera tysiące bezczynnych połączeń w produkcie IBM MQ i nie ma gwarancji, że te połączenia zostaną ponownie użyte. I nadal te połączenia pozostaną otwarte na zawsze, co stwarza problemy po stronie MQ. Musiałem restartować aplikację co tydzień w niższych środowiskach, aby odświeżyć połączenia. Apache Camel zapewnia również buforowanie, a połączenia wydają się zwiększać / zmniejszać w zależności od obciążenia.

  2. Spring nie zapewnia mapowania parametrów QoS. Nawet jeśli włączysz QoS, tryb dostawy i właściwości wygasania / czasu trwania zostaną utracone (mam zamiar poruszyć kwestię JIRA). Obsługuje to Apache Camel, a parametry QoS są wysyłane do aplikacji zewnętrznych i ich nie upuszcza.

W tej chwili pracuję nad problemami z obsługą wyjątków i transakcji z Apache Camel, który Spring wydawał się radzić sobie lepiej z AOP.

Selvakumar
źródło
Czy wystąpiła jakaś błędna konfiguracja, która spowodowała otwarcie bezczynnych połączeń w produkcie IBM MQ?
Harpreet Sandhu - TheRootCoder
4

Właściwie powiedziałbym, że FTP ukończył okres inkubacji. Możesz przeprowadzić proste wyszukiwanie na forach SI / JIRA, aby zobaczyć, jakie nowe funkcje zostały zaimplementowane i jakie błędy zostały naprawione. Z różnych rozmów wydaje się, że jest już pewne wykorzystanie produkcji, więc sugerowałbym, aby spojrzeć na to ponownie i oczywiście przekazać nam swoje obawy za pośrednictwem

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

Pozdrawiam Oleg

Zastrzeżenie: jestem zwolennikiem Spring Integration

Oleg Zhurakousky
źródło
4

Apache Camel to bardzo dobry framework i bardzo kompletny. Ale jeśli twoja aplikacja korzysta ze sprężyny, moja osobista rada to użycie Spring Integration.

Spring Integration to platforma reklamacji EIP dotycząca integracji w ekosystemie Spring-Source. Posiada doskonałą integrację z ekosystemem: Spring boot, Batch, XD; nawet jądro używa tej samej abstrakcji począwszy od Spring Framework 4. Część abstrakcji wiadomości została przeniesiona we frameworku, jako dowód, że podstawowa abstrakcja wiadomości w Spring Integration jest bardzo silna. Na przykład framework Spring wykorzystuje abstrakcję komunikacyjną dla Spring Web, obsługę gniazd sieciowych.

Inną dobrą rzeczą w aplikacji Spring z integracją Spring w celu korzystania z Apache Camel jest to, że dzięki integracji Spring można używać tylko jednego kontekstu aplikacji. Pamiętaj, że kontekst wielbłąda jest kontekstem wiosennym. jeśli masz szansę użyć nowej wersji Springa, proponuję użyć do konfiguracji Spring Integration Java DSL. Używam go w moich nowych projektach i jest bardziej czytelny i wyraźny. Mam nadzieję, że ta refleksja może ci pomóc w twoich ocenach.

Valerio Vaudi
źródło
1

Jednym z powodów, dla których warto używać Camel zamiast Spring Integration, jest to, że potrzebujesz bardziej funkcjonalnego zestawu EIP. Spring Integration nie zapewnia abstrakcji dla rzeczy takich jak ThreadPool.

Camel zapewnia dodatkowe konstrukcje, które upraszczają niektóre aspekty pracy z kodem współbieżnym:

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

Jeśli nie potrzebujesz tego typu rzeczy i chcesz po prostu podłączyć plik, JMS, punkty końcowe FTP itp., Po prostu użyj Spring Integration.

Jon
źródło
2
Masz abstrakcję dotyczącą samych ThreadPools w ankietach SI i wykonawcach zadań ze Spring. Jednak nic nie jest wstępnie skonfigurowane dla Ciebie OOTB w SI. Zobacz konfigurator zadań skonfigurowany tutaj: static.springsource.org/spring-integration/docs/2.1.x/reference/…
cwash
@Jon, czy możesz rzucić okiem na mój post na JMS
learner
-1

Camel działa jako oprogramowanie pośredniczące dla aplikacji, w których można modelować dane, przekształcać wartości komunikatów i choreografię komunikatów.

sudhirkondle
źródło
-3

Jeśli Twoja aktualna aplikacja jest w wersji Spring i wymaga funkcji, które są obsługiwane przez Spring Integration of EIP, Spring Integration jest najlepszą opcją, w przeciwnym razie wymaga więcej wsparcia / protokołów / formatów plików itp.

Venkata Parvatam
źródło
Camel naprawdę ma świetne wsparcie dla Springa i obejmuje wiele komponentów innych firm.
MikeHoss