Apache Camel et d'autres produits ESB

Question

Hé,
Si nous avons Apache Camel pourquoi utiliser d'autres solutions comme Apache ServiceMix et Mule?
Y at-il quelque chose Apache Camel ne peut comparer à ces produits?
Quand utiliser Mule / ServiceMix et quand utiliser Camel?

Answer 1

Apache Camel est une bibliothèque qui met en œuvre des modèles d'intégration d'entreprise (EIP). Bien qu'il peut utiliser Spring comme cadre du CIO, il est même pas dépendant de printemps, il est donc totalement indépendant de la plate-forme. Il est « juste » une bibliothèque. Ainsi, vous pouvez exécuter ne importe quel environnement JVM, par exemple simple, jvm, servlet, EJB, OSGi. Il ne met pas l'un des avantages (ou les frais généraux) d'un récipient tel Mule. Il a, à mon avis, la séparation plus propre des préoccupations dans ce domaine.

Mule peut également être intégré dans des environnements différents, mais je pense que Mule a à la fois les avantages et les inconvénients de leur couplage bibliothèque EIP à leur conteneur. Lorsque vous déployez Mule dans un servlet ou de l'environnement ejb, voulez-vous vraiment transporter tous les bagages que du conteneur Mule? Je ne suis pas un expert Mule, et je pense que vous pouvez probablement passer une quantité relativement modeste de l'effort et de nettoyer une partie de la capacité redondante. (Notez que ce n'est pas mauvaise capacité dans tous les cas, il est tout simplement inutile si vous utilisez un autre récipient incorporé à l'intérieur.)

Apache ServiceMix est un conteneur OSGI qui utilise Camel pour mettre en œuvre EIP comme base d'un ESB. Bien que ServiceMix historiquement a commencé avec ses racines dans JBI, il est éloigné de JBI et est devenu (OMI) une belle architecture en couches combinant le meilleur de la race Apache CXF, Camel et ActiveMQ dans un conteneur OSGI. La valeur principale ici est pas vraiment ServiceMix et son soutien JBI, mais le conteneur OSGI sous-jacente standard couplés aux transports Apache CXF éprouvés, tels que pour les services Web et ActiveMQ JMS pour. OSGI est une norme qui arrivent à échéance offre un conteneur qui répond aux mêmes types d'enfer « DLL » qui a sévi dans Microsoft avant l'avènement de .NET. Bien que ni .NET, ni OSGI résout la complexité essentielle du problème sous-jacent, ils permettent au moins un moyen pour y faire face. OSGI a d'autres avantages, mais d'un point de vue de la sélection des produits normes conteneur à base est primaire, et sa caractéristique essentielle que Mule (et Java en général) ne traite pas est la gestion des dépendances.

Il y a des choses importantes à noter dans la comparaison Mule avec les communautés Apache. Mule est comme Redhat dans le sens que bien qu'il soit une licence open source, il est pas vraiment à mon avis, une communauté ouverte. Tout le monde peut participer à Apache alors que MuleSoft est propriétaire de la communauté Mule et la feuille de route finale. Deuxièmement, bien que la communauté Mule est sans doute assez actif, je pense que la communauté Apache est beaucoup plus grande (et naturellement autant que ce n'est pas une communauté fermée). Les deux approches ont deux points positifs et négatifs. Un point positif à l'approche Apache est qu'il ya plusieurs fournisseurs pour son ESB basé sur Camel, CXF, ActiveMQ et OSGI. Par exemple, Talend offre un bus ESB sur les mêmes technologies de base sans l'histoire ServiceMix JBI. Cela a des points positifs et négatifs au sein de la communauté Apache, mais le vrai problème est de mettre en évidence la différence entre Apache et Mule. Vous ne trouverez pas les vendeurs multilple dans la communauté Mule. Ainsi, l'OMI un bus ESB Apache comme Talend ou ServiceMix est une communauté plus large et plus inclusive, et en fin de compte que la concurrence une communauté fermée comme Mule.

Ed Ost

Answer 2

Il est maintenant 2016 et beaucoup de choses ont changé depuis a d'abord posé la question, je voudrais revenir pour de nouveaux téléspectateurs.

Stratégiquement

