Apache Camel i inne produkty ESB

Hej,
jeśli mamy Apache Camel, po co używać innych rozwiązań, takich jak Apache ServiceMix i Mule?
Czy jest coś, czego Apache Camel nie może zrobić w porównaniu z tymi produktami?
Kiedy używać Mule / ServiceMix, a kiedy Camel?

Apache Camel to biblioteka implementująca wzorce integracji przedsiębiorstwa (EIP). Chociaż może używać Springa jako struktury IOC, nie jest nawet zależny od Springa, więc jest całkowicie niezależny od platformy. To „tylko” biblioteka. Możesz więc uruchomić dowolne środowisko JVM, np. Prosty jvm, servlet, ejb, osgi. Nie wiąże się to z żadnymi korzyściami (ani kosztami narzutu) kontenera typu Mule. Moim zdaniem zapewnia wyraźniejszy podział obaw w tym obszarze.

Mule można również osadzać w różnych środowiskach, ale myślę, że Mule ma zarówno zalety, jak i wady związane z połączeniem ich biblioteki EIP z kontenerem. Kiedy wdrażasz Mule w środowisku serwletu lub ejb, czy naprawdę chcesz nosić cały ten bagaż kontenera Mule? Nie jestem ekspertem od mułów i myślę, że prawdopodobnie możesz poświęcić stosunkowo niewielką ilość wysiłku i wyczyścić część zbędnych możliwości. (Zauważ, że nie jest to zła funkcja we wszystkich przypadkach, jest po prostu zbędna, jeśli używasz osadzonego w innym kontenerze).

Apache ServiceMix to kontener OSGI, który wykorzystuje Camel do implementacji EIP jako podstawy ESB. Chociaż ServiceMix historycznie zaczynał się od swoich korzeni w JBI, odszedł od JBI i ewoluował w (IMO) ładną architekturę warstwową łączącą najlepsze w swojej klasie Apache CXF, Camel i ActiveMQ w kontenerze OSGI. Główną wartością tutaj nie jest tak naprawdę ServiceMix i jego obsługa JBI, ale podstawowy kontener OSGI standardw połączeniu ze sprawdzonymi transportami Apache, takimi jak CXF dla usług internetowych i ActiveMQ dla JMS. OSGI to dojrzały standard oferujący kontener, który rozwiązuje te same typy piekła „DLL”, które nękało firmę Microsoft przed pojawieniem się .NET. Chociaż ani .NET, ani OSGI nie rozwiązują zasadniczej złożoności podstawowego problemu, przynajmniej zapewniają środki do rozwiązania tego problemu. OSGI ma również inne zalety, ale z punktu widzenia wyboru produktu kontener oparty na standardach jest najważniejszy, a jego podstawową funkcją, której Mule (i ogólnie Java) nie zajmuje się, jest zarządzanie zależnościami.

Kilka ważnych rzeczy, na które należy zwrócić uwagę, porównując Mule ze społecznościami Apache. Mule jest jak Redhat w tym sensie, że chociaż jest to licencja typu open source, to moim zdaniem nie jest tak naprawdę otwartą społecznością. Każdy może uczestniczyć w Apache, podczas gdy MuleSoft jest właścicielem społeczności Mule i ostatecznej mapy drogowej. Po drugie, chociaż społeczność Mule jest prawdopodobnie dość aktywna, myślę, że społeczność Apache jest znacznie większa (i naturalnie, ponieważ nie jest to społeczność zamknięta). Oba podejścia mają zarówno zalety, jak i wady. Jedną pozytywną cechą podejścia Apache jest to, że istnieje wielu dostawców ESB opartych na Camel, CXF, ActiveMQ i OSGI. Na przykład Talend oferuje ESB dla tych samych podstawowych technologii bez historii ServiceMix JBI. Ma to zarówno zalety, jak i wady w społeczności Apache, ale prawdziwym celem jest podkreślenie różnicy między Apache i Mule. W społeczności Mule nie znajdziesz wielu sprzedawców. Zatem IMO i Apache ESB, takie jak Talend lub ServiceMix, to szersza i bardziej inkluzywna, a ostatecznie konkurencyjna społeczność niż zamknięta społeczność, taka jak Mule.

Ed Ost

Jest teraz 2016 rok i wiele się zmieniło od czasu, gdy zadano to pytanie, więc chciałbym je ponownie odwiedzić dla nowych widzów.

Mówiąc strategicznie

• Apache Camel pozostał wierny swoim korzeniom i nie wyewoluował do ciężkiej ani pełnoprawnej platformy uruchomieniowej. Jest wszechstronny i modułowy i może działać:

  1. Osadzony w dowolnym kontenerze Java (kontener serwletów, serwer aplikacji, Spring Boot).
  2. Samodzielny jako proces Java.
  3. W środowisku OSGi ( Apache Karaf ).

