Comme chaque premier jeudi du mois, les consultants Xebia se sont réunis en fin de semaine dernière pour le XKE (Xebia Knowledge Exchange).
La journée a commencé par un jeu intitulé « Questions pour un Xebian » organisé par Cyrille Le Clerc et Jean-Laurent de Morlhon où il a été question de reconnaître ce que cachent plusieurs noms de technologies en vogue (sass, haml, hateoas, etc).
Nous avons ensuite poursuivi avec deux sessions en parallèle :
- Algorithme Min / Max et Tournoi de Puissance 4, animé par Morgan Renou
L’objectif de cette session était de présenter l’algorithme MiniMax avec un élagage Alpha-Béta afin de développer de petites intelligences artificielles s’affrontant dans un tournoi puissance 4. - Mule ESB, animé par Jean-Louis Rigau
Après avoir expliqué les principes fondamentaux de Mule ESB, cette session a permis de détailler, étape par étape, la mise en place d’une boutique en ligne, axée sur les traitements back-office.
Après le déjeuner, deux nouvelles sessions en parallèle :
Lire la suite de cet article »
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
Le coin de la technique
Lire la suite de cet article »
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.
Lire la suite de cet article »
Vous avez une application Java qui doit envoyer et recevoir des messages à droite et à gauche pour des raisons qui n’appartiennent qu’à vous… Votre premier réflexe sera sûrement de contacter votre vieil ami JMS. Pour ça, vous aurez aussi besoin d’un broker de message, mais vous n’êtes pas très riche et des outils comme WebSphere ou Tibco sont hors de portée… Vous aurez alors de fortes chances de vous tourner vers votre autre vieil ami ActiveMQ. Bon d’accord, l’amitié ça compte, mais par ailleurs d’autres amis (des vrais !) vous signalent qu’ils ont eu quelques problèmes de blocage de file avec ActiveMQ et qu’ils ont eu du mal à identifier ces problèmes. En plus vous avez encore d’autres amis qui aimeraient bien communiquer avec vous sur ce même broker mais leurs applications tournent en ruby et C++ qui parlent mal le JMS… C’est le moment idéal de vous présenter un nouvel ami : AMQP !
AMQP (Advanced Message Queuing Protocol) est un protocole de messagerie créé à l’initiative de la banque JP Morgan Chase pour gérer la communication entre ses différents partenaires. Le but affiché était de fournir une solution alternative aux solutions payantes et relativement chères dans le domaine du MOM (Message-Oriented Middleware) dominé largement par Websphere MQ d’IBM et RendezVous de Tibco (93% du marché à eux deux en 2008). Un certain nombre de partenaires se sont fédérés autour de ce projet pour aboutir à une première spécification en 2006. L’ambition avouée est qu’elle devienne l’équivalent du HTTP pour l’internet, ce qui explique qu’elle décrive aussi bien les différentes sémantiques liées au MOM que la partie plus bas niveau du transport de ces messages. Cette normalisation permet la multiplication des solutions clientes ou serveurs dont la compatibilité sera garantie par cette spécification. Par exemple, un broker de message écrit en Erlang comme RabbitMQ transférera de façon transparente un message d’un client ruby vers un autre client Java/JMS.
Notez bien qu’AMQP s’identifie clairement comme un protocole et non comme une API, contrairement à JMS. Donc un client Java basé sur JMS peut, moyennant des adaptations plus ou moins coûteuses, communiquer avec un broker AMQP.
Lire la suite de cet article »
Le serveur d’applications Weblogic permet de déclarer des serveurs JMS. À chaque serveur JMS est associé un Persistent Store, emplacement destiné à persister les messages JMS en cas d’interruptions de service entre la publication d’un message et sa consommation. Deux supports possibles :
- File Persistence Store, un répertoire accessible par le serveur Weblogic composé d’un ou plusieurs fichiers de structures binaires (.DAT)
- JDBC Persistence Store, ensemble de tables contenues dans une base de données relationnelle et accessible à travers une ‘DataSource’. La structure des tables et leur contenu sont exclusiment gérés par le serveur d’applications.
Le choix de l’un des deux types de stockage est principalement dicté par des contraintes d’architecture et d’exploitation; les avantages de l’un sont les inconvénients de l’autre.
Jusqu’à la version 8 de Weblogic, il était impossible de pouvoir les administrer, en particulier pouvoir les ouvrir, analyser ou dumper leur contenu.
À partir de la version 9, le serveur d’applications propose un outil : weblogic.store.Admin
java -classpath ${WLS_DIR}/servir/lib/weblogic.jar weblogic.store.Admin
Les commandes principales sont : open, dump et compact.
Lire la suite de cet article »
Complet
Twitter
