Utiliser Karaf dans une architecture en cluster

Lors de la première partie dututo “Développement OSGI pour serveur Karaf“, nous avions vu que le serveur Apache Karafavait un certains nombres de qualités intéressantes dont la capacité à créer desinstances filles en quelques lignes de commande.Mais j’avais omis un petit détail qui peut avoir son importance, cette qualité va luipermettre de travailler en mode DOSGi.PrérequisSi les notions de création de projet OSGi orienté Apache Karaf ne vous sont pasfamilières je vous propose d’aller faire un tour du coté des tutoriaux suivants :Développement OSGi pour serveur Karaf – Part 1Développement OSGi pour serveur Karaf – Part 2Développement OSGi pour serveur Karaf – Part 3Si vous avez besoin de vous référencer à quelque chose d’existant au cours de cetutorial je vous propose le tarball du projet : drinkerProject.tar.gz.Qu’est ce que le mode DOSGi ?DOSGi signifie Distributed OSGI, soit le développement d’application utilisant descomposants distribués sur un cluster. En résumé chacun des noeuds du cluster sera encapacité d’écouter et d’émettre des informations vers les autres noeuds.Mise en place d’un cluster (généralités)La capacité d’OSGi est apportée entre autres par un module de Apache Karaf appeléCellar. Ce module propose, au travers de la brique Hazelcast, de manager et synchroniserles instances de karaf composant un cluster. Il permet entre autres :La découverte automatique des noeuds (en outre par multicast ou peer2peer)La création de groupe de cluster, chacun d’eux aura sa propre configuration ainsi queson propre jeu d’installationLa distribution des configurations : à chaque modification sur un noeud celle-ci estdirectement relayée vers les autres noeuds du groupe.La distribution des features : à chacune des installations sur un noeud les features etles informations de repositories seront partagées sur l’ensemble des noeuds du groupeLa distribution des bundles : à chacune des installations sur un noeud les bundlesseront partagés sur l’ensemble des noeuds du groupeUne interface Web permet de gérer et superviser les groupes de clusterPour finir, Cellar embarque la possibilité de fonctionner en mode DOSGi, afin de pouvoircontacter des composants présents dans le clusterCellar s’installe comme n’importe quelle application dans karaf, rendez vous dans laconsole :1

Nous voila avec une instance Karaf “cellarisée” !Il nous faudra juste la configurer et créer des instances filles pour mettre en place uncluster de façon relativement simple.Pour se faire, cellar embarque une certaine quantité d’outils en ligne de commande quel’on peut obtenir en préfixant l’appel par “cluster:<TAB>” :

Configuration de baseDans le cadre de ce tuto, je vous propose de travailler avec des “instances fille”. Ils’agit d’une des facilités de karaf permettant de créer des copies partielles de serveurn’intégrant que :Les fichiers de configurationLe dossier de données qui contiennent toutes les informations d’exécutionLes fichiers de logsLes fichiers temporairesChacune des instances peut être lancée indépendamment des autres et posséder ses propresapplications.Donc notre configuration sera la suivante :

Création des instances fillesPour créer une nouvelle instance, nous allons utiliser un des outils pratiques de Karaf: admin:create.Voici l’exemple pour l’instance “barman_1” :

Donc l’opération sera à refaire pour :“client”“barman_2”Une fois les instances filles créées, il va falloir leur installer Cellar avec ladémarche vue dans la partie “Mise en place d’un cluster (généralités)”. Mais avant ça,

il va falloir démarrer et se connecter à chaque instance.Par exemple voici la procédure pour “barman_1” (la même chose est à faire sur les deuxautres instances) :

Comme on le voit il est facile de se connecter aux instances filles à partir del’instance mère… et si vous oubliez le nom d’une instance n’oubliez pas que danskaraf le shell possède une complétion avec <TAB>.Donc maintenant, si nous allons sur n’importe qu’elle instance fille et que nous faisonsun cluster:node-list, nous obtenons la liste suivante :

Remarque : Par défaut, toutes les instances sur lesquelles cellar est installé sontvisibles par tous les noeuds du cluster ! Sans configuration supplémentaire, tous lesnoeuds appartiennent au même groupe. La ligne préfixé par * n’est autre que l’instancesur laquelle nous sommes connecté.

Un peu de codeNous souhaitons obtenir une hiérarchie de ce genre :

