Choix techniques de développement

Développement de l’interface

Pour faire un projet d'une telle envergure, c'est la technologie OpenLaszlo qui est utilisée. A partir d'un code écrit en XML pour l’interface et JavaScript pour les méthodes, cet applicatif permet de générer un contenu Flash ou DHTML (depuis le 20 mars 2007) à partir d'un même code source. L'avantage de ce produit est, qu'il est écrit en Java/TomCat ce qui le rend multiplateforme.
L'inconvénient majeur de cette solution est le temps de compilation qui requière environ 20 secondes avant d'afficher la page. Cependant, un fois configuré en mode production, ce temps est réduit à 1 seconde et demie grâce à son système de cache intégré.
Open Laszlo possède deux modes de déploiement, SOLO et Serveur (J2EE).
Le mode Solo est en réalité une application flash embarquée (un fichier SWF)
Le mode Serveur utilise un serveur TomCat 5.5. Ce second mode est adapté pour utiliser des web services. Nous utiliserons ce mode pour déployer l'application car nous ferons appel à un Web Service pour accéder aux données.

Stockage des données

Pour le stockage des données des futurs clients (agenda, carnet d'adresse...), le Système de Gestion de Base de Données retenu est PostgreSQL car il est multiplateforme très léger et rapide. De plus, en ce moment SGBD a le vent en poupe. Robuste et stable, il permet d'exécuter des requêtes complexes et de gérer les procédures stockées. Pour ce qui est du stockage des documents du client (Document Word, Excel ou photo...), ils seront placés sur le disque dur du serveur et transférés en utilisant le couple PHP/Apache.

Développement du web service

Pour interagir entre Openlaszlo et notre base de données, nous utiliserons le protocole SOAP. Celui-ci permettra d'étendre les fonctionnalités du bureau distant. Par exemple, il est prévu pour la suite de créer une synchronisation des données entre l'agenda située sur Internet et le Pocket PC de l'utilisateur ou tout simplement synchroniser le répertoire de document local avec un répertoire distant à chaque fermeture de session.

Après de longues recherches, PHP à montrer une certaine souplesse d'utilisation sur ce protocole, notamment dans la version 5. Mais il me restait toujours un problème à résoudre, générer un fichier WSDL servant à référencer toutes les fonctions et variables du projet. Pour chaque nouvelle fonction intégrée, il faut insérer 10 lignes de code dans ce fichier en respectant la norme Internet du W3C.
Je suis resté bloqué un moment sur cette étape, car le respect de la norme W3C est difficile à mettre en œuvre mais indispensable pour rendre une application SOAP opérationnelle et utilisable par n'importe quel autre langage tel que le Python ou le Pascal Object (Delphi). C'est à ce moment que j'ai trouvé une petite librairie sur un site dont l'auteur est inconnu et dont le code source ne possède pas de licence: http://www.jool.nl/new/1,webservice_helper.html
Celle-ci se nomme WSHelper et permet à partir d'un code PHP Object de générer automatique le service SOAP ainsi que son précieux fichier WSDL.

Les logiciels utilisés pour tester et développer l'application

Pour rédiger le code OpenLaszlo, le seul éditeur fiable muni d’une très bonne coloration syntaxique ainsi que d'un débuggeur intégré est Eclipse. Cet éditeur test le code en direct, il indique toutes les erreurs de compilation rencontrées au fur et a mesure du développement. Il est donc incontournable.

Pour le développement des scripts PHP, j'ai utilisé mon logiciel, le Tipiweb PHP Editor. Celui-ci intègre une coloration syntaxique similaire au PHP-Editor de la société Zend ainsi qu'un outil de débogage des scripts PHP et un serveur Web Embarqué.

Pour effectuer des essais, plusieurs navigateurs Internet ont été utilisés. Parmi eux, les principaux ont été FireFox, Opéra et Internet Explorer 7. Il s'est avéré qu'en utilisant le mode application « Flash », le bureau à distance avait la même apparence d'un navigateur à l'autre. Cependant, en mode application DHTML, Firefox posait quelques problèmes pour l'affichage : certains boutons devenaient inutilisables et certaines images n'apparaissaient pas correctement. Sous Internet Explorer, aucun problème, de plus, celui-ci s'est avéré plus rapide sur le chargement de l'application.

En ce qui concerne le système d'exploitation, la création a été effectuée sur deux plateformes différentes, Windows Xp et Ubuntu Linux Edgy. J'ai remarqué que les temps de compilations sur la même machine étaient beaucoup plus rapides sous Linux que sous Windows. Cela vient sans-doute du serveur TomCat qui semble beaucoup plus réactif sur l’environnement Open-Source.