PROJET : ETNIC ESB JANUS. Guide technique : WS-Notification - Clustering. BULL Services et Solutions

Transcription

1 PROJET : ETNIC ESB JANUS Guide technique : WS- BULL Services et Solutions Date : 20 novembre 2008 Version : 1.0 Référence Bull : ETNIC_ESB/ANA/00 Auteur : NOSEDA Anne

2 Projet ETNIC ESB JANUS Guide technique WS-Notification Clustering Référence du document Type de document ETNIC_ESB_ANA_00 Guide de configuration Version Description Ecrit par Revu par Date 1.0 Corps du document Anne Noseda (BULL) 20/11/2008 2/10

3 Table des matières Architecture...4 Limitations du composant servicemix-wsn Fonctionnement du topic administratif...6 Fonctionnement des topics virtuels...7 Introduction...7 Exemple...7 Configuration ActiveMQ...8 Configuration du composant servicemix-wsn Modification des classes JAVA du composant servicemix-wsn /10

4 Voici l'architecture générale du cluster : Projet ETNIC ESB Architecture Les instances de Servicemix ne sont pas réellement «clusterisées». Elles sont tout-à-fait indépendantes et il faut obligatoirement déployer tous les SA sur toutes les instances du cluster. Ce sont les brokers JMS ActiveMQ qui sont réellement «clusterisés». Les instances Servicemix sont connectées à toutes les instances du cluster de broker JMS. Elles sont également toutes connectées à la même base de données WSN (reprenant les informations de sécurité et la persistance des topics et des souscriptions). L'alteon joue le rôle de loadbalancer. Il répartit la charge sur les différentes instances de Servicemix. 4/10

5 Limitations du composant servicemix-wsn2005 Pour réaliser l'architecture ci-dessus, le composant servicemix-wsn2005 présentait 2 limitations : les souscriptions et enregistrements de publisher n'étaient pas propagés d'une instance à l'autre (pas de communication / synchronisation) prévue entre les instances ; si une souscription était présente sur plusieurs instances, elle recevait autant de fois le message de notification alors qu'il ne fallait lui en envoyer qu'un seul exemplaire. Ces limitations ont été corrigées de la manière suivante : création d'un topic administratif pour permettre aux différentes instances de communiquer ; utilisation de la notion de topic virtuel. 5/10