DrinkService : L’interface de notre service1DrinkServiceImpl : L’implémentation du service1Drinker : Notre consommateur1DrinkerCommand : Notre extension de shell1

Personnellement, j’ai créé 1 projet avec 3 sous projets :DrinkerProject : Contient les 3 autres projets + un dossier de ressources dans lequelson place le fichier features.xml.drinker-api : Ne contient que l’interface et génère un jar tout ce qu’il y a de plussimple. Afin de partager cette dernière vers les deux autres modules.drinker-service : Contient l’implémentation du service ainsi que le fichier dedéfinition blueprint de notre module.drinker-client : Contient le client et l’extension de shell et utilise le service définidans le projet “DrinkerService”.Le fichier features.xml contient les entrées suivantes :all-in-one : installation totale des bundles en une fois (pour un test mono instance parexemple)drinker-client : installation des bundles utilisés pour le clientdrinker-client : installation des bundles utilisés pour les services1Test des bundlesSi vous souhaitez tester votre code sans toucher à vos 2 instances toutes propres, vouspouvez créer une instance “test”, la démarrer, vous y connecter et lancer les commandessuivante :1Si la dernière commande vous renvoie “Your glass of vodka is served ;)” c’est que vosbundles sont fonctionnels et que tout est ok pour la suite.Séparation des rôlesNous allons séparer nos instances par métier et donc par groupe :grp_bar : comportant barman_1 et barman_2grp_crowd : comportant clientRien de plus simple à faire avec Cellar et ses commandes cluster:group-*.

Pour explication, la commande cluster:group-create grp_crowd et cluster:group-creategrp_bar permet de créer nos deux groupes.La commande cluster:group-set grp_bar et cluster:group-set grp_crowd permet d’attribuerun groupe à chaque noeud. Facile, non ?!Mais, mise à part à bien ranger nos instances, à quoi vont servir ces groupes ? Et bienils vont permettre de faciliter notre gestion des installations et des configurationsgrâce encore une fois aux commandes émanantes de “cluster:”.Nous voulons installer le service sur les instances “barman_*” et notre client surl’instance client et voir se qui se passe. Pour commencer, installons les serveurs avecla commande suivantes :1L’utilisation de la commande cluster:feature-install [groupe] [feature] permetd’installer la feature sur l’ensemble des instances appartenant au groupe. Pratique, non?Pour vérifier si la feature et donc ses bundles sont bien démarrés, il suffit de fairela commande osgi:list et de vérifier la colonne “State”, si l’état est “Active” c’estbon sinon il y a un problème de lancement :1Passons au client avec son bundle “drink-consumer” :1Comme on peut le voir, les bundles sont bien actifs et apparemment aucune erreur n’estlevée !

Si tout est OK, testons notre appel avec la commande drink:commandchampagne. Malheureusement l’appel va se faire mais le retour ne sera pas celui escompté car nous obtenons une string “null”.Ce comportement est normal. En effet, les services sont sur 2 instances différentes etle client sur une 3ième … aucune chance qu’ils se connaissent et par conséquent aucunechance que le service ne réponde au client.C’est la capacité DOSGi de Karaf avec Cellar qui va nous donner la solution à ceproblème.Donc le DOSGi dans tout ça ?Il va permettre de répondre de façon relativement simple au problème “d’absentéisme”mentionné ci-dessus. Précédemment, nous avons installé Cellar sur chacun de nos serveurs“barman”. Mais vu que nous n’avons installé que la base de Cellar, nous ne pouvons pasencore faire du DOSGI (Les prochaines versions inclurons directement la fonctionnalité).Mais les développeurs ont eu la bonne idée de rajouter une feature se nommant “cellar-dosgi”. Donc empressons nous de l’installer !Mais avant il faut que le service soit rendu compatible avec cette fonctionnalité, cen’est pas très compliqué cela se limite en une ligne lors de la définition blueprint duservice :1L’entrée “service.exported.interfaces” est utilisée pour rendre distribué le service. Etça sera tout … rien d’autre à faire de ce côté !Nous allons nous concentrer sur les instances appartenant au groupe “grp_bar”.Sur chacune des instances installons cellar-dosgi de la façon classique :1Remarque : Pensez à mettre à jour la feature sur chacun des serveurs pour prendre encompte les derniers ajouts faits dans le fichier blueprint.Pour vérifier que l’installation a bien fonctionné, nous allons utiliser une nouvellecommande apporté par cellar-dosgi permettant de voir les services distribués :1Nous pouvons donc observer que nos deux instances “barman_*” possède un servicedistribué identifié par l’interface “fr.conceptit.tuto.drink.service.DrinkService”.A présent, si nous nous rendons sur l’instance “client” et que nous exécutons notrecommande notre réponse sera celle attendue :

