Choisir la bonne technologie pour le système de messagerie

Question

Je travaille sur un système de messagerie depuis deux ans maintenant, le système a été écrit par une équipe il y a longtemps et implique des e-mails et un traitement de documents. Le processus de base est:

1. Recevez un e-mail, analysez-le, enregistrez les pièces jointes à Samba Partage. Informer le processeur de messages. Nous avons une application Java robuste qui fait très bien cela.

2. Traitez le message, cela implique d'obtenir des données utilisateur à partir de LDAP, appelant des services Web de traitement de fichiers sur différentes plates-formes. Le système a une sorte de service de redémarrage qui interroge la base de données pour les messages échoués ou chronométrés dans différents états et les renvoie.

Les pièces de traitement de fichiers sont des services Web EJB qui exécutent essentiellement des utilitaires de ligne de commande. Le problème réside dans notre solution d'orchestration qui est basée sur OpendesB (presque morte maintenant), il a un tas de BPEL qui s'appelle et appelle EJBS éloignés (EJB3.0 sur Glassfish V2).

Le plus gros problème est que trop de logique se fait dans BPEL (disons, toutes les mises à jour de la base de données sont effectuées dans BPEL, il n'y a pas de couche de persistance), ils ressemblent aux spaghettis les plus horribles que j'ai jamais vus. Sans oublier qu'ils font des NetBeans que nous utilisons pour les modifier en exécution vraiment lentement, au point que certains fichiers ne sont modifiables que dans un éditeur de texte simple en tant que XML. De plus, le système a un certain nombre de bogues désagréables qui nécessiteraient un refactorisation majeure pour corriger et je suis redouté pour y penser. Ces messages sont traités manuellement par nos trucs de support, donc il n'y a presque pas d'impact client, mais j'aimerais avoir un véritable système transactionnel de toute façon.

Maintenant, pour la question elle-même. Je suis prêt à passer beaucoup de mon propre temps libre à essayer d'atteindre deux objectifs: construire un remplacement pour ESB et BPEL, apprenez de nouvelles technologies à la mode. Je voudrais garder le code dans les EJB de traitement de fichiers car ils fonctionnent très bien, même si je pense me débarrasser du savon comme interface distante. Je demande donc tout aperçu de quelle technologie (-ies) me permettrait de créer une solution de messagerie robuste qui serait:

1. Ayez une couche de persistance amicale, il n'y aura rien de vraiment complexe dans DBS, juste un message de méta-données.
2. Prenez soin d'équilibrer et d'interroger les appels pour le traitement des services Web.
3. Ne nécessiterait pas de traiter avec des tonnes de XML à différents endroits afin d'ajouter une nouvelle méthode d'interface.
4. Serait évolutif - exécuter sur un certain nombre de machines.
5. Permettrait une surveillance en temps réel, comme la visualisation des files d'attente de messages, la charge actuelle, les statuts, etc.
6. J'espère que je me permettra d'apprendre quelque chose de nouveau, ce qui signifie pas la pile J2EE. Fondamentalement, je suis ouvert à tout sauf BPEL et Opendesb.