Avantages et Lourdeurs de l’intégration

Le client/Serveur façon 4D c’est simple. Simple à développer, simple à déployer, simple à maintenir. Secret de la simplicité : l’intégration des technologies et la cohérence entre client et serveur.

Mais toute médaille a son revers : chaque mise à jour de 4D Server doit s’accompagner d’une mise à jour de 4D Client. Chaque mise à jour de 4D Client requiert une mise à niveau équivalente de 4D Server. C’est ce qui explique que certaines applications demeurent “coincés” dans des versions anciennes, les clients n’étant pas prêts à renouveler leur parc pour être compatible avec les pré-requis des versions récentes de 4D (abandonner un vieux parc de Mac en PowerPC par exemple).

Et pourtant, pendant ce temps, les demandes d’évolutions fonctionnelles continuent d’affluer vers l’équipe de développement, en particulier l’exigence de portage de certains modules fonctionnels sur le Web. Dans le cas d’un logiciel vertical, si la concurrence le propose déjà, délicat de ne pas suivre…

La demande de Terenui

Exemple concret, comment répondre à la demande d’un partenaire de longue date, la société Terenui, représentée par son dirigeant Christophe Heuberger, lorsqu’il vient me demander de réaliser un module Web de Planification de blocs pour son progiciel Grimoires qui fonctionne en 4D 2004 ?

- copie d’écran du module final dans un navigateur Web (noms floutés) -

Une solution basée sur le Web 2.0 Pack ne convient pas car elle contraint au même couplage fort entre le client (même Web) et le serveur. Pour tirer parti de la dernière version du Web 2.0 Pack, il faut la dernière version de 4D. Réciproque, si la version correspondante du Web 2.0 Pack n’est pas disponible, la migration dans vers la dernière version de 4D n’est pas possible. Trop contraignant.

Le choix se réduit à une solution basée sur de l’HTML + Ajax ou une technologie requérant un plugin comme Adobe Flex ou Microsoft Silverlight. Comme cette demande s’est produite fin 2009, l’aspect graphique du module demandé orientait plus vers une solution basée sur Flex que sur de l’HTML 4. 

Le choix était donc fait, ce serait un module Flex.

De l’intérêt du découplage de version

Le développement d’un module de ce type présente l’avantage  de retirer le découplage entre client et serveur, aucun lien n’existant entre la version de Flex et la version de 4D. Nous venons d’effectuer la mise à jour en Flex 4, la partie 4D demeurant encore en version 2004, quoique la version compatible v12 ne soit plus très loin.  

Autre découplage, la maintenance évolutive s’est effectuée avec Flex 3, pendant environ un an, sans poser de problème de compatibilité avec la version du Runtime en l’occurrence le Flash Player. Autrement dit, l’évolution du Runtime n’impose pas systématiquement d’évolution de l’outil de développement, c’est également un facteur de souplesse.

Communication client/serveur

Le choix d’XML sur HTTP offre davantage de contrôle que le recours à SOAP, plus adapté lors de la recherche d’une interopérabilité qui ne nous intéresse pas ici puisque nous maîtrisons à la fois le client et le serveur. 

Le client Flex envoie donc une requête HTTP vers le server Web de 4D qui répond en retournant une structure XML comme le montre la copie d’écran ci-dessous.

- échanges entre Flex et 4D en XML -

Le principe n’est pas nouveau puisque le schéma suivant, qui date d’une Note Technique de … 2006, illustre encore parfaitement la communication entre le client RIA et le serveur 4D :

Il suffit de remplacer Flash 8 par Flex 3 et la photo du mobile de l’époque (un iPaq HP) par un périphérique plus récent. (Vous pouvez trouver la Note Technique “Réaliser un client Flash pour PocketPC” sur le site développez.com).

D’un point de vue technique, la programmation est extrêmement aisée puisque 4D propose de nombreuses commandes XML (spécialement dans le thème DOM), tandis que Flex de son côté convertit automatiquement la structure XML en un objet ActionScript directement utilisable. Si l’on prend l’exemple de la structure XML de configuration retournée dans la copie d’écran vue plus haut, l’expression “lastResult.config.appName” retourne la valeur “Hôpital du bois joli” qu’il suffit de lier (binding) à un composant d’affichage, ici un Label.

Collaboration dév. 4D/dév. Flex

Comme tout progiciel vertical, Grimoires est le résultat d’un développement constant, durant plusieurs années, ajoutant de manière itérative de nouvelles fonctionnalités. Introduire dans l’équipe de développement un nouveau collaborateur pose toujours plusieurs problèmes :

- comment le rendre opérationnel sans nécessiter de coûteuses semaines de présentation de l’application ?

- comment délimiter ses interventions pour ne pas mettre en péril l’existant ?

L’approche retenue consiste à délimiter les responsabilités en s’entendant sur un contrat de communication : l’API du service proposé par le serveur. L’équipe 4D+Flex détermine le nom des requêtes, leurs structures, matérialise cette structure sous la forme d’un fichier statique dont on vérifie la syntaxe dans un outil dédié.

La première implémentation consiste, sur réception de la requête par 4D, à renvoyer ce fichier statique. Une fois cette modification effectuée (et dans 4D c’est vraiment très rapide), le développement côté Flex peut commencer en construisant le service de données et le stockage local. Pendant ce temps, en parallèle, le développement continue côté 4D en construisant les traitements réels de la requête.

La mise au point s’effectue sur les trois composantes :

• dans le débogueur de 4D côté serveur
• dans le débogueur de Flex (Eclipse) côté client
• dans Firebug pour le contenu des échanges entre client et serveur

Le développement ainsi très outillé garantit une bonne productivité.

Nouveau module

Flex permet des architectures très souples basées sur un découpage en composants réutilisables. Un composant expose des propriétés, des méthodes et des événements propres. La notion d’événements en particulier est très importante car c’est elle qui permet de conserver un découplage entre les différents composants.

Il est ainsi possible de rajouter de nouveaux modules fonctionnels au fur et à mesure. L’écran ci-dessous, rajoutée sans avoir été prévu initialement, se compose par exemple de plusieurs composants. 

- copie d’écran du module de planification des lits (noms floutés) -

Bilan ?

Il ne faut pas sous-estimer la productivité du développement 4D : il est difficile de trouver un autre environnement de développement permettant aussi rapidement de rajouter de nouvelles fonctions et de les tester. Le développement Web, en l’occurrence ici avec Adobe Flex, est significativement plus lent. Il impose donc une plus meilleure anticipation. Il requiert également une meilleure architecture de départ afin de garantir son évolutivité.

Une fois maîtrisée la routine de communication entre 4D et Flex, il devient cependant très efficace de coupler les deux technologies, l’une pouvant évoluer indépendamment de l’autre. Nous venons ainsi de migrer la partie cliente en Flex 4 sans avoir modifié la partie client/serveur. Dans les prochaines semaines, ce sera au tour de la partie client/Serveur de passer en v12 sans modification du client Flex.

La clé du succès réside dans la bonne collaboration entre les équipes afin que chacune puisse se concentrer sur ses tâches et son savoir-faire…