Quand utiliser un ESB? messagerie avec Email/XMPP/SMS

Question

J'apporte plus de profondeur à l'application en prenant en charge plusieurs méthodes de notification. Actuellement, s'il y a une exception sur le site ou qu'un événement se produit sur le site, un email sera envoyé à ces utilisateurs, mais je veux que ce soit plus générique. Je souhaite que les utilisateurs puissent hiérarchiser leurs méthodes de notification. S'ils veulent recevoir un message XMPP lorsqu'ils sont en ligne, ils seront avertis de cette façon. S'ils ne sont pas en ligne, ils recevront un courriel, et ainsi de suite.

Il me semble qu'un ESB serait ce que je voudrais utiliser ici, mais chaque ESB que je regarde ressemble à un poids lourd. À l'heure actuelle, je n'ai aucune intention d'envoyer/déplacer des fichiers ou le besoin de clustering/failover. J'ai joué avec Smack un peu, et ça marche bien pour ce que je veux. C'est simplement une bibliothèque client XMPP. Je suppose qu'après avoir lu ces réponses, je dois déterminer combien je gagne à partir d'Apache Camel ou d'Active MQ, etc. Le composant principal que je veux est le moteur de routage. Je peux facilement en écrire un qui priorise/commande différentes méthodes, mais je me demande s'il est plus avantageux de mordre la balle maintenant plutôt que plus tard et d'abandonner mon moteur de routage personnalisé.

Answer 1

Je pense que pour l'instant, comme je l'ai fait dans le passé avec d'autres projets, je vais déployer mon propre routeur de messages pour le moment. Ce sera un poids plus léger et j'aurai une plus grande appréciation/compréhension de la façon dont cela fonctionne.

L'infrastructure que j'utilise peut utiliser un backend JMS, mais utilise actuellement le modèle Observer/Publisher pour une seule machine JVM. J'utilise des travaux Quartz pour gérer toutes les demandes afin que le serveur ne soit pas submergé par trop de demandes. Lorsque je redimensionne d'autres serveurs, je peux utiliser une file d'attente JMS si nécessaire sans modifier ma base de code.

Walter

Answer 2

Les ESB sont très lourds. Sauf si vous avez un homme d'Accenture qui vous chuchote à l'oreille, je suggère fortement d'aller avec quelque chose d'un peu plus gérable. Quelque chose comme EventBus semble plus conforme à vos besoins, ou, si vous utilisez Spring, il dispose d'un mécanisme intégré de distribution d'événements sync/async qui fait bien le travail sur une seule JVM.

Answer 3

Les ESB sont lourds. Un des projets d'intégration devrait faire l'affaire. Apache Camel et Spring Integration viennent à l'esprit. Apache Camel a déjà intégré le support pour Email et XMPP. Spring Integration a intégré le courrier électronique, mais vous devez créer votre propre adaptateur XMPP pour l'instant, mais il semble être sur le chemin, voir Spring Integration 2.0.

Vous aurez besoin de construire une logique de routage dans l'un ou l'autre de sorte que lorsque vous envoyez un message à un utilisateur, il peut dire si l'utilisateur est en ligne et l'itinéraire approprié. Edit: Techniquement, Apache Camel et Spring Integration peuvent être considérés comme des ESB, mais ils sont clairement à l'extrémité légère de l'échelle, aucun des deux n'appliquant un mécanisme de conteneur. Plus d'informations sur whether Camel is an ESB.

Answer 4

Je recommanderais Apache Camel - son très facile à utiliser et est livré avec XMPP et mail soutien - avec beaucoup d'autres components.

Si ultérieurement vous souhaitez gérer chameau autonome, vous pouvez le déployer dans un OSGI container too.