• Apache Camel est resté fidèle à ses racines et n'a pas évolué pour devenir une plate-forme d'exécution des poids lourds, ni à part entière. Il est polyvalent et modulaire, et peut fonctionner:

  1. Embarqué dans tout type de conteneur Java (conteneur de servlet, serveur d'applications, Spring Boot).
  2. autonome comme un processus Java.
  3. Dans un environnement OSGi ( Apache Karaf ).

• Apache Camel a continué d'évoluer et d'acquérir une traction et une activité sur une base mensuelle, comme décrit par le graphique sous ce point que j'extrait de OpenHub . Le userbase continue également d'augmenter.

• En 2012, Red Hat acquis FuseSource , l'un des principaux promoteurs et développeurs derrière Apache Camel, ActiveMQ, CXF et ServiceMix. Plusieurs committers et membres PMC sont maintenant employés par Red Hat pour travailler sur Apache Camel.

• Mule ESB offres de leurs produits : Communauté (libre sous la licence CPAL) et l'entreprise (payant). Ils définissent leur Communauté Version comme:

  

Idéal pour évaluation ou pré-production.

=> Ce qui signifie que vous devez acquérir un Entreprise payé abonnement pour l'utilisation de la production.

• En fait, Mule ESB Community Edition est distribué sous licence CPAL . Cela signifie que si vous décidez de continuer à utiliser cette version, Mule IMPOSERAIENT :

  • Chaque fois qu'un Executable et code source ou un travail plus large est lancé ou d'abord fonctionner, un affichage en vue de l'attribution d'information de MuleSoft doit se produire sur l'interface utilisateur graphique utilisée par l'utilisateur final d'accéder à ce code couvert (qui peut inclure l'affichage sur un écran de démarrage), le cas échéant. => Fondamentalement, vous devez la publicité que ce que vous avez construit avec Mule est en cours d'exécution sur Mule.

  • Si votre déploiement de Mule ESB est accessible sur le réseau (il sera toujours, car il est une plate-forme d'intégration!), Vous devez également la source de votre déploiement disponibles à ceux qui y accèdent.

• Comme quelqu'un a mentionné ci-dessus, Apache Camel est un projet complètement ouvert et conduit par la communauté, pour la communauté . Tout le code source est public, et tout le monde est invité à envoyer des demandes de traction, et contribuer de l'aide ou des composants dans les forums Renseignez-. A l'inverse, la communauté Mule est une communauté fermée .

• Last but not least; peut-être la partie la plus importante. Voici ce que Google tendances dit au sujet de Mule Apache Camel vs ESB . Notez que j'utilise les nouvelles sémantiques Thèmes mesure pour une plus grande précision plutôt que la norme recherche des mots-clés . De cette façon, nous ne mesurons pas la popularité des animaux (Mule vs Camel), mais du logiciel! Interprétation: Mule a connu une tendance lourdementde 2007 à 2011, tandis que Apache Camel a connu une tendance vers le haut. Depuis 2011, Mule a atteint un plateau, tandis que Apache Camel maintient une tendance sainement!

évolution technique d'Apache Camel

Je voulais juste vous donner quelques paramètres fonctionnels sur l'évolution du Camel Apache depuis le 25 Septembre 2010, quand vous avez posé la question à l'origine. Ce fut l'arbre source à ce moment .

• À l'époque, Camel avait 88 composants, il a maintenant 220 composants, y compris les intégrations avec Facebook, Twitter, Salesforce, Apache Ignite , Apache Cassandra , AWS, Apache Kafka , MongoDB, Apache Spark etc.
• Beaucoup, beaucoup d'améliorations techniques. Async moteur de routage, Historique des messages, disjoncteur EIP, beaucoup de nombreuses améliorations et améliorations à PIE comme l'agrégation, de fendage, routage dynamique, etc
• L'écosystème a grandi pour désormais inclure aussi Hawtio pour le suivi et la gestion, fabric8 pour le déploiement, etc.
• Depuis plus de 5500 billets ont été résolus, y compris de nouvelles fonctionnalités, améliorations, bugs, etc.
• Et bien plus encore!

Notes finales

Les deux produits ont beaucoup évolué au cours des dernières années 5,25! Cependant, en raison de la différence de licences et la nature communautaire de Mule et Apache Camel ESB, je ne pense pas qu'ils sont comparables plus longtemps les uns aux autres.

Apache Camel est entièrement Open Source ??, tandis que Mule ESB communautaire oblige les utilisateurs à attribuer MuleSoft et de publier le code source du logiciel qui utilise Mule. Le Apache Software License est un affaires licence : vous êtes libre d'utiliser Camel sans attributions, ni aucune autre exigence. Vraiment libre comme dans la bière

L'espoir de cette réflexion sur les dernières années aide les nouveaux téléspectateurs! :)

---

Disclaimer: Je suis un livreur et membre du PMC au projet Apache Camel

.

Answer 3

Mon blog envoyer des réponses exactement cette question: http://www.kai-waehner.de/blog/2011/06/02/when-to-use-apache-camel/ => Apache Camel est un cadre d'intégration légère, ServiceMix etc. sur sont ESBs complètes.

Answer 4

Camel est un moteur de médiation tandis Mule est une plate-forme d'intégration légère. La différence est que cette Mule offre toutes les fonctionnalités d'un bus ESB, y compris un conteneur pour le déploiement d'applications, REST et Web Services. Mule peuvent être intégrées de la même manière Camel pour permettre aux développeurs d'applications à intégrer, il code d'application avec leur code d'intégration. Les deux intégrer étroitement avec le printemps.

Mule n'utilise pas JBI pour bonnes raisons et maintenant que la spécification JBI a été démantelée (aucun groupe de travail, qui appartient à Oracle qui sont passés sur la spécification JBI à l'origine) il n'y a aucune raison professionnelle ou technique à utiliser JBI.