6 Fonctionnement du topic administratif Lorsqu'une instance reçoit un message de type : souscription ; enregistrement d'un publisher ; désinscription (pas encore implémenté); désenregistrement d'un publisher (pas encore implémenté) elle effectue son travail normalement puis envoi le message original ainsi que l'id de la souscription / de l'enregistrement dans un topic administratif. De cette manière, les autres instances du cluster, sont averties et peuvent se synchroniser. D'un point de vue technique, lors de l'initialisation du composant, il vérifie que le clustering est activé (par défaut il est désactivé). Si c'est le cas, l'instance se connecte à l'aide d'une souscription durable au topic adiministratif (par défaut le topic WSN_ADMIN). A chaque réception d'un message, il en vérifie le type (souscription, enregistrement d'un publisher, autre,...) puis le traite pour créer la souscription / l'enregistrement (création du endpoint, du consommateur JMS,...). 6/10

7 Fonctionnement des topics virtuels Introduction Le principe du publish/subscribe repose sur la notion de topic JMS. Lorsqu'un producteur envoie un message sur un topic, un exemplaire de ce message est automatiquement envoyé à chacun des consommateurs. En mode cluster, on ne peut pas souscrire à partir de chaque instance sur un même topic car on va recevoir N fois le message de notification alors qu'il n'en faut qu'un seul exemplaire par réelle souscription. La solution est de recourir à la notion de queue JMS : en effet, sur une queue, lorsqu'un message est posté il ne sera reçu que pas un et un seul consommateur. L'idée est de créer un topic «virtuel» qui forwarde les messages qu'il reçoit vers un ensemble de queue : une par souscription. Exemple Dans l'exemple ci-dessous, nous avons un topic WSN.MimesisTopic sur lequel les notifications seront postées. Lorsqu'un «subscriber» envoie une demande de souscription, le système crée automatiquement une queue nommé : «Consumer.» + l'identifiant unique de la souscription + le nom du topic. Si l'identifiant de la souscription est «ID-nom-du-host », le nom de la queue sera «Consumer. ID-nom-du-host WSN.MimesisTopic». 7/10

8 Configuration ActiveMQ Sur chaque broker ActiveMQ du cluster, il faut configurer la notion de topic virtuel (pour plus d'information, voir le site : Dans le fichier AMCTIVEMQ_ROOT/conf/activemq.xml, ajouter les lignes suivantes : <broker xmlns=" brokername="localhost" datadirectory="${activemq.base}/data">... <!-- VIRTUAL TOPIC WSN --> <destinationinterceptors> <virtualdestinationinterceptor> <virtualdestinations> <virtualtopic name="wsn.>" prefix="consumer.>.wsn.>" /> </virtualdestinations> </virtualdestinationinterceptor> </destinationinterceptors>... </broker> ATTENTION : Il est donc impératif que toutes les notifications soient envoyées sur des topics ayant comme préfixe WSN. sinon le clustering ne fonctionnera pas. Par contre, le nom du topic administratif ne doit PAS commencer par «WSN.» car il s'agit d'un topic réel et non virtuel. 8/10

9 Configuration du composant servicemix-wsn2005 Dans le fichier SERVICEMIX_ROOT/conf/jndi.xml, il faut configurer le pool de connexions JMS aux brokers JMS «clusterisés». <!-- wsn2005 jms connection factory --> <entry key="java:comp/env/jms/wsnotificationcf"> <bean class="org.apache.activemq.pool.pooledconnectionfactory" destroy-method="stop"> <constructor-arg value="tcp://localhost:51616" /> </bean> </entry> Dans le fichier SERVICEMIX_ROOT/conf/component.properties, il faut obligatoirement activer le clustering et donner un nom unique à chaque NotificationBroker (instance servicemix) du cluster car ce nom est utilisé pour créer l'id lors de la souscription JMS durable au topic administratif. servicemix-wsn2005.brokername=broker-instance1 servicemix-wsn2005.activateclustering=true D'autres propriétés sont paramétrables mais sont optionnelles : servicemix-wsn2005.jndiconnectionfactoryname=java:comp/env/jms/wsnotificationcf servicemix-wsn2005.clusteringadmintopicname=wsn_admin La première doit correspondre avec la clé de votre fichier JNDI (voir ci-dessus). La seconde permet de paramétrer le nom du topic administratif utilisé par le cluster. Si vous le changez, faites attention à utiliser le même nom sur toutes les instances du cluster et à ne pas le préfixer avec «WSN.». 9/10

10 Modification des classes JAVA du composant servicemix-wsn2005 package org.apache.servicemix.wsn class AbstractNotificationBroker : ajout d'une propriété activateclustering, ajout d'un appel à la méthode warnclustersubscription dans la méthode handlesubscribe pour prévenir les autres instances du cluster de la création d'une nouvelle souscription, ajout d'une méthode handlesubscribeclustering pour traiter un message de type 'souscription' venant du topic administratif, ajout d'un appel à la méthode warnclusterpublisherregistration dans la méthode handleregisterpublisher pour prévenir les autres instances du cluster de la création d'un nouvel enregistrement d'un publisher, ajout d'une méthode handleregisterpublisherclustering pour traiter un message de type 'enregistrement' venant du topic administratif, ajout de deux méthodes abstraites warnclustersubscription et warnclusterpublisherregistration. interface WSNConstants : ajout d'une interface regroupant toutes les constantes. package org.apache.servicemix.wsn.component class WSNConfiguration : ajout de 2 propriétés activateclustering et clusteringadmintopicname interface WSNConfigurationMBean : ajout de 4 méthodes isactivateclustering, setactivateclustering, getclusteringadmintopicname, setclusteringadmintopicname. class WSNLifeCycle : ajout de l'initialisation des 2 propriétés activateclustering et clusteringadmintopicname. package org.apache.servicemix.wsn.jms class JmsNotificationBroker : ajout de 5 propriétés clusteringadmintopicname, session, topicconverter, jmstopic, log; modification de la méthode init pour assigner un ID à la connexion et créer une souscription durable au topic administratif; ajout d'une méthode onmessage qui permet de traiter les messages en provenance du topic administratif; ajout de deux méthodes warnclustersubscription et warnclusterpublisherregistration pour créer le message à poster dans le topic administratif. class JmsSubscription : modification de la méthode start pour créer un consommateur JMS sur une queue et plus sur un topic (à cause de la notion de topic virtuel). package be.etnic.janus.wsn.security class EtnicSecurityHandler : ajout avant de créer la souscription ou de l'enregistrement d'un test sur leur présence. En effet, une autre instance peut déjà avoir créer la ligne en DB. class EtnicSecurityDbManager : ajout de 2 méthodes : subscriptionexist et registrationexist. 10/10