Comparaison WebDev et J2EE : langage et gestion des sources de données

Le monde J2EE est souvent jugé complexe mais cette complexité apparente n’est que la réponse nécessaire aux problématiques réelles des SI. De son côté WebDev propose une solution aguicheuse pour le développement mais tient-il la comparaison ?

Dans un billet précédents je déclarais que la cible de WebDev n’était pas la même que J2EE. WebDev semble s’adresser à une population d’informatiien et surtout de non informaticien pour développer des applications de gestion CRAD (portemanteau de CDRUD et de RAD). Après quelques semaines passé à manipuler WebDev voici mes conclusions.

Du point de vue du développeur (rôle développeur en J2EE), le langage WLangage n’est pas Objet. On est trop souvent amené à appeler des fonctions qui ne sont pas des méthodes d’objet ni de classe. Ce sont bel et bien des fonctions. Le paradigme de programmation du WLangage (langage propriétaire utilisé par WebDev) est donc bancal. Se voulant objet, puisque l’on peu faire des objets, il n’impose malheusement pas ce modèle. Si le lecteur doute de la pertinence de l’objet en matière de génie logiciel, je ne peux que lui conseiller de mettre à jour ses connaissances.

Certaines fonctions sont elles-mêmes bancales dans leur signature. Ainsi le fonction qui test si une chaine commence par une autre est bien nommée ChaîneCommencePar mais ne retourne pas un booléen mais un entier…. Donc le développeur passe d’un niveau d’abstration fonctionnel avec des fonction dont le nom est significatif à un autre, celui d’un test en langage C….

Une fois l’application développé vient le temps du déploiement. Comme on veut comparer WebDev et J2EE, nous sommes dans le contexte d’un SI d’entreprise voire d’un éditeur, avec des environnements de test, de preé-production et de production. Là où J2EE permet de découpler le code de l’application des paramètres de l’environnement comme les sources de données qui sont du ressort de l’administrateur (rôle déployeur en J2EE). Ainsi le mème livrable pourra être déployé en test ou en production, le code étant totalement agnostique de l’environnement, Quelle solution propose WebDev ?

La notion de connexion nommée est interne à l’IDE qui confond allègrement nom de connexion et nom de variable dans le but de simplification à outrance. Ainsi une connexion définie dans l’IDE est référencé par son nom en tant que variable et nom pas en temps que chaine. Les connexions semblent devoir être définies lors du développement. WebDev inscite donc à repasser par l’AGL et déclarer les connexions spécifiques à l’environnement cibles puis recompiler et redéployer l’application. Une fois dployée l’application est alors scotchée à sa source de donnée…. WebDev ne fait donc pas de découplage entre application et source de données!

Néanmoins on peut par programmation construire une connexion et l’affecter aux tables (appelées Fichiers) du programme. Cette méthode est celle préconisée par le support pour rendre l’application multi-cible. Finalement c’est un développeur si il a un minimum de compétence en génie logiciel, de prévoir ce qui est du ressort de la technique et donc contraire à la cible première de WebDev. Par ailleur le support propose une solution hasardeuse de détecter l’environnement en fonction de l’IP du serveur… sous-entendant que le code doit tester si il est en test ou en prod. WebDev est donc a proscrire pour les éditeurs qui devraient connaitre l’IP de tous les serveurs de ses clients!

Une première solution pourtant existe et aurait dû être proposée par le support. Lors du déploiement l’AGL propose d’inclure des fichiers supplémentaires. Il suffit d’ajouter un fichier de type INI qui contient la définition de la connexion pour l’instance en train d’être déployée. Par programmation, l’application lors de son initialisation va lire ce fichier et créer la connexion puis surcharger la connexion de l’analyse. Cependant, cette méthode oblige toute modification des sources de données de se faire soit en redéployant soit en allant modifier le fichier INI sur le serveur. On peut aller plus loin en incluant un fichier (Table) d’initialisation qui contiendrait les valeurs de connexions aux tables métiers et un module d’administration pour modifier la table de paramétrage… Dommage que WebDev ne propose pas cela dans son modèle, ce qui lui aurait permis de soutenir la comparaison avec J2EE.

