Apache Camel und andere ESB-Produkte

Hey,
wenn wir Apache Camel haben, warum sollten wir andere Lösungen wie Apache ServiceMix und Mule verwenden?
Gibt es etwas, was Apache Camel im Vergleich zu diesen Produkten nicht kann?
Wann wird Mule / ServiceMix verwendet und wann wird Camel verwendet?

Apache Camel ist eine Bibliothek, die Enterprise Integration Patterns (EIP) implementiert. Obwohl Spring als IOC-Framework verwendet werden kann, ist es nicht einmal von Spring abhängig, sodass es vollständig plattformunabhängig ist. Es ist "nur" eine Bibliothek. Sie können es also in jeder JVM-Umgebung ausführen, z. B. einfaches JVM, Servlet, EJB, OSGI. Es bringt keinen der Vorteile (oder den Overhead) eines Containers wie Mule mit sich. Meiner Meinung nach hat dies eine sauberere Trennung der Bedenken in diesem Bereich zur Folge.

Mule kann auch in verschiedene Umgebungen eingebettet werden, aber ich denke, Mule hat sowohl die Vor- als auch die Nachteile, wenn die EIP-Bibliothek an den Container gekoppelt wird. Wenn Sie Mule in einer Servlet- oder EJB-Umgebung bereitstellen, möchten Sie wirklich das gesamte Gepäck des Mule-Containers tragen? Ich bin kein Mule-Experte, und ich denke, Sie können wahrscheinlich relativ wenig Aufwand betreiben und einige der redundanten Funktionen bereinigen. (Beachten Sie, dass dies nicht in allen Fällen eine schlechte Funktion ist. Es ist nur redundant, wenn Sie in einem anderen Container eingebettet ausführen.)

Apache ServiceMix ist ein OSGI-Container, der Camel verwendet, um EIP als Basis eines ESB zu implementieren. Obwohl ServiceMix in der Vergangenheit mit seinen Wurzeln in JBI begann, hat es sich von JBI entfernt und sich zu einer schönen Schichtarchitektur (IMO) entwickelt, die Apache CXF, Camel und ActiveMQ der Spitzenklasse in einem OSGI-Container kombiniert. Der wichtigste Wert ist hier nicht wirklich ServiceMix und seine JBI - Unterstützung, aber der zugrunde liegende OSGi - Container Standardgekoppelt mit bewährten Apache-Transporten wie CXF für Webdienste und ActiveMQ für JMS. OSGI ist ein ausgereifter Standard, der einen Container bietet, der die gleichen Arten von "DLL" -Hölle behandelt, die Microsoft vor dem Aufkommen von .NET geplagt haben. Während weder .NET noch OSGI die wesentliche Komplexität des zugrunde liegenden Problems lösen, bieten sie zumindest ein Mittel, um es anzugehen. OSGI hat auch andere Vorteile, aber aus Sicht der Produktauswahl ist der auf Standards basierende Container primär, und sein wesentliches Merkmal, das Mule (und Java im Allgemeinen) nicht ansprechen, ist das Abhängigkeitsmanagement.

Einige wichtige Dinge, die beim Vergleich von Mule mit Apache-Communities zu beachten sind. Mule ist wie Redhat in dem Sinne, dass es sich zwar um eine Open-Source-Lizenz handelt, aber meiner Meinung nach nicht wirklich eine offene Community ist. Jeder kann an Apache teilnehmen, während MuleSoft die Mule-Community und die endgültige Roadmap besitzt. Zweitens, obwohl die Mule-Community wohl ziemlich aktiv ist, denke ich, dass die Apache-Community viel größer ist (und natürlich, da es sich nicht um eine Gated-Community handelt). Beide Ansätze haben sowohl Vor- als auch Nachteile. Ein positiver Aspekt des Apache-Ansatzes ist, dass es mehrere Anbieter für ESBs gibt, die auf Camel, CXF, ActiveMQ und OSGI basieren. Zum Beispiel bietet Talend einen ESB für dieselben Kerntechnologien ohne die ServiceMix-JBI-Historie an. Dies hat sowohl Vorteile als auch Nachteile innerhalb der Apache-Community. Der eigentliche Punkt ist jedoch, den Unterschied zwischen Apache und Mule hervorzuheben. In der Mule-Community finden Sie keine zahlreichen Anbieter. IMO ist ein Apache ESB wie Talend oder ServiceMix eine breitere und umfassendere und letztendlich wettbewerbsfähigere Community als eine geschlossene Community wie Mule.

Ed Ost

Es ist jetzt 2016 und viel hat sich geändert, seit die Frage ursprünglich gestellt wurde. Deshalb möchte ich sie für neue Zuschauer erneut besuchen.

Strategisch gesehen

• Apache Camel ist seinen Wurzeln treu geblieben und hat sich weder zu einer schweren noch zu einer vollwertigen Laufzeitplattform entwickelt. Es ist vielseitig und modular und kann ausgeführt werden:

  1. Eingebettet in jede Art von Java-Container (Servlet-Container, Anwendungsserver, Spring Boot).
  2. Standalone als Java-Prozess.
  3. In einer OSGi-Umgebung ( Apache Karaf ).

