Des suggestions pour un modèle de programmation par événements ?

Bonjour à toutes et à tous
Il y a quelque temps de ça j'ai exploré un modèle de programmation par événement en créant un petit langage "ad hoc" (D.S.L) en Groovy.
Tout ça est bien gentil mais comme une réalisation sérieuse approche dans mon planning je me pose la question d'un choix de modèle de programmation Java plus "standard".

D'abord une petite idée du problème général: sur un réseau de micro-pcs pilotant des matériels j'ai un code "chef d'orchestre" qui demande à certains matériels d'exécuter des actions (supposons que l'ordre soit "ferme une vanne")
pendant que cet ordre est en cours d'exécution et que le chef d'orchestre en attend le résultat, des événements surviennent et sont notifiés au chef d'orchestre (" l'alim. électrique est en train de lâcher", "un tremblement de terre se déclenche" - ce n'est pas un blague on est en zone très sismique - , etc...). Il faut donc que le chef prenne certaines décisions dans le contexte d'une exécution.

Dans ma maquette Groovy j'avais donc une définition de contexte d'exécution associant des actions à des événements. On gère une queue d'événements (avec des événements plus prioritaires que d'autres) qui contient des codes qui sont exécutés en séquence. Quand on reçoit le code de fin d'exécution on a des opérations spéciales de vidange de la queue ... et on recommence (bon c'est une description très simplifiée).

Auriez vous à l'esprit quelque chose qui ressemblerait à ce genre de mécanisme en Java "pur" (ou avec une librairie -presque- standard) ? ... je regarde Java Rx mais je n'arrive pas trop à le faire correspondre à mes besoins .... (mais p.e. m'y prends-je mal).

Merci pour toute suggestion ou piste.

Est ce que les message driven beans ne correspondraient pas à votre cas.
En résumé, chaque message arrive dans une queue ou un topic (la différence est simplement que le topic notifie tous les subscribers alors que la queue est consomée que par un seul consumer)

Vous pouvez regarder activemq.

Pareil, ça me fait penser à une queue JMS la description, avec le chef d'orchestre qui, au fur et à mesure de la lecture des event lance des actions, action qui peuvent très bien envoyer leur résultat sous forme d'event, histoire de ne pas bloquer ton chef :)

Le plus dur c'est d'éviter l'effet "boule de neige" si trop d'event sont gérés en même temps.

je regarde d'un peu plus près activemq
pour JMS: initialement le projet avait une couche de message JMS, d'un point de vue du transfert de messages je suis passé à une implantation Jgroups (pour un tas de raisons)
il y une distinction entre la gestion d'envoi/reception des messages et les traitements associés à des événements (qui résultent de la réception de message mais aussi d'évènements générés dans la JVM locale - y compris par le code du chef d'orchestre lui même). Il y a une gestion sophistiquée de la queue avec un contexte global par "script" et un contexte lié à une action en cours.
J'ai déjà écrit une maquette qui fait ça mais ce qui m'inquiète c'est le "modèle" à offrir aux programmeurs (c'est pas tous des javaïstes ceinture noire 4° dan) il faut leur offrir une vision simple à comprendre, à formuler, à débuguer ...

Est-ce que tu as regardé Apache Storm ? ou Apache Camel ?
Il y a aussi Akka.