Comme promis dans mon dernier article concernant une introduction à YAKOLIV Gen Tool assistant, nous allons parcourir les dossiers générés par l'outil. Commençons par rappeler l'ensemble des dossiers générés. On peut les lister sur l'image ci-dessous:
1- Le dossier Config
Son contenu est le suivant:
Ce fichier xml contient la configuration du mapping objet-relationnel entre la classe java 'org.yakoliv.exple.Country' et la table 'Country'.
Dans l'article Exemple simple d'utilisation de Yakoliv Framework, je vous avais présenté son contenu que je ne rappellerai plus ici.
Ce dossier contient aussi les fichiers suivants:
Leurs contenus sont statiques et varient très peu, ceux d'entre vous ayant une espérience avec ibatis n'auront même pas à s'en occuper, sauf s'ils veulent être curieux.
Le contenu du fichier SqlMapConfig.xml est le suivant:
Et comme vous pouvez le constater à la lecture du contenu de la balise <transactionManager>, ce fichier a besoin d'informations venant d'ailleurs. Ces informations sont recherchées dans le fichier SqlMapConfig.properties dont voici le contenu:
C'est très facile de voir que ce fichier attend des informations pour être complet, tout développeur concerné par cet article devrait savoir quoi faire en le lisant.
Le dossier Config ayant été présenté, passons au dossier SQL
2- Le dossier SQL
Il contient en général les codes SQL de création des tables concernées par le présent projet. Pour ce qui est de ce projet, il ne s'agit que du code de la table 'Country' comme nous pouvons le voir sur la figure ci-dessous:
Le contenu de ce fichier est le suivant:
Il s'agit pour cette table d'un exemple simple de code de création de table. Intéressons nous maintenant au dossier 'Contract'
3- Le dossier Contract
Il s'agit de l'ensemble des éléments dont les clients de vos web services auront besoin pour accéder aux services distants. Il s'agit comme le nom l'indique du contrat entre le serveur et le client distants. Pour ce cas précis, il contient deux arborescences:
- Contract\java\org\yakoliv\exple\wsrv\itf
- Contract\java\org\yakoliv\cxf
Commençons par la première arborescence. Le contenu du dossier itf est le suivant:
Le fichier ICountryWSrv.java contient les méthodes nécessaires à la manipulation de la table Country, celles qui seront utilisées pour communiquer avec les services déployés. Son contenu est le suivant:
L'on peut choisir de supprimer des méthodes ou d'en ajouter, cela dépend des besoins. La plupart des méthodes présentes ici sont celles connues dans l'article Exemple simple d'utilisation de Yakoliv Framework et qui étaient alors présentées dans le cadre des services simples d'accès aux données.
Passons à présent au contenu du dossier cxf
Il contiendra toujours un fichier, le fichier de configuration de cxf pour les accès distants. Il portera le nom cxf-client.xml
Le contenu du dossier cxf est le suivant:
Le contenu de ce fichier décrit la façon dont votre client communiquera avec le serveur, où le trouver, comment communiquer avec lui, etc.
Explorons ce fichier xml:
Les habitués de CXF devraient en rire car il est plus que simple. Continuons notre périple, non sans remarquer l'apparition dans ce fichier des éléments configurés dans le fichier xml de description du projet yakoliv. Explorons maintenant le dossier ext-lib.
4- Le dossier ext-lib
Il contient des librairies auxilliaires pour les accès aux données et pour la communication client-serveur. Il est constitué de deux arborescences:
- ext-lib\server
Il contient le fichier mbouop.jar qui sera utilisé côté serveur pour accéder aux données. C'est en fait l'adaptateur de DAO, la DAO Générique.
-ext-lib\client
Il contient le fichier serviceFinder.jar qui sera utilisé côté client pour initialiser les modules (clients de web services).
C'est tout pour le dossier 'ext-lib', passons au dossier 'Simple Services'.
5- Le dossier Simple Services
Il contient des classes et interfaces permettant d'utiliser la DAO générique pour accéder à la base de données. Il est constitué des arborescences ci-dessous:
- Le sous-dossier itf:
Il contient les différentes interfaces d'accès à la DAO Générique. Dans notre cas, il s'agit du fichier ICountrySSrv présenté dans l'article Exemple simple d'utilisation de Yakoliv Framework
- Le sous-dossier impl:
Il contient les différentes classes d'implémentation des interfaces sus-cités.
Dans notre cas, il s'agit du fichier CountrySSrvImpl ci-dessous:
Son contenu est le suivant:
6- Le dossier Web Services
Il contient les classes d'implémentation des interfaces du contrat présenté plus haut. Dans notre cas, son contenu est le suivant:
Le fichier CountryWSImpl contient l'implémentation de l'interface ICountryWSrv présenté dans le dossier Contract ci-dessus.
Son contenu est le suivant:
Le code est relativement simple, rien de nouveau pour toute personne ayant lu l'article Exemple simple d'utilisation de Yakoliv Framework
La notion de proxy dans le code ci-dessus renvoie à la programmation orientée aspect. Yakoliv contient parmi ses modules une entité qui définit des proxy dynamiques pour les logs essentiellement (pour ce qui est du built-in behaviour).
Intéressons nous actuellement au dossier Web-Inf-Files.
7- Le dossier Web-Inf-Files
Il contient les fichiers de configuration des services web, de CXF et autres. Son contenu est le suivant:
Le fichier web.xml a un contenu classique connu de tout développeur ayant flirté avec la programmation web en java. Son contenu est le suivant, il peut être édité si besoin est:
Le fichier Logic-beans.xml est le fichier contenant les descriptions des classes métier, celles qui contiennent l'implémentation des services à exposer. Dans notre cas, son contenu est le suivant:
Le fichier beans.xml contient la configuration de CXF. Son contenu est le suivant:
ça saute aux yeux à ce niveau que nos webservices ne sont pas sécurisés, mais nous verrons comment le faire dans mes futures publications. Yakoliv génère ces configurations de la sécurité, mais je les ai supprimées dans un but de démonstration, en vue de mettre en exergue la notion de sécurité dans les services web générés.
Ouf! Enfin c'est terminé pour ce billet. Dans le prochain article, nous verrons comment exploiter ces fichiers pour construire notre programme client/serveur et le tester.