Petit plusPour une raison de traçabilité ou seulement par curiosité, il serait bon de savoir quelnoeud nous a répondu. Il suffira de modifier 2 choses dans notre projet “service” afinde questionner directement le cluster.Récupérer le manager de cluster et lui demander l’ID du noeudAjouter cet ID dans la réponse émise par le service.Pour récupérer l’ID on va tout simplement utiliser l’IOC de blueprint en demandant larécupération du manager de Cellar. Cela va se faire via la configuration blueprint :1Ligne 1 : Récupération du service “ClusterManager” via son interface.Ligne 2 : Utilisation le bean de référence du ClusterManager comme une factory pourrécupérer l’objet Node (qui définie le noeud en cours) via la méthode getNode.Ligne 3 : Utilisation du Node comme une factory pour récupérer l’ID via la méthode getIdde l’objet.Pour l’injecter dans le service on ajoute dans la classe un constructeur avec unargument de type String et dans le blueprint on ajoute une injection par constructeur :1Une fois cela fait, puis après compilation et redéploiement, on peut se rendre compte dutravaille de la mise en cluster des services en faisant des appels successifs :

On voit bien que la réponse ne provient pas tout le temps du même noeud. Vous pouvez àprésent faire le test de couper une instance serveur et de la relancer et voire lecomportement émanant du DOSGi.ConclusionNous avons pu voir ici quelques facilités offertes par karaf au niveau de la créationd’instances filles et surtout sa capacité à distribuer des services au sein d’uncluster. Cette capacité à être monté en cluster permet à votre infrastructure à base deKaraf de répondre aux montées en charge ou aux coupures possibles d’un sous-réseau.Ainsi cela rend possible une continuité de service grandement appréciable dans le cadred’une plateforme haute disponibilité comme dans le cas d’une intégration EDI partenaireou clients.

Développement OSGi pour serveur Karaf – Part 3

Dans la partie 2, nous avons commencer à mettre en place une application devente/échange de spiritueux et de vins qui va nous servir de support le la suite desopérations. Cette partie va concerner le module persistance. En effet, pour le moment,notre sauvegarde de données se fait dans une ArrayList ; niveau persistance on a déjà vumieux! C’est pourquoi nous allons, dans cette partie, mettre en place une solution detype base de données. Personnellement en ce moment, j’aime beaucoup les base de donnéesde type document , mais pour les besoin de l’exemple je vais utiliser une base dedonnées “classique” du genre Oracle, mySQL, postgres, derby, hsql et consorts.La source de donnéesLorsque dans un serveur J2EE classique nous utiliserions un connecteur JNDI pour secoupler à la DataSource, dans un serveur OSGI nous allons utiliser un service OSGI …normal ! La création de notre DateSource va être simplifiée par l’utilisation deblueprint encore une fois. La définition du DataSource va se faire par la création d’unbean implémentant l’interface “javax.sql.DataSource “corespondant à la base de donnéesque vous souhaitez attaquer. Puis une fois ce bean créer, nous exposerons un servicerépondant à l’interface “javax.sql.DataSource” et référençant notre bean et lui donnantun p’tit nom à la JNDI. Dans l’exemple nous allons utiliser une base full Java nommé H2.Dans karaf, il ne faut pas oublier que les applications n’emportent pas leursdépendances – et cela vaut aussi pour le drivers de base de données – et qu’il faudradonc installer le drivers dans karaf. Afin de vous laisser le choix des armes voici uneliste des dépendances utilisables pour quelques bases couramment rencontrées :

Base dedonnées

Installation des dépendances dans Karaf

DB2 mvn install:install-file -DgroupId=com.ibm.db2.jdbc -DartifactId=db2jcc -Dversion=10.1 -Dpackaging=jar -Dfile=”C:\Program Files(x86)\IBM\SQLLIB\java\db2jcc.jar”

DERBY install -s mvn:org.apache.derby/derby/10.10.1.1H2 install -s mvn:com.h2database/h2/1.3.170

HSQL install -s mvn:org.hsqldb/hsqldb/2.2.9MYSQL install -s mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.stax-

