JMS/ActiveMQ : Spring vs Grails
Vous avez peut être entendu parler de Grails, ce nouveau framework Web Java qui vise à fournir une solution simple, rapide et efficace pour créer des applications Web JEE. Grails est une plateforme de développement qui grâce à son système de plugins intègrent plusieurs APIs et frameworks de l'écosystème Java visant ainsi à fournir une stack complète packagée et intégrée pour répondre d'une manière efficace et élégante aux différentes problématiques liées à la création des applications d'entreprises orientées Web...
Dans ce premier billet, nous nous attarderons sur la comparaison entre deux implémentations d'une application utilisant JMS et ActiveMQ : une première implémentation avec Spring et JMS et une deuxième avec le plugin grails-activemq.
JMS et ActiveMQ avec Spring
Je vous propose dans un premier temps une implémentation de base d'ActiveMQ avec Spring. Pour cela plusieurs étapes sont nécessaires :
- Télécharger et installer ActiveMQ.
- Créer un
pom.xmlavec les dépendances nécessaires. - Déclarer les beans nécessaires dans le fichier applicationContext-services.xml :
<beans>
<!-- pool de connection JMS -->
<bean id="jmsFactory" class="org.apache.activemq.pool.PooledConnectionFactory" destroy- method="stop">
<property name="connectionFactory">
<bean class="org.apache.activemq.ActiveMQConnectionFactory">
<property name="brokerURL">
<value>tcp://localhost:61616</value>
</property>
</bean>
</property>
</bean>
<!-- template JMS Spring simplifiant la gestion des message JMS -->
<bean id="jmsTemplate" class="org.springframework.jms.core.JmsTemplate">
<property name="connectionFactory">
<ref local="jmsFactory"/>
</property>
</bean>
<!-- Définition d'une queue permettant d'échanger les message JMS -->
<bean id="destination" class="org.apache.activemq.command.ActiveMQQueue">
<constructor-arg index="0">
<value>queue.destination</value>
</constructor-arg>
</bean>
<!-- Template JMS Spring simplifiant la gestion des message JMS -->
<bean id="listenerSample" class="sample.activemq.ListenerSample "/>
<bean id="listenerContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer">
<property name="concurrentConsumers" value="3"/>
<property name="connectionFactory" ref="jmsFactory" />
<property name="destination" ref="destination" />
<property name="messageListener" ref="listenerSample" />
</bean>
<!-- création d'un bean spring qui utilise le template JMS et la destination pour envoyer les message -->
<bean id="springProducer" class="sample.activemq.ProducerSample">
<property name="template" ref="jmsTemplate"/>
<property name="destination" ref="destination"/>
</bean>
</beans>
- Créer le bean ProducerSample, qui s'appuie sur JmsTemplate de Spring pour créer et envoyer les messages JMS :
import javax.jms.Destination;
import javax.jms.JMSException;
import javax.jms.Message;
import javax.jms.Session;
import javax.jms.TextMessage;
import org.springframework.jms.core.JmsTemplate;
import org.springframework.jms.core.MessageCreator;
import java.util.Date;
/**
* @author karl verger
*/
public class ProducerSample {
private JmsTemplate jmsTemplate;
private Destination destination;
public void sendMessage(){
MessageCreator messageCreator = new MessageCreator() {
public Message createMessage(Session session) throws JMSException {
TextMessage textMessage = session.createTextMessage();
textMessage.setText("Hi, this is a Hello World with JMS & ActiveMQ, " + new Date());
textMessage.setJMSType("text");
return textMessage;
}
};
getTemplate().send(getDestination(), messageCreator);
}
public JmsTemplate getJmsTemplate() {
return jmsTemplate;
}
public void setJmsTemplate(JmsTemplate template) {
this.jmsTemplate = jmsTemplate;
}
public Destination getDestination() {
return destination;
}
public void setDestination(Destination destination) {
this.destination = destination;
}
}
- Créer le bean ListenerSample pour consommer les messages de manière asynchrone :
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.jms.JMSException;
import javax.jms.Message;
import javax.jms.MessageListener;
import javax.jms.TextMessage;
/**
* @author karl verger
*/
public class ListenerSample implements MessageListener {
public void onMessage(Message message) {
try {
System.out.println("GOT MESSAGE: "+ ((TextMessage)message).getText() );
} catch (JMSException ex) {
Logger.getLogger(JmsListenerSample.class.getName()).
log(Level.SEVERE, null, ex);
}
}
}
JMS et ActiveMQ avec Grails
Je vais essayer de démontrer à quel point l'utilisation de Grails permet de simplifier l'implémentation d'ActiveMQ et de booster la productivité. La mise en place de JMS avec Grails et ActiveMQ nécessite les étapes suivantes :
- Installer le plugin ActiveMQ avec la commande :
grails install-plugin activemq - Installer le plugin JMS avec la commande :
grails install-plugin jms - Créer une classe Groovy pour la production de messages :
def index = {
def message = "Hi, this is a Hello World with JMS & ActiveMQ, " + new Date()
sendJMSMessage("queue.destination", message)
render message
}
}
- Créer un service Groovy pour la réception des messages :
boolean transactional = false
static expose = ['jms']
static destination = "queue.destination"
def onMessage = {
println "GOT MESSAGE: $it"
}
}
Retour d'expérience
La création et la préparation du projet Grails est très simple, l'outil create-app permet de générer rapidement la structure du projet avec des exemples de code fonctionnel. Avec Spring plusieurs étapes sont nécessaires pour la création et la configuration du projet.
Avec Grails, la configuration par défaut est générée lors de l'installation des plugins JMS et ActiveMQ ce qui n'est pas le cas pour l'exemple Spring ou une déclaration des beans est nécessaire dans le fichier application-services.xml.
Le plugin grails-activemq fournit une solution simple pour l'échange de messages entre applications et composants permettant ainsi de booster la productivité et de produire un code simple et facilement maintenable. Toutefois, ce plugin n'est toujours pas production ready et reste donc, pour le moment, à tester à petite échelle.
Bonjour,
Je lisais l'article sur grails activemq et jms. Je me permets juste de demander en quoi ces plugins ne sont pas production ready surtout pour grails-jms qui est le fruit d'un effort particulier de Luke Daley, un grails comitter. J'ai vu des applications en prod avec ce plugin sans soucis particulier, quelques échanges sur la mailing liste confirmeront je pense.
L'auteur a indiqué sur la page de documentation du plugin : http://www.grails.org/ActiveMQ+Plugin qu'il n'est toujours pas production ready.
This plugin at the moment is not production ready. Use at your risk for rapid prototyping with JMS without installing anymore.
Mea culpa je parlais du plugin JMS en particulier car je n'ai pas souvent vu activeMQ embedded effectivement en prod !
Bonjour,
Je trouve cet article un peu biaisé dans la forme : on voit 200 lignes de code XML/Java d'un côté, 20 de l'autre, évidemment vu comme ça c'est tentant. Malheureusement il doit manquer des choses côté Grails : où est configuré l'URL du JMS, la taille du pool de consumer, la gestion des exceptions...
Est-on bien en train de comparer 2 choses à périmètre équivalent ?
De mon côté, je retiens plutôt la solution d'utiliser le plug-in JMS et de configurer à la main ActiveMQ. Il suffit de configurer un bean jmsConnectionFactory et le broker (que ce soit ActiveMQ ou un autre, embarqué dans l'application ou séparé). Je pense que le plug-in ActiveMQ n'est pas marqué comme production-ready car il ne fournit aucun moyen de configurer ActiveMQ. En configurant ActiveMQ via Spring, on retrouve la flexibilité sans perdre le bénéfice de la simplicité de configuration.
Pas mieux que le monsieur au dessus !
Intéressant, mais la comparaison Spring vs Grails est un peu tirée par les cheveux :
- Grails, c'est du Spring emballé, donc à priori on aurait pu prendre la conf Spring et la copier tel quel dans l'appli Grails.
- Ce n'est pas tant Grails en soit que le plugin associé qui facilite la configuration. En réalisant un plugin équivalent en Java, on y gagnerait aussi pour la version Spring, non ?
- Les plugins Grails, c'est bien, quand ils sont bien réalisés et bien maintenus. Si l'on prend l'exemple du plugin Acegi Security (présenté sur ce blog dans un article précédent), il est intéressant, mais dès qu'on rentre dans certains cas spécifiques de configuration il montre ses limites, et les développeurs du plugin sont aux abonnés absents.
La comparaison n'est pas tirée par les cheveux, l'expression que donnent Groovy et Grails change complètement la donne. Je pense que c'est ce qu'a voulu appuyer l'auteur ici.
Quant aux plugins, ce sont des initiatives généralement dérivée de travaux internes et ils sont gentiment proposés en tant que tels, à la manière d'un SDK. Il n'est pas interdit de retoucher un plugin voire de partager ses améliorations si on lui trouve des manques. Même si on rêve de ça (http://bit.ly/amceaS , mon stupide poisson d'avril) , que des amis chez spring parlent d'un futur repo gold maintenu, un développeur plugin est un développeur d'applications grails. Dés lors, tous les développeurs sont invités à contribuer à faciliter la vie des autres
[...] JMS : Spring versus Groovy Share and Enjoy: [...]