Siema,
mam stworzyć małą aplikacje typu adapter który zbiera informacje z jednego serwisu i je przetwarza i wysyła dalej i tak w kółko taka apka integracyjna, wszystko oczywiście asynchronicznie kolejki. Na początku analizy uzgodniliśmy że użyjemy Camel-a ale teraz jak zacząłem go implementować to tak trochę nie bardzo dużo problemów jest z nim jest dosyć trudny. Wiem że to jest fajne narzędzie integracyjne ale może macie jakieś fajne alternatywy, coś nowszego (słyszałem o Spring Integration) ale nie wiem czego używacie w swoich firmach. Coś na szybko polecicie.
- Rejestracja:prawie 8 lat
- Ostatnio:8 miesięcy
- Postów:39

- Rejestracja:ponad 13 lat
- Ostatnio:około 11 godzin
- Postów:1068
Spring Integration to jeszcze starsze niz Camel jest :v.
Uzywam spring integration bo jestem zaznajomiony juz z tą biblioteką i pamiętam jeszcze jak sią ją w całości w xml'u konfigurowało aczkolwiek nie jest ani specjalnie łatwiejsza ani przyjemniejsza :p
Zmieni ci się słówko route na channel więc jakiegos uzysku nie bedziesz miał xD.
- Rejestracja:ponad 4 lata
- Ostatnio:około 2 godziny
- Postów:224
Jeżeli chcesz(musisz) używać Camela to najpierw dobrze zrozum EIPs, inaczej będzie sporo niespodzianek. Camel wg. mnie to (dość skomplikowana) implementacja tych wzorców.
Biorąc pod uwagę to co napisałeś, to nie uważam, że potrzebujesz Camela.
Edit:
A i z tego co pamiętam, to sporo tam castowania, bo wszystki idzie jako Object.
- Rejestracja:około 3 lata
- Ostatnio:ponad rok
- Postów:2310
Nie żebym się wielce znał, ale mozesz sam sobie pomóc okreslajac "cieżar" tego rozwiazania, czy to ma integrowac na sposób clouda nieznaną ilość żrodeł / nieznaną ilosć konsumentów, mieć samonaprawialnosć typową dla świata mikroserwisów, odpornosc na bombardowanie itd... Również wyciskania innych funkcji, niż kolejkowanie.
W przeciwnym wypadku może sie okazać ze szukasz "zwykłego" brokera kolejki.
- Rejestracja:około 7 lat
- Ostatnio:około 6 godzin
- Postów:896
Każda aplikacja na dobrą sprawę jest integracyjna. Camela nie lubię, bo jest ciężki i dynamiczny. Dodanie tak ciężkiego frameworka (jeśli chodzi o filozofię jak i wykonanie) na pewno odbije się na utrzymywalności. Na początku napisałbym wszystko jak Bóg przykazał: logika odzielnie, obsługa protokołów odzielnie i zobaczyłbym czy obsługa protokołów jest na tyle ciężka, że warto w to iść. Zgaduję, że nie

- Rejestracja:ponad 3 lata
- Ostatnio:4 dni
- Postów:822
małą aplikacje typu adapter który zbiera informacje z jednego serwisu i je przetwarza i wysyła dalej
Zadałeś sobie trud analizy przypadków użycia dla tej aplikacji i rozrysowania wysokopoziomowej architektury? Dla mnie to brzmi jak:
- pobierz dane z A,
- zapisz na kolejkę/storage,
- pobierz z kolejki/storage i wykonaj jakąś logikę na danych (np transformacja z modelu A na B, zapis do bazy analitycznej, cokolwiek)
- (opcjonalnie) zapisz wynik na storage/kolejce
- wyślij do B
Nie wydaje mi się żeby to był use case dla jakiegokolwiek kombajnu typu Enteprise Integration Platform
- Rejestracja:ponad 12 lat
- Ostatnio:19 minut
- Postów:3586
Tak jak napisał @markone_dev - wydaje mi się, że niewielkie projekty nie idą w parze z Camelem. Powiedziałbym, że typowe rozwiązania ETL są nawet za duże dla tego rozwiązania. Jeśli macie gdzieś dostępną Kafkę to sprawdziłbym na twoim miejscu czy samo Kafka Streams nie wystarczy. Jedyny problem jaki widzę to "pobieranie danych z serwisu", pewnie trzeba by było własny SourceConnector
napisać, chociaż sprawdziłbym czy te dostępne nie spełniają twoich potrzeb.
Zarejestruj się i dołącz do największej społeczności programistów w Polsce.
Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.