Développement OSGi pour serveur Karaf

Développement OSGi pour serveur Karaf – Part 3
Dans la partie 2, nous avons commencer à mettre en place une application de
vente/échange de spiritueux et de vins qui va nous servir de support le la suite des
opé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à vu
mieux! C’est pourquoi nous allons, dans cette partie, mettre en place une solution de
type base de données. Personnellement en ce moment, j’aime beaucoup les base de données
de type document , mais pour les besoin de l’exemple je vais utiliser une base de
données “classique” du genre Oracle, mySQL, postgres, derby, hsql et consorts.
La source de données
Lorsque dans un serveur J2EE classique nous utiliserions un connecteur JNDI pour se
coupler à 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 de
blueprint encore une fois. La définition du DataSource va se faire par la création d’un
bean implémentant l’interface “javax.sql.DataSource “corespondant à la base de données
que vous souhaitez attaquer. Puis une fois ce bean créer, nous exposerons un service
répondant à l’interface “javax.sql.DataSource” et référençant notre bean et lui donnant
un 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 leurs
dépendances – et cela vaut aussi pour le drivers de base de données – et qu’il faudra
donc installer le drivers dans karaf. Afin de vous laisser le choix des armes voici une
liste des dépendances utilisables pour quelques bases couramment rencontrées :
Base de
données
DB2
DERBY
H2
HSQL
MYSQL
Installation des dépendances dans Karaf
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”
install -s mvn:org.apache.derby/derby/10.10.1.1
install -s mvn:com.h2database/h2/1.3.170
install -s mvn:org.hsqldb/hsqldb/2.2.9
install -s mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.staxapi-1.2/2.2.0install -s mvn:mysql/mysql-connector-java/5.1.24
ORACLE 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.jdbc4
Plus tard, nous utiliserons les facilités offertes par le fichier features.xml qui
permettera de faciliter la “mise en production”.
L’installation de la dépendance pour H2 se fera donc de la façon suivante :
1
Une fois le driver de base de données installé, il nous faut créer notre service
permettant d’interagir avec la base. Comme nous l’avons vue dans la partie précédente
créer un service n’est pas chose compliquée et pour preuve voici le code pour notre
service de base de données :
1
Une fois ce fichier XML défini nous avons en notre possession une data source définie
par les critères suivant :
Base de données : H2
Nom de base : cellar_bd
User : john
Password : doe
Nom d’exposition du service d’accès : jdbc/cellar_bd
Maintenant la question est simple: comment l’utiliser ? JDBC ou JPA ? Avec quel
framework OpenJPA, Hibernate ou autres ? Les possibilités sont assez variées, certaines
trè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 avec
la base utilisant JDBC.
Dans la partie 2, nous avions défini une classe SpiritServiceImpl dans le bundle
persistence. Cette classe possédait une ArrayList en guise d’élément de persistance ; Le
but 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 les
opérations sur la liste de spirit par un objet de type DAO que j’appellerai sans
surprise … SpiritService.
1
Remarque : Ce DAO vérifie à sa création si la table CELLAR existe, dans le cas
contraire le DAO crée cette table. Au passage, on pousse quelques informations dedans
afin de vérifier le bon fonctionnement de notre application. Si vous souhaitez vérifier
que la base est bien créée et bien peuplée vous pouvez vous connecter à la base avec un
logiciel tel que l’excellent SQuirreL.
L’utilisation de cette DAO à partir de notre service passera par une injection utilisant
la capacité IOC de blueprint. Nous modifierons le fichier persistence.xml pour
construire le DAO et le pousser vers le service. Au passage, un va injecter la
DataSource dans le DAO :
1
Le Service s’en trouve simplifié :
1
Installation facile
Au début de ce post, nous avons vu que pour utiliser notre base de données il fallait
installer le driver sur karaf. C’est rapide, facile mais le développeur peut encore
faciliter la manipulation au client final. Pour ça on retourne sur notre fichier
features.xml dans le projet spout-feature afin d’ajouter tout simplement le driver ou
tout autre dépendance nécessaire.
1
Et 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 CRUD
simpliste qui peuvent être facilités par tout ORM qui se respecte. C’est pourquoi la
prochaine 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 nous
utiliserons une des facilitées liée à karaf … l’extension de shell.
Lecture - "Enterprise Games" de Michael HUGOS aux éditions O'REILLY
J’ai commencé un livre qui m’a été conseillé, ENTERPRISE GAMES : Using Game Mechanics to
Build a Better Business. Ce livre est une étude sur le management de projet et comment
améliorer la conduite de projet avec des techniques modernes de jeux. On ne parle pas
ici de jeux dans le monde du travail (serious gaming) ni de jeux à des fins
commerciales, même si cette étude ne serait pas complète sans passer un minimum dessus.
On l’entend quand même citer Ian BOGOST – “Gamification is Bullshit”.
Dilbert – http://www.dilbert.com/2013-05-19/ de Scott ADAMS
Michael HUGOS – l’homme derrière la plume
Michael HUGOS est l’auteur de ce livre. Il a travaillé comme directeur des systèmes
d’information avec plusieurs (parfois gros) clients pour trouver des solutions élégantes
à des problèmes complexes. Pour ses travaux il a remporté plusieurs prix comme le CIO
100 Award, le InformationWeek 500 Award et le Premier 100 Award. Il a écrit des articles
pour un magazine “Doing Business in Real Time”. Il est l’auteur de 7 livres dont le
populaire “Essentials of Supply Chain Management”.
Enterprise Games: Using Game Mechanics to Build a Better Business – couverture
Sa vision du jeu (dans le monde du travail)
Le monde progresse et le travail progresse en même temps. Les technologies entrent dans
la vie active. Michael HUGOS pense qu’ignorer ces changements et les possibilités qui
vont avec, sont autant d’opportunités ratées et d’avantages laissés aux adversaires.
Michael HUGOS s’inspire des jeux actuels, notamment des MMORPG et a identifié 4 piliers
qui sont applicables dans le management des systèmes d’information. Il réfute les
systèmes comme le travail à la chaîne et le cloisonnement des informations de la société
qu’il juge dépassés et encombrants. Les nouveaux médias qui sont apparus, les progrès en
télécommunications, l’accès à internet plus répandu sont autant d’outils et de points
clefs qui nous obligent à revoir notre façon de travailler. Et pour ceux qui ne le font
pas, la concurrence le fera. Il est temps de sauter à bord, le train est déjà en marche.
les 4 pilliers
Michael HUGOS nous présente tout au long de son ouvrage 4 piliers pour améliorer le
workflow d’un projet. Ces 4 piliers sont les fondements des jeux (en general).
the Goals – les objectifs
Les objectifs doivent être définis. Il est important que tous les membres du projet
sachent ce qu’on leur demande et sur quels critères on évalue le succès du projet. De
plus compléter ces objectifs doit être positif, améliorer l’entreprise et améliorer leur
quotidien. Il faut impliquer les employés.
the Rules – les règles
Les règles sont les outils et méthodes utilisables pour réaliser et atteindre les
objectifs. Il ne faut pas hésiter à voir large. Il est important de laisser de la marge
de manoeuvre aux employés et de leur donner un maximum de visibilité et de pouvoir pour
accomplir leurs objectifs. Les employés seront plus concernés et plus motivés.
the Feedback – le retour d’informations
Le feedback est sans doute le point le plus important de ces 4 piliers. Ce point découle
de l’avancée des nouvelles technologies et les moyens de communication moderne. En
effet, avec les smartphones et les progrès d’internet, beaucoup de gens sont en
connexion permanente. Un accès au feedback, en temps réel, partout et pour tous est la
clef de la responsabilisation des employés et de la confiance qu’on leur apporte. Le
feedback doit présenter à tous les employés : où ils en sont par rapport au objectifs,
où en est le projet en général par rapport aux objectifs, où en sont les autres par
rapport aux objectifs. Dans son livre, Michael HUGOS parle de faire passer l’employé de
simple engrenage à membre de l’équipe à part entière.
the Participation – la participation
Enfin, le dernier pilier présenté par Michael HUGOS, la participation doit être
volontaire. Une participation obligatoire va à l’encontre de la responsabilisation et de
la prise d’importance de l’employé. Si votre nouveau système est vraiment meilleur, les
gens migreront d’eux même sans réticences. Sinon, leur critiques seront votre feedback
pour proposer mieux.
Pourquoi lire ce livre ?
Le constat de l’évolution de l’entreprise et de notre société est grave et des solutions
commencent à émerger. Même si la vision de Michael HUGOS ne vous convient pas, la
réflexion sur l’état des choses est important et un exemple des solutions à venir est
intéressant à observer. Selon Michael HUGOS, les entreprises sont de moins en moins
attachées à leur employés. Il en découle que les employés sont de moins en moins
attachés à leur entreprise. Si les employés ne sont pas mieux valorisés, ils seront sous
productifs ou partiront vers des entreprises qui leur feront plus confiance. Au travers
d’exemples et de réflexions personnelles sur ses projets, Enterprise Games, présente une
voie d’avenir qu’on aurait tort de se priver d’explorer.