Derrière un marketing singulier dans le monde des éditeurs, WebDev est un AGL qui ressemble plus à une boîte à outils pour assembler rapidement des applications focalisées sur l’apparence. Certes, on développe vite des IHM mais le modèle applicatif n’est pas celui attendu par des SI d’entrepise et encore moins celui de professionnelles de l’informatique comme les éditeurs. Définitivement, a moins de s’adjoindre les services d’un spécialiste en architecture ou génie logiciel, l’utilisation de WebDev n’est pas adaptée à un SI d’entreprise avec des contraintes autres que celles du médecin qui veut développer un IHM sur son fichier de patients.

Base Geneweb sur Cdrom

Logo of GeneWeb
Image via Wikipedia

Geneweb est un logiciel de généalogie libre qui fonctionne sur Linux, MacOS X et Windows. Ecrit en OCamel à l’INRIA, geneweb se présente sous la forme d’une application web. Cela a l’avantage de permettre l’accès à la base de données généalogiques à de nombreuses personnes aussi bien en lecture qu’écriture.

Cependant on peut avoir envie de diffuser la base sous forme de cdrom. C’est le cas quand l’accès au réseau n’est pas possible ou que l’on souhaite archiver une version autonome de la base. La documentation de geneweb présente les manipulations à effectuer afin générer une arborescence que l’on peut ensuite graver sur un Cdrom. Si ces explications constituent une base dans l’automatisation de la tâche de création d’image ISO d’une base geneweb, ce billet explique comment arriver au but final sous Ubuntu 11.04.

En premier lieu, la manipulation consistant à compacter la base en faisant un export au format gw puis un import est à proscrire. En effet selon les cas (configuration de la base ou typologie de celle-ci comme la présence de branche), cette opération risque d’enlever des personnes dans la base. Nous recommandons donc de ne pas effectuer ces optimisations sauf si l’utilisateur en a l’habitude.

La suite des opérations est conforme à la documentation. Nous allons copier la base ainsi que les executables mais aussi mettre en place un autorun pour plateforme windows. Ainsi la base généalogique est distribuable auprès de tous les membres de votre famille même ceux qui ne sont pas (encore) passés dans la lumière du libre !

L’ensemble des opération est heureusement automatisable et nous proposons ici le script bash suivant qui va jusqu’à créer l’ISO. Attention l’exécutable gwd.exe pour Windows doit être mis à dans le répertoire à côté du script !

#!/bin/bash
#-----------------------------------------------
# generate cdrom iso ready to burn from geneweb
#-----------------------------------------------