Answer 5

Il y a quelques entrées FAQ à Apache Camel qui jettent un peu de lumière sur ce http://camel.apache.org/faq

Et la collection de liens à Apache Camel http://camel.apache.org/articles.html

Avoir des liens où les gens dans les négociations communautaires et à d'autres Camel comparent les projets.

Answer 6

Claus, il y a un certain nombre d'erreurs dans la FAQ Camel, sans surprise, aucun d'entre eux en notre faveur:)

• le modèle UMO Mule n'est plus Mule. Nous commençons en se éloignant de ce modèle dans Mule 2 et il a été complètement changé Mule 3. Nous avons maintenant un modèle très simple du processeur de message qui fait votre déclaration au sujet redondant
• Mule a eu conversion de type explicite depuis quelques années maintenant, ce n'est pas un facteur de différenciation pour Camel
• Mule est sous licence OSI a approuvé la licence CPAL 1.0 . Ceci est une licence open source et non un commercial. S'il vous plaît mettre à jour le plus tôt possible ce

Answer 7

D'abord, vous devez comprendre que le Service Mix est comme un conteneur qui peut exécuter du code Apache Camel et Mule ESB est un produit distinct par lui-même

Il pourrait y avoir beaucoup de différenciations que vous pouvez fournir entre les produits ESB.

Vous devriez savoir quelques petites choses avant de regarder dans la différenciation. Ils sont

1. Comment les produits sont développés
2. Son licence
3. Ses fonctions de support
4. Open Source ou non
5. Si open source peut être la source modifiée et utilisée etc.

Le ci-dessus sera un meilleur facteurs que vous devez examiner avant de faire une sélection. Ce qui précède est générique à la plupart de la sélection des produits et il faut une attention particulière ici.

La différence de produit secondaire sera spécifique aux outils et son domain.This est probable que la réponse que vous recherchez. Trouvez la liste que vous devez Introspect avant de faire une sélection.

1. soutien communautaire
2. pile de produit
3. Extensibilité en termes de modification de votre propre code
4. aptitude à apprendre et facilité d'utilisation
5. Support produit lorsqu'il est acheté en entreprise

Ceci est probablement une recherche que vous devez faire sur votre propre pour sélectionner la différence. Toutes les façons il y a beaucoup valeur ajoute que rendre le produit adapté à votre organisation plutôt que de dire mieux sur le marché.

Quand il vient à dos de chameau Apache ou autre ESB. La différence qui fera sont

1. Le nombre de transports
2. Apache Camel vous fournit la variété de DSL sur Mule et d'autres sont sont qu'ils ne sont pas multiples DSL comme dans Camel.
3. Mule dans sa pile de produits contient la gestion des API et dans la maison Cloud Connectors où Apache Camel est un cadre lorsque FUSE ESB est pris en compte JBoss Stack fournit une bonne quantité d'autres produits qui peuvent compléter votre sélection.