api-1.2/2.2.0install -s mvn:mysql/mysql-connector-java/5.1.24ORACLE mvn install:install-file -

Dfile=”C:\oraclexe\app\oracle\product\11.2.0\server\jdbc\lib\ojdbc6.jar” -DgroupId=ojdbc -DartifactId=ojdbc -Dversion=11.2.0.2.0 -Dpackaging=jar

POSTGRES install -s wrap:mvn:postgresql/postgresql/9.1-901-1.jdbc4Plus tard, nous utiliserons les facilités offertes par le fichier features.xml quipermettera de faciliter la “mise en production”.L’installation de la dépendance pour H2 se fera donc de la façon suivante :1Une fois le driver de base de données installé, il nous faut créer notre servicepermettant d’interagir avec la base. Comme nous l’avons vue dans la partie précédentecréer un service n’est pas chose compliquée et pour preuve voici le code pour notreservice de base de données :1Une fois ce fichier XML défini nous avons en notre possession une data source définiepar les critères suivant :Base de données : H2Nom de base : cellar_bdUser : johnPassword : doeNom d’exposition du service d’accès : jdbc/cellar_bdMaintenant la question est simple: comment l’utiliser ? JDBC ou JPA ? Avec quelframework OpenJPA, Hibernate ou autres ? Les possibilités sont assez variées, certainestrès simples d’autres beaucoup plus complexes !Allez on se connecte !Nous allons commencer par la base, c’est à dire la mise en place d’une interaction avecla base utilisant JDBC.Dans la partie 2, nous avions défini une classe SpiritServiceImpl dans le bundlepersistence. Cette classe possédait une ArrayList en guise d’élément de persistance ; Lebut du jeu va être de remplacer cette liste par une vraie base de données.Dans le but de faire à peu près correctement les choses, nous allons remplacer lesopérations sur la liste de spirit par un objet de type DAO que j’appellerai sanssurprise … SpiritService.1Remarque : Ce DAO vérifie à sa création si la table CELLAR existe, dans le cascontraire le DAO crée cette table. Au passage, on pousse quelques informations dedansafin de vérifier le bon fonctionnement de notre application. Si vous souhaitez vérifierque la base est bien créée et bien peuplée vous pouvez vous connecter à la base avec unlogiciel tel que l’excellent SQuirreL.L’utilisation de cette DAO à partir de notre service passera par une injection utilisantla capacité IOC de blueprint. Nous modifierons le fichier persistence.xml pourconstruire le DAO et le pousser vers le service. Au passage, un va injecter laDataSource dans le DAO :1Le Service s’en trouve simplifié :1Installation facileAu début de ce post, nous avons vu que pour utiliser notre base de données il fallaitinstaller le driver sur karaf. C’est rapide, facile mais le développeur peut encorefaciliter la manipulation au client final. Pour ça on retourne sur notre fichierfeatures.xml dans le projet spout-feature afin d’ajouter tout simplement le driver outout autre dépendance nécessaire.1Et voila c’est tout !L’installation se ferra ainsi en une fois sans se poser de question sur les dépendancesà installer à coté.JDBC c’est bien mais après …Il est toujours un peu fastidieux de travailler avec le JDBC surtout dans le cas de CRUDsimpliste qui peuvent être facilités par tout ORM qui se respecte. C’est pourquoi laprochaine fois on ira voir du coté de JPA.On se ferra aussi un petit module afin de tester l’insertion de donner et pour cela nousutiliserons une des facilitées liée à karaf … l’extension de shell.

Développement OSGi pour serveur Karaf – Part 2

Dans la première partie Développement OSGi pour serveur Karaf – Part 1, nous avons vucomment créer un bundle de base et comment le déployer facilement dans Karaf enpermettant un redéploiement à la volée en cas de repackaging de notre bundle.Dans cette partie nous allons mettre en place une logique d’application afin de mettreen place quelques concepts de base.

