Wann sollte Spring Integration vs. Camel verwendet werden?

Als erfahrener Spring-Benutzer ging ich davon aus, dass die Spring-Integration in einem kürzlich durchgeführten Projekt, das einige (JMS-) Messaging-Funktionen erfordert, am sinnvollsten wäre (mehr Details). Nach einigen Tagen der Arbeit mit Spring Integration fühlt es sich immer noch wie ein großer Konfigurationsaufwand an, wenn man bedenkt, wie viele Kanäle Sie konfigurieren müssen, um eine Anfrage-Antwort-Kommunikation (Abhören verschiedener JMS-Warteschlangen) zu ermöglichen.

Daher habe ich nach Hintergrundinformationen gesucht, wie sich Camel von Spring Integration unterscheidet, aber es scheint, als wären Informationen da draußen ziemlich spärlich, ich habe gefunden:

• http://java.dzone.com/articles/spring-integration-and-apache (Sehr neutraler Vergleich zwischen der Implementierung eines realen Integrationsszenarios in Spring Integration vs. Camel, Stand Dezember 2009)
• http://hillert.blogspot.com/2009/10/apache-camel-alternatives.html (Comparing Camel with other solutions, Oktober 2009)
• http://raibledesigns.com/rd/entry/taking_apache_camel_for_a (Matt Raible, Oktober 2008)

Frage ist: Welche Erfahrungen haben Sie mit der Verwendung des einen Stapels über dem anderen gemacht? In welchen Szenarien würden Sie Camel empfehlen, wenn Spring Integration keine Unterstützung bietet? Wo sehen Sie jeweils Vor- und Nachteile? Alle Ratschläge aus realen Projekten werden sehr geschätzt.

Wir wählen Camel gegenüber der Spring-Integration, weil die fließende API wirklich nett ist. Wir verwenden es tatsächlich in Spring-Projekten und verwenden Spring, um einen Teil davon zu konfigurieren. Die Programmier-APIs sind übersichtlich und es gibt eine große Menge sinnvoller Komponenten.

Wir haben ein kleines Shootout gemacht und im Grunde genommen hat Camel damals für unsere Anforderung gewonnen. Wir verwenden es hauptsächlich, um interne Datendateien zu/von externen Parteien zu übertragen, was normalerweise eine Formatkonvertierung erfordert, indem wir es mit ftp/sftp/… senden oder es an eine E-Mail anhängen und versenden.

Wir fanden den Edit-Compile-Debug-Zyklus verkürzt. Die Verwendung von Groovy zum Experimentieren mit dem Einrichten von Routen ist ein zusätzlicher Bonus.

Spring-Integration ist auch ein großartiges Produkt, und ich bin mir ziemlich sicher, dass es auch unsere Anforderungen erfüllen würde.

Ich empfehle die Spring-Integration nur, wenn Sie bereits ein Spring-Projekt haben und nur eine “grundlegende” Integration mit Datei, FTP, JMS, JDBC usw. hinzufügen müssen.

Apache Camel hat zwei Hauptvorteile:

1. Viele, viele weitere Technologien werden unterstützt.
2. Neben einer (guten) XML-DSL gibt es flüssige APIs für Java, Groovy und Scala.

Da Apache Camel eine sehr gute Integration mit Spring hat, würde ich es in den meisten Spring-Projekten sogar anstelle von Spring Integration verwenden.

Wenn Sie mehr Details benötigen, können Sie meine Erfahrungen in meinem Blogbeitrag lesen: Die Qual der Wahl: Welches Integration Framework soll es sein – Spring Integration, Mule ESB oder Apache Camel?

Ich habe kürzlich ein Camel vs Spring Integration Shootout mit dem Ziel der Integration durchgeführt Apache Kafka. Obwohl ich ein begeisterter Spring-Entwickler bin, fand ich leider meinen Verdacht mit Springs ständig wachsendem Project-Stack bestätigt: Spring ist großartig als IOC-Container, um als Kleber für andere Frameworks zu dienen, aber es scheitert daran, brauchbare Alternativen zu bieten zu diese Rahmen. Es mag Ausnahmen davon geben, nämlich alles, was mit MVC zu tun hat, wo Spring herkommt und wo es großartige Arbeit leistet, aber andere Versuche, neue Funktionen zusätzlich zu den Containerfunktionen bereitzustellen, greifen zu kurz drei Gründe und die Anwendungsfall von SI Kafka bestätigt alle:

• Einführung eines umständlichen, schwer zu bedienenden DSL zur XML-Konfiguration.
• Seiten mit XML-Konfigurationscode, um alle Framework-Komponenten zu vernetzen.
• Fehlende Ressourcen, um Funktionen auf Augenhöhe mit dedizierten Frameworks bereitzustellen.

Nun zurück zu den Ergebnissen meines Shoot-Outs: Am wichtigsten ist, dass ich vom Gesamtkonzept von Camels beeindruckt bin Routen zwischen Endpunkten. Kafka fügt sich nahtlos in dieses Konzept ein und drei Konfigurationslinien reichen aus, um alles zum Laufen zu bringen. Probleme, die während des Prozesses auftreten, werden von ordentlich angegangen umfangreiche Dokumentation des Projektteams sowie viele Fragen zu Stackoverflow. Nicht zuletzt gibt es eine umfassende Integration in Spring das keine Wünsche offen lässt.