• Apache Camel nadal ewoluował i zyskiwał przyczepność i aktywność w ujęciu miesięcznym, co przedstawia wykres w tym punkcie, który wyodrębniłem z OpenHub . Baza użytkowników również rośnie.

• W 2012 roku firma Red Hat przejęła firmę FuseSource , jednego z głównych promotorów i programistów stojących za Apache Camel, ActiveMQ, ServiceMix i CXF. Kilku committerów i członków PMC jest teraz zatrudnionych przez Red Hat do pracy nad Apache Camel.

• Mule ESB oferuje dwie wersje swojego produktu : Community (bezpłatna na licencji CPAL) i Enterprise (płatna). Definiują swoją wersję społecznościową jako:

Idealny do oceny lub zastosowania przedprodukcyjnego.

=> Oznacza to, że powinieneś nabyć płatną subskrypcję Enterprise do użytku produkcyjnego.

• W rzeczywistości Mule ESB Community Edition jest rozpowszechniane na licencji CPAL . Oznacza to, że jeśli nadal zdecydujesz się korzystać z tej wersji, Mule WYMAGA TEGO :

  • Za każdym razem, gdy Wykonywalny i Kod źródłowy lub Większa Praca jest uruchamiana lub początkowo uruchamiana, w graficznym interfejsie użytkownika używanym przez użytkownika końcowego w celu uzyskania dostępu do takiego Kodu Objętego (który może obejmować wyświetlanie na ekranie powitalnym) musi pojawić się wyraźne wyświetlanie Informacji o atrybucji Mulesoft ), Jeśli w ogóle. => Zasadniczo musisz reklamować, że wszystko, co zbudowałeś w Mule, działa na Mule.

  • Jeśli dostęp do wdrożenia Mule ESB odbywa się za pośrednictwem sieci (zawsze będzie, ponieważ jest to platforma integracyjna!), Należy również udostępnić źródło wdrożenia każdemu, kto ma do niego dostęp.

• Jak ktoś inny wspomniał powyżej, Apache Camel to całkowicie otwarty projekt, prowadzony przez społeczność dla społeczności . Cały kod źródłowy jest publicznie dostępny i każdy jest zachęcany do wysyłania żądań ściągnięcia, dostarczania komponentów i pomocy lub zadawania pytań na forach. Z drugiej strony, społeczność Mule to zamknięta społeczność .

• Nie mniej ważny; być może najważniejsza część. Oto, co Google Trends ma do powiedzenia na temat Mule ESB kontra Apache Camel . Zwróć uwagę, że używam nowych tematów semantycznych pomiarów dla większej dokładności, a nie standardowych słów kluczowych zapytań . W ten sposób nie mierzymy popularności zwierząt (Mule vs Camel), ale oprogramowania! Interpretacja: Mule miał silny trend spadkowy od 2007 do 2011 roku, podczas gdy Apache Camel miał tendencję wzrostową. Od 2011 roku Mule ustabilizował się, a Apache Camel wciąż zyskuje na popularności!

Techniczna ewolucja Apache Camel

Chciałem tylko podać kilka funkcjonalnych wskaźników ewolucji Apache Camel od 25 września 2010 r., Kiedy pierwotnie zadałeś to pytanie. To było drzewo źródłowe w tamtym momencie .

• Wtedy Camel miał 88 komponentów, teraz ma 220 komponentów, w tym integracje z Facebookiem, Twitterem, Salesforce, Apache Ignite , Apache Cassandra , AWS, Apache Kafka , MongoDB, Apache Spark itp.
• Wiele, wiele ulepszeń technicznych: Async Routing Engine, Message History, Circuit Breaker EIP, wiele, wiele ulepszeń i ulepszeń EIP, takich jak agregacja, podział, routing dynamiczny itp.
• Ekosystem rozrósł się do teraz, obejmując również Hawtio do monitorowania i zarządzania, strukturę 8 do wdrażania itp.
• Od tego czasu więcej niż tego czasu rozwiązano 5500 zgłoszeń, w tym nowe funkcje, ulepszenia, błędy itp.
• I dużo dużo więcej!

Uwagi końcowe

Oba produkty bardzo się rozwinęły w ciągu ostatnich 5,25 lat! Jednak ze względu na różnice w licencjach i społeczny charakter Mule ESB i Apache Camel nie sądzę, aby były one już ze sobą porównywalne.