Le cas pratiqueAfin de pouvoir mettre en place une logique d’application, nous allons travailler enutilisant comme base un cas pratique que j’appellerai “SPOUT”. Il s’agira de mettre enplace une plateforme de vente/échange de spiritueux et de vins.La première partie de cette plateforme se composera d’une interface minimale d’insertionunitaire, d’une interface minimale de recherche (listing par critère “type”) et de lamise en place des bundles de bases de notre application.model : Contenant l’interface du service de persistance et l’objet représentant notreproduit (spiritueux ou vin)persistence : Contenant l’implémentation du service mentionné précédemment (logique desauvegarde et de recherche) ui : Contenant les classes permettant de construire l’interface.NB. : L’ensemble de ces composants sera modifié au fur et à mesure des parties afind’utiliser différents composants susceptibles de s’approcher ducahier d’acceptance d’une telle application en milieu professionnel. Notre projetcontiendra donc 3 bundles donc au moins 3 projets eclipse/maven. Je décomposerai toutceci en 5 parties :Un fichier pom.xml servant de parent aux différents projetsUn projet “model” contenant mes sources et le pom.xmlUn projet “persistence” contenant mes sources et le pom.xmlUn projet “ui” contenant mes sources et le pom.xmlUn projet “features” contenant un fichier ressource “features.xml” et le pom.xml.Soit l’arborescence suivante :spoutpom.xmlfeaturespom.xmlsrcmodelpom.xmlsrcpersistencepom.xmlsrcwebpom.xmlsrcNous reviendrons un peu plus tard sur ce dernier projet afin d’expliquer le pourquoi dece fichier “features.xml” et son utilité dans le context Karaf.Le pom parent1Le modelLe model ressemble beaucoup à l’exemple utilisé dans la partie précédente (Part 1). Nousallons cependant revenir sur quelques points :L’Activator n’est pas un élément indispensable d’une application pour Karaf … donc nousallons nous en passer.Cela va permettre de simplifier au passage le pom.xml qui ne contiendra plus que leslignes suivantes :1

Nous définissons l’objet Spirit de la façon suivante :

Et l’interface de service : La persistanceLa persistance sera faite dans un premier temps dans une liste du type <ArrayList>. Nousverrons dans une prochaine étape comment apporter une persistance plus intéressante etsurtout plus … persistante. Pour le moment, nous allons implémenter notre interface dela façon suivante :

1De cette façon nous avons une liste d’entités sur laquelle faire une insertion basiqueet une recherche par type de spiritueux. Il nous reste à remplir le pom.xml avec lesinfos suivantes :1Maintenant il nous faut exposer notre service aux autres bundles. Pour le faire nousavons plusieurs choix :Bundle ActivatorService déclaratifPar annotationPar fichier de déclaration Service BlueprintMa préférence ira pour cette fois vers le Blueprint. Pour utiliser cette exposition deservice, il suffit de définir dans le dossier /src/main/ressources un dossier OSGI-INF/blueprint/ et de mettre à l’intérieur un fichier XML (peut importe son nom). Et dedéfinir le service de la façon suivante :1Grâce à ces quelques lignes, nous définissons un service répondant àl’interface fr.conceptit.tuto.spout.model.SpiritService.L’interface graphique “minimaliste”Lors de cette phase nous mettrons en place une interface minimaliste à base de servlet.Mais dans une prochaine étape nous pourrons voir qu’il y a beaucoup plus intéressant etergonomique à faire. Nous utiliserons dans un premier temps le “Pax Web whiteboardextende“. Cet outil va permettre d’enregistrer les servlets et de faire le lien avec lesalias définis. Pour l’utiliser, il faudra installer la feature dans karaf :1Une fois cette feature installée, il va falloir indiquer sur quel port nous voulonsfaire travailler notre “serveur web”. Pour cela nous créons un fichier“org.ops4j.pax.web.cfg” dans le dossier %KARAF-HOME%/etc et dans ce fichier nous allonsécrire “org.osgi.service.http.port=8080”. Personnellement j’opte pour le 8080.Une fois cela fait, nous allons créer notre première Servlet qui nous permettra delister les spiritueux en cherchant par leur type. Cette Servlet va surtout nous servir àcomprendre comment se connecter service appartenant au bundle persistence.Le code de la servlet est un code “classique”, il va juste permettre de récupérer un URLdu type : http://localhost:8080/spout?type=simple afin de récupérer une page de listing