• Apache Camel hat sich weiterentwickelt und gewinnt monatlich an Zugkraft und Aktivität, wie in der Grafik unter diesem Punkt dargestellt, die ich aus OpenHub extrahiert habe . Die Nutzerbasis nimmt ebenfalls weiter zu.

• Im Jahr 2012 erwarb Red Hat FuseSource , einen der Hauptförderer und Entwickler von Apache Camel, ActiveMQ, ServiceMix und CXF. Mehrere Committer und PMC-Mitglieder sind jetzt bei Red Hat beschäftigt, um an Apache Camel zu arbeiten.

• Mule ESB bietet zwei Versionen seines Produkts an : Community (kostenlos unter der CPAL-Lizenz) und Enterprise (kostenpflichtig). Sie definieren ihre Community- Version als:

Ideal für die Evaluierung oder Vorproduktion.

=> Dies bedeutet, dass Sie ein kostenpflichtiges Enterprise-Abonnement für die Produktionsnutzung erwerben sollten .

• Tatsächlich wird die Mule ESB Community Edition unter der CPAL-Lizenz vertrieben . Dies bedeutet, dass Mule, wenn Sie sich dennoch für diese Version entscheiden, Folgendes benötigt :

  • Jedes Mal, wenn ein ausführbarer Code und ein Quellcode oder ein größeres Werk gestartet oder zum ersten Mal ausgeführt werden, muss auf der grafischen Benutzeroberfläche, die der Endbenutzer für den Zugriff auf diesen abgedeckten Code verwendet (einschließlich der Anzeige auf einem Begrüßungsbildschirm), eine auffällige Anzeige der Attributionsinformationen von Mulesoft erfolgen ), wenn überhaupt. => Im Grunde müssen Sie werben , dass alles , was Sie aufgebaut haben , mit Mule auf Mule läuft.

  • Wenn auf Ihre Bereitstellung von Mule ESB über das Netzwerk zugegriffen wird (dies ist immer der Fall, da es sich um eine Integrationsplattform handelt!), Müssen Sie die Quelle Ihrer Bereitstellung auch jedem zugänglich machen, der darauf zugreift.

• Wie bereits erwähnt, ist Apache Camel ein völlig offenes Projekt, das von der Community für die Community vorangetrieben wird . Der gesamte Quellcode ist öffentlich verfügbar, und jeder wird aufgefordert, Pull-Anfragen einzusenden, Komponenten beizutragen und in den Foren zu helfen oder nachzufragen. Umgekehrt ist die Mule-Community eine Gated Community .

• Zu guter Letzt; vielleicht der wichtigste Teil. Hier ist, was Google Trends über Mule ESB vs. Apache Camel zu sagen hat . Beachten Sie, dass ich die Messung der neuen semantischen Themen für eine höhere Genauigkeit anstelle der Standardabfrage- Schlüsselwörter verwende . Auf diese Weise messen wir nicht die Beliebtheit der Tiere (Mule vs Camel), sondern der Software! Interpretation: Mule tendierte von 2007 bis 2011 stark nach unten, während Apache Camel nach oben tendierte. Seit 2011 hat Mule ein Plateau erreicht, während Apache Camel weiterhin gesund ist!

Technische Entwicklung von Apache Camel

Ich wollte Ihnen nur einige funktionale Metriken zur Entwicklung von Apache Camel seit dem 25. September 2010 geben, als Sie die Frage ursprünglich gestellt haben. Dies war der Quellbaum zu diesem Zeitpunkt .

• Damals hatte Camel 88 Komponenten, jetzt 220 Komponenten, einschließlich Integrationen mit Facebook, Twitter, Salesforce, Apache Ignite , Apache Cassandra , AWS, Apache Kafka , MongoDB, Apache Spark usw.
• Viele, viele technische Verbesserungen: Async Routing Engine, Nachrichtenverlauf, Leistungsschalter-EIP, viele, viele Verbesserungen und Verbesserungen an EIPs wie Aggregation, Aufteilung, dynamisches Routing usw.
• Das Ökosystem ist gewachsen und umfasst jetzt auch Hawtio für die Überwachung und Verwaltung, Fabric8 für die Bereitstellung usw.
• Seitdem wurden mehr als 5500 Tickets behoben, einschließlich neuer Funktionen, Verbesserungen, Fehler usw.
• Und sehr viel mehr!

Schlussbemerkungen

Beide Produkte haben sich in den letzten 5,25 Jahren stark weiterentwickelt! Aufgrund der unterschiedlichen Lizenzen und des Community-Charakters von Mule ESB und Apache Camel denke ich jedoch nicht, dass sie länger miteinander vergleichbar sind.