# check if destination argument is present
if [ $# -ne 2 ]
then
  echo "Usage: $0 base destination"
  echo "base is the name of the base"
  echo "destination is the destination to write the cdrom tree where"
  exit 1
else
  BASE_NAME=$1
  DEST_DIR=$2
fi
# remove existing destination files
if [ -e $DEST_DIR ]
then
  rm -R $DEST_DIR
fi

#create destination
mkdir -p $DEST_DIR

# copy geneweb database
cp -R /var/lib/geneweb/$BASE_NAME.gwb $DEST_DIR/$BASE_NAME.gwb

# copy config file
cp /var/lib/geneweb/$BASE_NAME.gwf $DEST_DIR/

# copy lang, etc, images from /usr/share/geneweb
cp -R /usr/share/geneweb/lang $DEST_DIR/
cp -R /usr/share/geneweb/etc $DEST_DIR/
cp -R /usr/share/geneweb/images $DEST_DIR/

# copy images from /var/lib/geneweb
cp -R /var/lib/geneweb/images $DEST_DIR/

# copy Linux executable
mkdir $DEST_DIR/Linux
cp `which gwd` $DEST_DIR/Linux/

# create gwd.arg for Linux
echo "-wd" >> $DEST_DIR/Linux/gwd.arg
echo "/tmp/geneweb" >> $DEST_DIR/Linux/gwd.arg
echo "-hd" >> $DEST_DIR/Linux/gwd.arg
echo "../" >> $DEST_DIR/Linux/gwd.arg
echo "-bd" >> $DEST_DIR/Linux/gwd.arg
echo "../" >> $DEST_DIR/Linux/gwd.arg
echo "-dd" >> $DEST_DIR/Linux/gwd.arg
echo "../" >> $DEST_DIR/Linux/gwd.arg

# copy Windows executable
mkdir $DEST_DIR/Windows
cp gwd.exe $DEST_DIR/Windows/

# create gwd.arg for Windows
echo "-wd" >> $DEST_DIR/Windows/gwd.arg
echo "c:tempgeneweb" >> $DEST_DIR/Windows/gwd.arg
echo "-hd" >> $DEST_DIR/Windows/gwd.arg
echo "..\" >> $DEST_DIR/Windows/gwd.arg
echo "-bd" >> $DEST_DIR/Windows/gwd.arg
echo "..\" >> $DEST_DIR/Windows/gwd.arg
echo "-dd" >> $DEST_DIR/Windows/gwd.arg
echo "..\" >> $DEST_DIR/Windows/gwd.arg

# create a launcher for Windows
echo "call "cmd /c start ./Windows/gwd.exe"" >> $DEST_DIR/run.bat
echo "@start "" /b "C:\Program Files\Internet Explorer\iexplore.exe" //localhost:2317/$BASE_NAME" >> $DEST_DIR/run.bat

# create autorun for Windows
echo "[Autorun]" >> $DEST_DIR/autorun.inf
echo "open=run.bat" >> $DEST_DIR/autorun.inf    #create an iso
mkisofs -V "Geneweb $BASE_NAME" -o $BASE_NAME.iso -J $DEST_DIR

Ce script a été testé sous Ubuntu 11.04. L’ISO obtenue montée sur Windows XP sous VirtualBox (simulatiion d’une gravue et insertion physique). Une fois le cdrom introduit, un navigateur s’ouvre automatiquemen sur la page d’accueil de la base contenue dans le cdrom.

Accès Oracle natif avec WebDev

L.’AGL WebDev propose moyennant finance d’accéder nativement à une base Oracle. On entend par nativement le fait de na pas passer par ODBC ou OLE DB. L’application WebDev se connecte directement à Oracle.

Outre le gain de performence dû à l’absence de couche intermédiaire, PCSOFT indique que par l’utilisation de l’accès natif, le code de l’application ne nécessite pas de changement en cas de changement pour un autre base de donnée. Cela est étrange car d’un point de vue conceptuel, c’est justement interface commune indépendante de l’implémentation qui permet de ne pas changer le code utilisateur quand on change l’implémentation. En réalité l’interface commune semble être le WLangage et le RAD. Dans d’autres univers cette interface commune s’appelle par exemple JDBC… et le fournisseur de l’implémentation de l’interface c’est le fournisseur de la base de données.

Quoi qu’il en soit, PCSOFT vend un connecteur natif Oracle. L’installation du contenu du cdrom contenu dans la boîte jaune se fait sans encombre et WebDev propose ensuite le type de connexion Accès Natif Oracle pour WebDev dans le paramétrage des connexions.

Comme l’architecture est étrange pour ne pas dire antipattern puisque Oraccle ne fournit pas de driver pour la couche d’abstraction (inexistante car API propriétaire) de WebDev obligeant PCSOFT à fournir (vendre) un connecteur, l’installation de la boîte jaune ne suffit pas.

En effet la documentation indique que l’installation de la couche cliente Oracle est nécessaire. Pour cela il faut aller sur le site web d’Oracle pour télécharger Instant Client. La version Basic est suffisante. Il s’agit d’une archive dont l’installation consiste à rendre accessible les librairies qu’elle contient pour tout le système. Sous Windows, il faut alors mettre à jour la variable PATH.

Pour créer une connexion il faut ouvrir l’éditeur d’analyse puis aller dans le menu Analyse > Connexions …. Cliquer sur le bouton + pour ajouter une connexion. Dans l’onglet propriété voici les champs à remplir:

  • Nom : le nom qui sera utilisé comme variable dans le code WLangage
  • Connexion pas : choisir Accès natif Oracle pour WebDev
  • Source de donnée : c’est l’url de connexion de la forme serveur:port/base où le port peut être omis si c’est celui par défaut 1521

Retour d’expérience sur WebDev 16

WedDev se présente comme un RAD professionnel permettant de développer 10 fois plus vite. Le marketing est très aguicheur mais que se cache-t-il vraiment derrière ? Une première réponse est apportée par ce billet que nous allons complété avec des exemples précis qui aideront le lecteur dans son choix (ou sûrement son non choix).

  • plantage de l’éditeur
  • droit avec le groupware ne marche pas sur tous les champs
  • la fonction de création automatique des tables ne marche pas toujours
  • mémoire insuffisante pour compiler un petit projet
  • plantage du centre de contrôle HyperFileSQL
  • HyperFileSQL est privateur de liberté

Plantage de l’IDE

Le problème se rencontre dès le début de l’utilisation du manuel d’auto-formation. L’éditeur propose la complétion et l’aide à la saisie des paramètre de procédures. Lors de la saisie dans l’éditeur de la procédure milieu, une saisie des paramètres provoque un crash de l’IDE. Nous avons reporté ce bug reproductible sur plusieurs machines auprès du support de PCSoft.

D’autre cas de plantage sont survenus au fil de l’utilisation dans d’autres parties de l’AGL, provoquant un crash de WebDev.

Limitation du groupeware

Alors que le manuel et la documentation en ligne indiquent que les champs des pages peuvent être limités à certains groupes d’utilisateurs du groupeware,  malheureusement après de nombreux essais, nous nous apercevons que cela ne fonctionne pas sur tous les champs mais seulement sur le menu, les boutons et les images ! Le support, réactif, nous à alors indiqué que l’aide en ligne allait être mise à jour. Cela illustre l’adage it is not a bug it is a feature

Un contournement est toutefois possible. Il suffit de modifier pour chaque page les propriétés des champs ou groupe de champs en fonction du groupe de l’utilisateur connecté.

Fonctionnement capricieux de la création automatique

Quand on utilise HyperFileSQL, on est étonné de ne pas trouver comment générer le script de création de la base. En effet de nombreux dialectes de SQL sont supportés mais pas celui de HyperFileSQL. Notons que l’utilisation du SQL standard ANSI 92 n’a pas fonctionné dans mon cas à cause d’une rubrique (colonne) de type BIT…

En fait il ne faut pas chercher à générer de script de création de table pour HyperfileSQL. Dans les propriétés du projet l’option de génération des fichiers (tables) au premier accès est activé par défaut. Donc lors du déroulement du programme (navigation sur le site web) les fichiers sont créés au besoin. Cette fonctionnalité ne marche pas toujours. D’un coup plus aucune table n’était créée.

La solution consiste à générer manuellement par WLangage le schéma de la base en début d’application.

Gourmandise mémoire

WebDev est occupe 2 Go sur le disque et l’IDE est un gros consommateur de mémoire vivre. Ainsi sur un poste disposant de 4 Go de ram, la compilation d’un projet de 10 tables et 40 écrans a échoué sur le message mémoire insuffisante.

Contraintes de HyperFileSQL

La base de données propriétaires de WebDev est présentée comme gratuite et installable partout. De plus un accès ODBC est disponible pour les applications tierces i.e. non WebDev. Cette offre est séduisante mais que vaut-elle réellement ?

Si la base est gratuite elle n’est pas au sens de la FSF un application libre. L’éditeur ne propose pas de façon libre l’accès au pilote ODBC. Ce dernier est installable si on installe l’AGL ou déploie une application WinDev mais il n’est pas téléchargeable séparément sans passer par l’achat d’une licence webdev. Finalement la base HyperfileSQL doit n’être vue que comme un moyen de persistance maison redistribuable sans royalties dans les applications développées par l’AGL. De plus l’accès ODBC est uniquement en lecture pour les applications non windev selon le support technique. Ainsi ne comptez pas brancher un ETL sur une base HyperfileSQL en écriture par exemple….

Paramétrage Squid pour Jabber local

Squid (software)
Image via Wikipedia

Nous avons vu hier comment mettre en place un serveur Jabber personnel. Si cela fonctionne parfaitement pour les clients sur internet i.e. à l’extérieur du réseau local, les clients locaux doivent comme c’est souvent le cas passer par un proxy (ex: control parental). Un paramétrage de ce dernier est alors nécessaire.

Le proxy utilisé est Squid. Il est configuré comme proxy pour tout le système mais non transparent. L’accès à Jabber depuis le réseau local nécessite donc soit un réglage du proxy. soit que le client Jabber outrepasse le réglage proxy. Sous Ubuntu 11.04 cette dernière méthode est possible avec Pigdin mais pas avec Empathy qui est le client de messagerie instantané officiel.

Nous allons voir comment dire à Squid d’autoriser les accès au serveur Jabber local. Dans les fichier /etc/squid3/squid.conf on déclare une acl pour le port Jabber:


acl JABBER_PORT port 5222

Comme on veut limiter les accès à un serveur jabber particulier on doit également déclarer une acl pour cette destination. Dans le billet précédent le serveur jabber est désigne par jabber.acme.com, d’où:


acl JABBER_SERVER dstdomain jabber.acme.com

Maintenant il suffit d’autoriser les accès vers ce serveur via ce port

http_access allow JABBER_SERVER JABBER_PORT

Enfin redémarrer le proxy pour charger la nouvelle configuration:


sudo service squid3 restart

Serveur de messagerie instannée personnel

This is the Jabber light bulb.
Image via Wikipedia

Dans un billet précédent, Serveur mail personnel, nous avons vu comment disposer de son propre serveur de messagerie. Cela nous permet d’être autonome et de ne pas dépendre de son FAI ou d’un fournisseur de messagerie tel que google gmail. Nous allons maintenant mettre en place une serveur de messagerie instantanée qui pourra être utilisé à la fois sur le réseau local et internet.

Le choix du serveur met en lice le protocol IRC et Jabber. Notre choix se porte sur Jabber pour son l’extensibilité. Nous allons maintenant détailler l’installation de Jabber.

Dans Ubuntu 11.04 jabber est présent dans le dépôt officiel. Nous portons notre choix sur la dernière version: la branche 2 de jabber. Dans la liste des paquets il faut sélectionner jabber2. Une fois l’installation effectuée, nous allons paramétrer jabber. Cela consiste à:

  1. créer la base de données dans laquelle jabber stocke les messages et les informations sur les utilisateurs
  2. spécifier la connexion à la base de données
  3. ouvrir le mécanisme de création de compte

Nous utilisons MySQL comme base de données. Il faut commencer par créer la base (schéma) disons jabberd2. Pour cela il suffit de lancer un script distribué avec Jabber.

cd /usr/share/doc/jabberd2

Dans Ubuntu le sript est compressé, on va l’extraire:

gunzip db-setup.mysql

Puis on execute le scrip en faisant:

mysql -u root -p
mysql> . db-setup.mysql

Puis il faut créer l’utilisateur jabberd2. Pour cela nous utiliser MySQL Administrator qui permet de faire cette tâche via une IHM. Dans l’onglet Privilèges il faut donner à l’utilisateur jabberd2 les droits sur le schema jabberd2. Il a besoin de faire des INSERT, SELECT, UPDATE,DELETE.

Nous allons maintenant indiquer à Jabber de se connecter à la base MySQL ainsi préparée.

Pour le stockage des messages, dans le fichier /etc/jabberd2/sm.xml vérifier que le nœud xml /storage/driver vaut bien mysql. Dans ce même fichier aller dans le noeux xml /mysql/pass pour indiquer le mot de passer qui a été choisi pour l’utilisateur jabberd2.

Pour l’authentification, dans le fichier /et/jabberd2/c2s.xml il faut faire les même manipulations que pour sm.xml.

Le serveur jabber est maintenant bien connecté à la base de données. Il nous reste à lui donner une identité qui lui permet d’être reconnu sur internet. Pour cela nous devons indiquer dans le fichier /etc/jabberd2/sm.xml spécifier l’id du serveur dans le noeux xml /sm/id. Par exemple si le serveur est accéssible par le nom jabber.acme.com, il faudra mettre cette valeur comme identifiant. Ainsi les utilisateurs gérés par ce serveur auront des identifiants de la forme toto@jabber.acme.com.

Nous allons maintenant activer la création de compte pour le public. Cette section n’est utile que si on souhaite permettre la création de compte depuis un client jabber. Dans le fichier /etc/jabberd2/c2s.xml il faut également indiquer l’identifiant du serveur dans le noeud xml /c2s/local/id vaut bien

 <id register-enable='true'>jabber.acme.com</id>

Et que la création de compte est bien autorisé au niveau du backend de base de données

<authreg>
    <!-- Dynamic authreg modules path -->
    <path>/usr/lib/jabberd2</path>

    <!-- Backend module to use -->
    <module>mysql</module>
    <register>
      <enable/>
    </register>

Une dernière étape consiste à ouvrir le pare-feu ou rediriger les ports utilisés par Jabber vers la machine hôte cachée derrière la box du FAI. Pour cela il faut ouvrir les ports suivants : 5222, 5223 et 5269.

Il suffit maintenant de relancer le service:

sudo service jabberd2 restart

et d’utiliser un client Jabber pour créer son propre compte.