des spiritueux.1Nous remplissons notre pom.xml de la même façon qu’habituellement en utilisant le mêmeplugin que dans les autres bundles.1Il nous faut maintenant faire deux choses :Informer le bundle qu’il possède un service un peu spécial de type servlet. Cela se faitassez facilement! En effet, grâce à blueprint nous allons définir un service répondant àl’interface javax.servlet.http.HttpServlet.Et au passage nous allons récupérer l’instance du service que nous avons définiprécédemment et le lier à la servlet.Tout ceci va se faire avec un fichier xml que nous placerons comme précédemmentdans /src/main/ressources/OSGI-INF/blueprint/ et que l’on nommera comme bon vous sembleet qui contiendra les lignes suivantes :1Le tag <reference> permet de rechercher le service par l’intermédiaire de son interface.Le tag <service> est utilisé dans ce cas de façon un peu spécifique pour présenter ausystème notre servlet qui sera automatiquement récupérée par le http-whiteboard pourl’exposer.Voila notre dernier bundle terminé.Et maintenant !Et bien maintenant rendez vous dans karaf.Nous allons installer 1 feature et 3 bundles dans l’ordre suivant :http-whiteboard : features:install http-whiteboarspout-model : osgi:install mvn:fr.conceptit.tuto.spout/spout-model/1.0-SNAPSHOTspout-persistence : osgi:install -s mvn:fr.conceptit.tuto.spout/spout-persistence/1.0-SNAPSHOTspout-ui : osgi:install -s mvn:fr.conceptit.tuto.spout/spout-ui/1.0-SNAPSHOTLe résultat devrait être celui la :

Une fois les bundles installés et démarrés, il ne reste plus qu’à interroger notreservice via l’url : http://localhost:8080/spout?type=simple.

Le projet featuresNous avons un projet fonctionnel mais nous pouvons améliorer le système d’installation.Il est toujours fastidieux d’installer plusieurs bundles l’un à la suite des autres etqui plus est, avec les features et bundles qu’ils ont en dépendance. Sur une applicationcomplète, on peut facilement avoir 50 dépendances voire plus…Afin de faciliter l’installation des bundles que composent une application nous allonsutiliser les features.Pour ce faire, il faut créer un nouveau projet que l’on nommera par exemple “spout-features”. Nous allons tout d’abord créer notre fameux fichier d’installation dans ledossier “spout-features/src/main/ressources/” et nous le nommerons features.xml :1Grâce à ce fichier nous allons donner les informations suivantes :Ligne 2 : Définition du nom du groupe de features.Ligne 3 : Définition d’une feature d’installation avec nom, version et descriptionbrève.Ligne 4 : Demande d’installation d’une dépendance sous forme de feature, ici http-whiteboard qui permet de gérer les servlets.Ligne 6 à 8 : Demande d’installation de nos bundles qui vont permettre de fairefonctionner l’application.Comme nous pouvons le constater facilement la définition des bundles se fait de la mêmefaçon que lorsqu’on le fait à la main dans karaf, avec le préfixe “mvn:” suividu groupId puis de l’artifactId et pour finir la version, le tout mis entre balises<bundle/> . Dans le cas d’une dépendance sous forme de feature c’est encore plus simpleil suffit de mettre le nom de celle-ci entre les balises <feature/>.Ce fichier doit être envoyé dans votre repo maven et pour se faire nous allons définirle pom suivant qui permet de transformer les ${…} en valeur et d’envoyer le résultat aubon endroit :1Ce fichier features.xml va nous permettre d’installer notre application de la façonsuivante :

La première commande :1Elle permet d’informer karaf de l’endroit où il va pouvoir trouver le fichier contenantles features. Grâce à la précédente ligne nous allons profiter d’une autocomplétion afinde savoir quelle feature nous pouvons installer facilement.La deuxième commande :1Cette ligne va installer à proprement parlé notre feature comportant l’ensemble descomposants indispensables à notre application.

Conclusion de cette partieDans cette partie nous avons commencé à mettre en place une application un peu plusréelle que dans la partie 1. Dorénavant, les 4 modules (model, persistence, ui etfeatures) vont servir de base pour les prochaines parties.Nous avons également aperçu comment nous pouvions mettre en place une interface à basede Servlet, mais nous verrons que nous pourrons utiliser des moyens beaucoup plusefficients et puissants pour créer des interfaces de type CRUD.Le dernier élément intéressant est la création du fichier de features permettant degérer les dépendances et les bundles composants notre application. Il permet égalementde faciliter l’installation de cette dernière.

Développement OSGi pour serveur Karaf - Part 1

Ce post est le premier d’une série concernant le développement d’applications OSGi pourApache Karaf. Apache Karaf est un conteneur OSGi (basé sur Equinox ou Felix au choix).