Apache Camel ist vollständig Open Source while, während die Mule ESB Community von Benutzern verlangt, Mulesoft zuzuweisen und den Quellcode der Software zu veröffentlichen, die Mule verwendet. Die Apache-Softwarelizenz ist eine geschäftsfreundliche Lizenz: Sie können Camel ohne Namensnennung oder andere Anforderungen verwenden. Wirklich kostenlos wie beim Bier !

Hoffe, diese Reflexion über die letzten Jahre hilft neuen Zuschauern! :) :)

Haftungsausschluss: Ich bin Committer und PMC-Mitglied beim Apache Camel-Projekt.

Mein Blog-Beitrag beantwortet genau diese Frage: http://www.kai-waehner.de/blog/2011/06/02/when-to-use-apache-camel/ => Apache Camel ist ein leichtes Integrationsframework, ServiceMix und so weiter sind volle ESBs.

Camel ist eine Vermittlungsmaschine, während Mule eine leichte Integrationsplattform ist. Der Unterschied besteht darin, dass Mule alle Funktionen eines ESB bietet, einschließlich eines Containers zum Bereitstellen von Anwendungen, REST und Web Services. Mule kann auf die gleiche Weise wie Camel eingebettet werden, damit Anwendungsentwickler dort Anwendungscode mit ihrem Integrationscode einbetten können. Beide integrieren sich eng in Spring.

Mule verwendet JBI aus guten Gründen nicht. Nachdem die JBI-Spezifikation aufgelöst wurde (keine Arbeitsgruppe von Oracle, die die JBI-Spezifikation ursprünglich weitergegeben hat), gibt es keinen guten beruflichen oder technischen Grund für die Verwendung von JBI.

Es gibt einige FAQ-Einträge bei Apache Camel, die etwas Licht auf diese http://camel.apache.org/faq werfen

Und die Link-Sammlung bei Apache Camel http://camel.apache.org/articles.html

Haben Sie einige Links, über die Leute in der Community sprechen, und vergleichen Sie Camel mit anderen Projekten.

Claus, es gibt eine Reihe von Fehlern in den Kamel-FAQ, nicht überraschend, keiner von ihnen zu unseren Gunsten :)

• Das UMO-Modell in Mule ist nicht mehr in Mule. Wir haben begonnen, uns von diesem Modell in Mule 2 zu entfernen, und es wurde in Mule 3 vollständig geändert. Wir haben jetzt ein sehr einfaches Nachrichtenprozessormodell, das Ihre Aussage darüber überflüssig macht
• Mule hat seit einigen Jahren eine explizite Typkonvertierung, dies ist kein Unterscheidungsmerkmal für Camel
• Mule ist unter der von OSI genehmigten CPAL 1.0-Lizenz lizenziert . Dies ist eine Open Source-Lizenz, keine kommerzielle. Bitte aktualisieren Sie diese so schnell wie möglich

Zunächst müssen Sie verstehen, dass Service Mix wie ein Container ist, in dem Apache Camel-Code ausgeführt werden kann, und dass Mule ESB ein eigenständiges Produkt ist

Es kann viele Unterschiede zwischen ESB-Produkten geben.

Sie sollten einige Dinge wissen, bevor Sie sich die Differenzierung ansehen. Sie sind

1. Wie die Produkte entwickelt werden
2. Seine Lizenzierung
3. Seine Unterstützungsfunktionen
4. Open Source oder nicht
5. Wenn Open Source, kann die Quelle geändert und verwendet werden und so weiter.

Die oben genannten Faktoren sind die besten Faktoren, die Sie berücksichtigen müssen, bevor Sie eine Auswahl treffen. Das Obige ist für den größten Teil der Produktauswahl allgemein und erfordert auch hier besondere Aufmerksamkeit.

Der sekundäre Produktunterschied ist spezifisch für die Tools und deren Domäne. Dies ist wahrscheinlich die Antwort, nach der Sie suchen. Suchen Sie die Liste, die Sie überprüfen müssen, bevor Sie eine Auswahl treffen.

1. Gemeinschaftliche Unterstützung
2. Produktstapel
3. Erweiterbarkeit in Bezug auf das Ändern Ihres eigenen Codes
4. Lernfähigkeit und Benutzerfreundlichkeit
5. Produktunterstützung beim Kauf als Unternehmen

Dies ist wahrscheinlich eine Recherche, die Sie selbst durchführen müssen, um den Unterschied auszuwählen. Es gibt viele Möglichkeiten, die das Produkt für Ihr Unternehmen geeignet machen, anstatt es als das Beste auf dem Markt zu bezeichnen.

Wenn es um Apache-Kamel oder andere ESB geht. Der Unterschied, der machen wird, sind

1. Die Anzahl der Transporte
2. Apache Camel bietet Ihnen die Vielfalt von DSL über Mule und andere sind, dass sie nicht mehrere DSL wie in Camel haben.
3. Mule in seinem Produktstapel enthält API-Management und interne Cloud-Konnektoren, bei denen Apache Camel ein Framework ist, wenn FUSE ESB berücksichtigt wird. JBoss Stack bietet eine angemessene Menge anderer Produkte, die Ihre Auswahl ergänzen können.