Apache Camel jest w pełni Open Source ❤️, podczas gdy społeczność Mule ESB wymaga od użytkowników przypisania Mulesoft i opublikowania kodu źródłowego oprogramowania korzystającego z Mule. Licencja na oprogramowanie Apache jest licencją przyjazną dla biznesu : możesz swobodnie używać Camel bez atrybucji ani żadnych innych wymagań. Naprawdę za darmo jak w piwie !

Mam nadzieję, że ta refleksja na temat ostatnich lat pomoże nowym widzom! :)

Zastrzeżenie: Jestem członkiem komisji opiniodawczej i PMC w projekcie Apache Camel.

Mój post na blogu odpowiada dokładnie na to pytanie: http://www.kai-waehner.de/blog/2011/06/02/when-to-use-apache-camel/ => Apache Camel to lekka platforma integracji, ServiceMix i tak dalej są pełne ESB.

Camel to silnik pośredniczący, a Mule to lekka platforma integracyjna. Różnica polega na tym, że Mule oferuje wszystkie możliwości ESB, w tym kontener do wdrażania aplikacji, REST i Web Services. Mule można osadzać w taki sam sposób, jak Camel, aby umożliwić programistom aplikacji osadzanie kodu aplikacji wraz z kodem integracji. Oba ściśle integrują się ze Spring.

Mule nie korzysta z JBI z ważnych powodów, a teraz, gdy specyfikacja JBI została rozwiązana (brak grupy roboczej, której właścicielem jest Oracle, która pierwotnie przekazała specyfikację JBI), nie ma dobrego zawodowego lub technicznego powodu, aby używać JBI.

Jest kilka wpisów FAQ na Apache Camel, które rzucają trochę światła na ten http://camel.apache.org/faq

Oraz zbiór linków w Apache Camel http://camel.apache.org/articles.html

Miej linki, w których ludzie ze społeczności rozmawiają i porównują Camel z innymi projektami.

Mikołaj, w Camel FAQ jest kilka błędów, nic dziwnego, żaden z nich nie jest na naszą korzyść :)

• model UMO w Mule nie jest już w Mule. Zaczynamy odchodzić od tego modelu w Mule 2 i został on całkowicie zmieniony w Mule 3. Mamy teraz bardzo prosty model Message Processor, który sprawia, że ​​Twoje oświadczenie na jego temat jest zbędne
• Mule od kilku lat ma wyraźną konwersję typów, to nie jest wyróżnikiem dla Camela
• Mule jest objęty licencją na podstawie zatwierdzonej przez OSI licencji CPAL 1.0 . To jest licencja typu open source, a nie komercyjna. Zaktualizuj to jak najszybciej

Najpierw musisz zrozumieć, że Service Mix jest jak kontener, w którym można uruchomić kod Apache Camel, a Mule ESB jest osobnym produktem

Między produktami ESB może być wiele różnic.

Powinieneś wiedzieć kilka rzeczy, zanim zajrzysz do różnicowania. Oni są

1. Jak powstają produkty
2. Jego licencjonowanie
3. Jego funkcje wsparcia
4. Open Source czy nie
5. Jeśli open source może być modyfikowane i używane i tak dalej.

Powyższe będą najlepszymi czynnikami, na które należy zwrócić uwagę przed dokonaniem wyboru. Powyższe jest ogólne dla większości produktów i również tutaj wymaga szczególnej uwagi.

Różnica w produkcie drugorzędnym będzie zależała od narzędzi i ich domeny. Jest to prawdopodobnie odpowiedź, której szukasz. Znajdź listę, którą musisz przyjrzeć się introspekcji przed dokonaniem wyboru.

1. Społeczność
2. Stos produktów
3. Rozszerzalność w zakresie modyfikowania własnego kodu
4. Umiejętność uczenia się i użyteczność
5. Wsparcie produktowe w przypadku zakupu jako przedsiębiorstwo

Prawdopodobnie jest to badanie, które musisz wykonać samodzielnie, aby wybrać różnicę. Istnieje wiele sposobów, które sprawiają, że produkt jest odpowiedni dla Twojej organizacji, a nie najlepszy na rynku.

Jeśli chodzi o wielbłąda Apache lub inną ESB. Różnica, która spowoduje to

1. Liczba transportu
2. Apache Camel zapewnia różnorodność DSL over Mule i inne są takie, że nie mają wielu DSL, jak w Camel.
3. Mule w swoim zestawie produktów zawiera zarządzanie API i wewnętrzne złącza Cloud, gdzie podobnie jak Apache Camel jest ramą, gdy brana jest pod uwagę FUSE ESB, JBoss Stack zapewnia przyzwoitą ilość innych produktów, które mogą uzupełnić Twój wybór.