Bei SI hingegen ist die Dokumentation für die Kafka-Integration ziemlich intensiv und erklärt immer noch nicht klar, wie man Kafka integriert. Die Integration von Kafka ist gedrückt in die SI-Art, Dinge zu tun, was zusätzliche Komplexität hinzufügt. Andere Dokumentation, zB zu Stackoverflow, ist ebenfalls weniger zahlreich und weniger hilfreich als für Camel.

Mein Fazit: Schuster bleib bei deinem Handwerk – nutze Spring als Container und Camel als Systemintegrations-Framework.

Es hängt wirklich davon ab, was Sie tun möchten. Wenn Sie etwas erweitern müssen, um Ihre eigene Messaging-Lösung zu erstellen, hat Spring Integration das bessere Programmiermodell. Wenn Sie etwas benötigen, das viele Protokolle ohne benutzerdefinierten Code unterstützt, ist Camel der Spring-Integration voraus.

Eine kleine Schießerei ist eine sehr gute Idee, stellen Sie nur sicher, dass Sie versuchen, die Art von Dingen zu tun, die Sie normalerweise in dem Projekt tun würden.

–Disclaimer: Ich bin ein Spring Integration Committer

Die meisten Vergleiche von Camel und SI, die ich gesehen habe, berücksichtigen Folgendes nicht:

1.) Die Auswirkung von Spring Boot auf die Entwicklerproduktivität für Spring Integration

2.) Der Effekt von Spring XD hat dazu geführt, dass Spring Integration-Anwendungen ohne Codekompilierung verfügbar gemacht wurden – auch Spring XD-Quellen und -Senken sind einfach Spring Integration-Kanaladapter, wenn Sie Spring XD erweitern möchten.

3.) Der Effekt von Spring XD hat zur Vereinheitlichung von Spring Integration, Spring Batch, Spring Data (+Hadoop!) in einem Stack geführt, wodurch Batch- und Stream-Verarbeitung, HDFS/Apache Hadoop-Unterstützung und vieles mehr effektiv in Spring Integration integriert wurden.

4.) Der Effekt der bald erscheinenden Spring Integration 4.0 Java DSL https://github.com/spring-projects/spring-integration-extensions/wiki/Spring-Integration-Java-DSL-Reference

Für Ihre Überlegung,

/Pieter (Haftungsausschluss Ich arbeite bei Pivotal)

Wir verwenden Spring Integration für unsere Anwendung und erwägen nun, auf Apache Camel umzusteigen, da wir auf viele Probleme mit dem Spring Integration-Framework gestoßen sind. Hier sind einige Probleme.

1. Die CachingConnectionFactory, die Spring bereitstellt, öffnet Tausende von Leerlaufverbindungen in IBM MQ, und es gibt keine Garantie dafür, dass diese Verbindungen wiederverwendet werden. Und dennoch bleiben diese Verbindungen für immer offen, was auf der MQ-Seite zu Problemen führt. Musste die Anwendung in niedrigeren Umgebungen jede Woche neu starten, nur um die Verbindungen zu aktualisieren. Apache Camel bietet auch Caching und die Verbindungen scheinen je nach Auslastung nach oben/unten zu gehen.

2. Spring bietet keine Mapper für QoS-Parameter. Selbst wenn Sie QoS aktivieren, gehen der Übermittlungsmodus und die Ablauf-/Timetolive-Eigenschaften verloren (ich werde dafür ein JIRA-Problem aufwerfen). Apache Camel handhabt dies und QoS-Parameter werden an Upstream-Anwendungen gesendet und nicht gelöscht.

Ich arbeite gerade an Problemen mit der Behandlung der Ausnahmen und Transaktionen mit Apache Camel, die Spring mit AOP besser zu handhaben schien.

Apache Camel ist ein sehr gutes Framework und auch sehr vollständig. Aber wenn Ihre Anwendung Spring verwendet, ist mein persönlicher Rat, Spring Integration zu verwenden.

Spring Integration ist das Integrations-EIP-Beschwerde-Framework des Spring-Source-Ökosystems. Es hat eine hervorragende Integration in das Ökosystem: Spring Boot, Batch, XD; Sogar der Kern verwendet ab Spring Framework 4 dieselbe Abstraktion. Einige der Messaging-Abstraktionen wurden in das Framework verschoben, um zu beweisen, dass die grundlegende Messaging-Abstraktion von Spring Integration sehr stark ist. Jetzt verwendet das Spring-Framework beispielsweise die Messaging-Abstraktion für Spring Web, Web-Socket-Unterstützung.

Eine weitere gute Sache in einer Spring-Anwendung mit Spring-Integration in Bezug auf die Verwendung von Apache Camel ist, dass Sie mit Spring-Integration nur einen Anwendungskontext verwenden können. Denken Sie daran, dass der Kamelkontext ein Frühlingskontext ist. Wenn Sie die Möglichkeit haben, eine neue Spring-Version zu verwenden, empfehle ich, Spring Integration Java DSL für die Konfiguration zu verwenden. Ich verwende es bei meinen neuen Projekten und es fühlt sich lesbarer und klarer an. Ich hoffe, dass diese Reflexion Ihnen bei Ihren Bewertungen helfen kann.