Alternatywa do Camel-a w 2022

0

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.

3

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.

1

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.

1

@pawlo135:

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.

3

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

0

Ja wcześniej używalem Spring Integration.
Paradoksalnie dla mnie xml był bardziej czytelny.
To jest własnie implemetacja wzorców Integracyjnych.
Natomaist nie spotkałem się camelem nigdy, więc trudno mi powidzieć co jest lepsze

2

Camela używałem i miło go wspominam
Spring integration spotkałem w projekcie i wręcz przeciwnie.
Spójrz na Alpakke (podobny do Camela ale mniej "string driven")

2

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

1

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.

1 użytkowników online, w tym zalogowanych: 0, gości: 1