Événements Java personnalisés avec les écouteurs par rapport à une implémentation basée sur JMS?

Question

Mon application nécessite que des événements soient déclenchés en fonction de certaines activités spécifiques. J'essaie de déterminer si je devrais créer mon propre système de gestion d'événements en utilisant Java EventObject avec des écouteurs personnalisés similaires à Java AWT Ou devrais-je utiliser une implémentation JMS? Je considérais la solution Qpid ou ActiveMQ d'Apache. J'explore ces options en ce moment et je me demandais si quelqu'un avait de l'expérience avec Qpid ou ActiveMQ et pouvait offrir quelques conseils (p. Ex. Avantages, inconvénients à considérer, etc.) Aussi, si quelqu'un a des suggestions pour construire un système de gestion d'événements simple ... si cela vaut la peine de considérer cela sur une solution basée sur JMS.

Answer 1

Les écouteurs d'événements simples (tels qu'utilisés dans Java AWT) requièrent que les événements soient traités immédiatement, dans la même machine virtuelle et généralement dans le même thread. JMS (par exemple, en utilisant ActiveMQ) permet de gérer les événements ultérieurement (en mettant éventuellement en mémoire tampon les messages dans un stockage persistant) et dans d'autres machines/threads virtuels. Cette flexibilité se fait au prix d'une complexité supplémentaire et d'une efficacité moindre.

Answer 2

Vous n'avez pas beaucoup parlé de votre application, mais si vous avez besoin d'un simple système de gestion d'événements pour une seule machine virtuelle, jetez un œil à EventBus.

Answer 3

Souhaitez-vous que les messages/événements encore à traiter soient conservés au cas où votre instance JVM meurt? Si c'est le cas, vous aurez besoin d'une file d'attente de messages externe. Est-ce que d'autres applications auront besoin de publier/consommer les mêmes messages que cette application? Même chose.

Answer 4

2016 Mise à jour

ALTHO événements java ont été ajoutés en 2006, et cette question est à partir de 2010, ceux-ci sont encore en quelque sorte des caractéristiques « cachées » dans l'API Java, la lecture de la question que je crois une alternative qui ne exactement ce que vous voulez sont les événements Java, mais pas ceux des événements AWT Java 6, qui vous permettent de découpler vos modules de projet et d'avoir des capacités JML sans serveur, le seul inconvénient des événements par rapport à JMS, est que l'auditeur doit courir, sinon le message sera perdu dans l'oubli.

de: https://dzone.com/articles/java-ee6-events-lightweight

Yo créer un message:

public class LogMessage implements Serializable { 

    private final String message; 
    private final Level level; 

    LogMessage(String message, Level level) { 
     this.message = message; 
     this.level = level; 
    } 

    public String getMessage() { 
     return message; 
    } 

    public Level getLevel() { 
     return level; 
    } 
} 

Vous créez un producteur:

@Inject Event<LogMessage> event; 


event.fire(new LogMessage("Log it baby!", Level.INFO)); 

et enfin, vous créez un consommateur:

public class LogListener { 
    private static final Logger LOGGER = Logger.getAnonymousLogger(); 
    public void process(@Observes LogMessage message){ 
     LOGGER.log(message.getLevel(), message.getMessage()); 
    } 
} 

Consultez l'annotation @Observes.

Tout cela se fait de manière synchrone et bien être plus jms/comme vous voulez faire de ce processus de manière asynchrone, pour ce juste ajouter:

@Stateless 
@Asynchronous 
public class LogListener { 
    private static final Logger LOGGER = Logger.getAnonymousLogger(); 
    public void process(@Observes LogMessage message){ 
     LOGGER.log(message.getLevel(), message.getMessage()); 
    } 
}