cadre de publication / abonnement léger en java

Question

Est-il une bonne infrastructure légère pour java qui fournit le modèle de publication/abonnement?

Certaines caractéristiques idéales

• Soutien pour les génériques
• L'enregistrement de plusieurs abonnés à un éditeur
• API principalement des interfaces et quelques implémentations
• purement en mémoire, de la persistance et de la transaction garantit pas nécessaire.

Je sais à propos de JMS mais c'est overkill pour mon besoin. La publication/l'abonné données sont le résultat de l'analyse d'un système de fichiers, avec les résultats de l'analyse nourris à un autre composant de traitement, qui sont ensuite traitées avant d'être introduit à un autre et ainsi de suite.

EDIT: Tous dans le même processus. PropertyChangeListener à partir de fèves de ne pas tout couper, puisque c'est la déclaration de changements sur les propriétés, plutôt que de publier des articles spécifiques. Je pourrais chausse-pied ProprtyChangeListener de travail par une "dernière publication de l'objet de la propriété", et donc les objets publiés. PropertyChangeListeners ne prennent pas en charge les génériques, et sont enracinées dans le changement de propriété sémantique, plutôt que de pur publier/souscrire. La java.util Observateur/Observable modèle serait une bonne chose, mais Oberver est une classe concrète.

Answer 1

Il semble que cela correspond aux exigences:

EventBus de Google Goyave Bibliothèque - "Publish-subscribe-style communication entre les composants sans nécessiter de composants à inscrire explicitement les uns avec les autres". Il peut aussi être une AsyncEventBus qui va distribuer les événements sur un autre thread.

Quelques options supplémentaires à prendre en compte:

1. Si elle est dans le même processus, il est possible de l' Observateur modèle peut être utilisé. Les abonnés peuvent ajouter des écouteurs et de recevoir des notifications d'événements. Observable est déjà partie de l'API Java.

2. FFMQ est un Java complète, léger, Rapide JMS 1.1 File d'attente de mise en œuvre.

Answer 2

JMS est aussi léger ou lourd que vous le configurez. Nous utilisons par exemple HornetQ dans un projet avec une file d'attente en mémoire. Il est facile à installer, ne nécessite aucune configuration basée sur JNDI et est vraiment facile à utiliser.

Je pense que JMS en tant qu'API pour Message Pub / Sub est aussi simple que possible. (Et pas plus facile;)

Answer 3

Puisque vous utilisez Spring, je ne sais pas si vous savez que Spring dispose de sa propre structure d’événements légers . Il est principalement utilisé dans le cadre même, mais il est parfaitement utilisable par le code de l'application.

Par défaut, il s’agit d’un synchrone pub / sub, mais vous pouvez le rendre asynchrone à l’aide de ApplicationEventMulticaster .

Answer 4

Je pense Chameau est également un bon candidat. Surtout avec la publication-souscription modèle

Chameau peut être incorporé et est léger. Il propose Enterprise Integration Patterns - de nombreux outils utiles pour l'intégration, à l'intérieur d'une application ou même avec d'autres acteurs (d'où le terme "Intégration").

Il se compare à Spring Integration mais plus complète de l'OMI.

Answer 5

Si vous dépassez les limites du processus, un certain "poids" va être engendré. Pourquoi dites-vous que JMS est un poids lourd? L'API est assez simple? Il y a des implémentations supposées légères, par exemple, les coûts plus lourds du lien , tels que la persistance et la transactionnalité sont facultatifs.

De quoi avez-vous besoin, qui est plus léger que cela?