Les caractéristiques intéressantes de Apache Karaf sont :Console type bash avec complétion (peut être étendue par chaque bundle)Console de connexion SSHDéploiement de Bundle ou Feature à partir d’une repository mavenCréation dynamique et facile d’instances filles en ligne de commandeL’ensemble de ces caractéristiques rendent l’utilisation d’un serveur d’application OSGiaussi simple que celle d’une application standalone Java. Le déploiement et la gestiondes applications dans Apache Karaf sont beaucoup plus simples et pratiques que laplupart des serveurs déjà rencontrés. En ajoutant à cela que ce serveur est relativementléger, je pense que Apache Karaf est une solution combinant la facilité de développementd’une application J2EE et d’une application standalone utilisant Spring.Outils :Java version “1.7.0_17”Eclipse 4.2.2 Juno http://www.eclipse.org/downloads/Maven 3.0.5 http://maven.apache.org/download.cgiServer Apache Karaf http://karaf.apache.org/index/community/download.htmlAllez, c’est parti !La première partie se contentera de créer le projet Eclipse contenant le minimum vital,de configurer la génération du bundle et de l’installer sur notre serveur Karaf.Partie 1 : Projet karaf-spoutPartie 1 : Projet karaf-spoutDans Eclipse créer un nouveau projet de type Maven avec les paramètres suivants :groupId : fr.conceptit.tutoartifactId : karaf-spoutversion : 0.0.1-SNAPSHOT

Partie 2 : Définition d’un ActivatorDans le dossier src/main/java :création d’un package “fr.conceptit.tuto.spout”Création d’un fichier Activator.java avec le code suivant1Cette classe permettra d’intercepter le démarrage et l’extinction de notre bundle. Celapermettra soit de monitorer soit de déclencher des actions sur des services.Partie 3 : Création du bundleDans le fichier POM.xml, nous allons définir les informations permettant de créer unbundle pour karaf :packaging doit être du type bundleNous allons ajouter une dépendance pour l’Activator:1Dans la liste de plugin a utiliser nous allons mettre maven-bundle-plugin avec lesinformations suivantes :1Une fois la configuration faite, nous allons générer le bundle avec la commandeclassique :mvn -U clean installPartie 4 : Rendez vous dans karafUne fois la précédente commande exécutée vous avez dû voir “BUILD SUCCESS” apparaître.Donc nous allons maintenant installer notre bundle dans Karaf.Pour se faire :Décompressez le zip de Apache KarafEntrez dans le dossier généré, direction le dossier “bin”Lancez le serveur avec l’exécutable “karaf”Vous obtenez un serveur lancé avec la fenêtre suivante :

Pour installer notre bundle nous n’avons qu’une ligne à saisir :1Le résultat devrait être celui la :

si nous voulons stopper et relancer ou encore désinstaller notre bundle il suffit defaire un osgi:stop / osgi:start / osgi:uninstall avec l’ID du bundle :

Partie 5 : Dynamiser son développementQuand on veut développer avec Apache Karaf, une commande peut s’avérer très pratique :1En effet, cette dernière permet de demander au serveur de surveiller la repository mavenet de mettre à jour le bundle ou les bundles lorsque ces derniers sont régénérés.Il faut savoir que, par défaut, Apache Karaf est à l’écoute de votre repository mavenlocal configuré par votre setting.xml.L’utilisation la plus simple dans le cadre de dev est de démarrer son karaf et de taperla commande :1Avec le wildcard “*”, dev:watch se met à l’écoute de tout les bundles dont l’uri secompose de mvn:* et comportent -SNAPSHOT.A chaque fois que vous ferez un mvn clean install de votre projet vous obtiendrezquelque chose du genre :1Voici un exemple de résultat :

Conclusion de cette partieCréer un projet de bundle pour karaf n’est pas plus compliqué que ça !Une configuration minimum d’Eclipse, de même pour maven et quelques lignes de commandedans le serveur Karaf suffiront à mettre en route un projet fonctionnel.Pour le moment, notre application n’est pas ce qu’on peut appeler utile ! Par la suite,nous verrons comment il est possible d’utiliser cette plateforme pour mettre en place unflow de traitement de fichiers avec framework orienté EIP, processus d’insertion en baseet reporting par l’intermédiaire de web services.Au final, mettre en place un cluster de Karaf dans le but de se rapprocher au plus prêtd’une infrastructure professionnelle, serait très pratique.