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

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:

• http://java.dzone.com/articles/spring-integration-and-apache (bardzo neutralne porównanie pomiędzy wdrożeniem rzeczywistego scenariusza integracji w Spring Integration vs. Camel, od grudnia 2009)
• http://hillert.blogspot.com/2009/10/apache-camel-alternatives.html (Porównanie Camel z innymi rozwiązaniami, październik 2009)
• http://raibledesigns.com/rd/entry/taking_apache_camel_for_a (Matt Raible, październik 2008)

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.

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.

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?

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.

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

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)

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.

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

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.

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.

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.

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.