Apache Camel peut-il s'intégrer à une application de traitement de travaux propriétaire?

Question

Dans le projet actuel, nous devons effectuer des calculs assez compliqués sur les données exportées de notre système. Les calculs sont gérés par un logiciel tiers (qui est essentiellement une boîte noire pour nous). Nous avons ce logiciel en tant que binaires Linux ou Windows, et nous savons comment l'exécuter avec nos données dans la ligne de commande.

Le traitement d'un seul ensemble de données sur un cœur de processeur dure environ 200 heures. Cependant, nous pouvons diviser l'ensemble de données en ensemble de données plus petit (structurellement équivalent) et exécuter des calculs en parallèle. Plus tard, nous pouvons facilement agréger les résultats. Notre but est de pouvoir traiter chaque ensemble de données de moins de 10 heures.

Notre client dispose d'une application propriétaire de traitement des travaux. L'interface est basée sur le système de fichiers: nous copions le fichier EXE du travail (yep, c'est Windows) et le fichier INI de configuration dans le dossier entrant, l'application de traitement des travaux exécute ce travail sur l'un des nœuds (gestion des erreurs, basculement, etc. .) et enfin copie les résultats dans le dossier sortant. Ce système de traitement de travaux propriétaire a plusieurs centaines de cœurs de processeur, il y a donc assez de puissance pour gérer notre ensemble de données de moins de 10 heures. Même moins de 30 minutes.

Maintenant, la chose est, notre application est basée sur J2EE, plus ou moins l'application JBoss standard. Et nous devons:

• intègrent à un système de traitement de file d'attente travail comme propriétaire et
• split/agréger nos ensembles de données de manière fiable.

Pour moi, beaucoup de choses que nous devons faire ressemblent beaucoup à Enterprise Application Intergation Patterns comme Splitter et Aggregator. Donc, je pensais si Apache Camel serait un bon moyen pour la mise en œuvre:

• Nous allons construire nos emplois (+ EXE + INI) jeu de données sous forme de messages. Un séparateur diviserait les messages de travaux importants en plus petits en divisant l'ensemble de données en plusieurs jeux de données plus petits.
• Nous aurons probablement besoin de mettre en œuvre nos propres canaux de messagerie pour écrire des messages dans le répertoire entrant ou lire des messages à partir du répertoire sortant du système de traitement de travaux propriétaire.
• Nous aurons besoin d'un agrégateur pour agréger les résultats des tâches en un seul résultat d'un travail.

Cependant, je n'ai pas encore d'expérience avec Apache Camel et j'ai donc décidé de demander conseil sur l'applicabilité.

Étant donné le problème décrit ci-dessus, pensez-vous que Apache Camel serait un bon choix pour cette tâche?

Note de clôture: Je ne recherche pas de ressources externes ou une suggestion d'outil/bibliothèque. Juste une confirmation (ou le contraire), si je suis sur la bonne voie avec Apache Camel.

Answer 1

Vous avez un cas d'utilisation assez compliqué là-bas. Permettez-moi de reformuler ce que vous aimeriez faire dans un format simple et de fournir mes pensées. Si vous voyez que j'ai raté quelque chose, laissez-moi un commentaire et je vais réviser mon message. JBoss basée sur l'application J2EE qui a un grand ensemble de données qui doit être transformé en deux parties, puis transformé en un format personnalisé.Ce format sera ensuite écrit sur le disque et traité par une autre application qui créera de nouveaux résultats de données dans un dossier de sortie sur le disque. Vous voulez ensuite récupérer cette sortie et agréger les résultats. Je dirais qu'apache camel peut le faire, mais vous devrez prendre le temps d'ajuster le système à vos besoins et de configurer quelques configurations personnalisées sur vos composants. J'imagine que ce processus cherche quelque chose comme:

from("my initial data source") 
    .split().method(CustomBean.class, "customSplitMethod") 
     //You might want some sort of round robin pattern to 
     //distribute between the different directories 
     .to("file://customProgramInputDirectory"); 

from("file://customProgramOutputDirectory") 
    .aggregate(constant(true), new MyCustomAggregationStratedgy()) 
    .to("output of your data source"); 

Puisque vous avez dit que vous intégrerons avec un « système de traitement du travail de file d'attente comme propriétaire », je pourrais avoir mal compris l'entrée et la sortie de l'autre programme pour être fileDirectories, s'il s'agit d'un système basé sur une file d'attente et qu'il supporte jms il existe un modèle générique que vous pouvez utiliser, sinon il est toujours possible de créer un composant personnalisé camel afin que votre modèle passe simplement de 'file: //' à 'MyCustomEndpoint:// '

Answer 2

La réponse est NON - Camel n'est pas le meilleur cadre pour le faire même s'il peut être trop long pour imiter ce que vous décrivez.

Apache Camel effectue un fractionnement à l'arrivée de l'unité de travail identifiée comme Exchange qui peut bien sûr être un fichier (en utilisant le composant camel-file). MAIS, lors de la division, chaque "morceau" est ensuite envoyé à un Processor dédié.

Le problème est que le bloc est un Exchange lui-même et destiné à être mis en mémoire (pour pouvoir effectuer des tâches en parallèle plus tard). Dans votre cas, je suppose que la partie des données est encore trop importante pour être traitée en mémoire. Si ce n'est pas le cas, Camel répond à vos besoins et effectue même tous les sondages requis pour s'intégrer au système que vous avez décrit.

Vous demandez de ne rien proposer, mais si j'étais vous je donnerais un essai sur Spring Batch à la place.

Answer 3

Je pense que Apache Camel est adapté à vos besoins, car c'est l'un des meilleurs frameworks d'intégration que j'ai trouvé jusqu'à présent.

Mon projet actuel consiste à traiter avec ECM, ayant à traiter une énorme quantité de documents pouvant atteindre le nombre de 1 million/jour.

En entrée, nous avons des fichiers XML représentant un groupe de documents (ou un lot de documents) ainsi que des liens vers des fichiers réels stockés sur un NAS. Tout d'abord, nous avons dû transformer tous ces fichiers XML dans un format XML propriétaire qui convient à l'importateur de documents propriétaire utilisé par notre système ECM (notre blackbox) et les diviser en plus petits morceaux afin d'en exploiter plus d'un. importation de la file d'attente Ensuite, nous devions surveiller les files d'attente des importateurs et les répartir correctement afin d'équilibrer la charge de file d'attente et après cette opération, nous devions trouver le résultat de l'opération de lecture d'un fichier XML de format propriétaire généré par l'importateur. Entre chaque étape de ce processus, il y avait une file d'attente ActiveMQ (avec persistance de la base de données) afin de tout garder asynchrone et chaque phase pouvait être augmentée, augmentant le nombre de consommateurs simultanés dans cette file d'attente spécifique. Nos microservices font également partie d'un flux de travail énorme et long géré par un ESB. Nous recevons donc des messages d'ESB et écrivons les messages de sortie dans ces files d'attente à l'aide de petits services Web pour obtenir/définir les objets.

Nous avons décidé d'opter pour Camel car il a résolu de nombreux problèmes d'intégration, il donne un contrôle complet à chaque route unique et peut être facilement surveillé par hawtio. De plus la plupart de la configuration est faite en écrivant ou en modifiant les fichiers de contexte XML, vous offrant ainsi de la flexibilité et vous évitant d'écrire beaucoup de code. La communauté est animée, le cadre est mis à jour très souvent et vous pouvez trouver beaucoup de livres et de tutoriels.

Donc je pense que votre problème a beaucoup de points de contacts et d'affinités par rapport à mon objectif de projet, donc encore une fois, j'ai définitivement décidé d'utiliser Apache Camel.

Avec de très bons résultats.