Conception d’un client Eclipse RCP et serveur OSGI avec Spring DM [step0]

Il y a 3 ans j’ai créé le projet GestCV, une application WEB de gestion de CV basé sur Spring, Hibernate, Struts1.x et AJAX. A cette époque je souhaitais utiliser et mettre en évidence toutes les technologies que j’adorais dans un véritable projet.

Aujourd’hui j’ai décidé de me former au développement d’applications Eclipse RCP basé sur les API SWT et JFace que j’ai découvert à travers le développement du plugin Eclipse Akrogen, du projet TK-UI et JFace DOM Databinding. Eclipse RCP me séduit de plus en plus pour les raisons suivantes. Avec Pascal Leclercq nous avons créé ce mois-ci le projet DynaResume OSGI GestCV qui est une version RCP de GestCV (le projet est en phase d’étude). Plus exactement ce projet est basé sur une architecture client/serveur, autrement dit :

• la couche serveur fournira les services utiles pour la gestion de CV (édition d’un CV, création d’un CV).et sera basée sur OSGI via Spring DM. Les services feront appels à la base de données via Hibernate.
• la couche cliente sera une application Eclipse RCP qui consommera les services hébérgés sur le serveur.

Nous souhaitons utiliser OSGI dans la couche serveur pour démarrer/arrêter à chaud les services sans devoir redémarrer le serveur (très utile en développement comme en production). OSGI fournit d’autres avantages que je tenterais d’expliquer tout au long de ces billets. Je ne sais pas si nous aboutirons ce projet mais mon but premier est de me former aux technologies OSGI, Spring DM, RCP et de les expliquer par des exemples concrets et détaillés dans des billets.

Mon idée est de rédiger des billets qui expliqueront pas à pas comment réaliser une application Eclipse RCP qui communique avec un serveur OSGI avec Spring DM. Concrètement je vais tenter d’expliquer comment développer une petite application RCP qui affiche/met à jour une liste d’utilisateurs récupérée par des services (OSGI) hébérgés sur le serveur. Je tenterais en même temps d’expliquer l’interêt d’OSGI.

Nous avons aussi envisagé d’étudier plus tard (selon notre temps) ce que peut nous fournir le futur projet Eclipse E4 (moteur CSS (qui est à l’origine celui de projet TK-UI ), Modeled Workbench, SWT Flex…) et RAP (qui d’après ce que j’ai compris permet de déployer l’application RCP en mode WEB ).

Si le sujet vous intéresse, vous pouvez accéder à la série de billets intitulée Conception d’un client Eclipse RCP et serveur OSGI avec Spring DM .

I .Application WEB vs RCP

Application WEB (client léger) ou client lourd Eclipse RCP? C’est une question que je me pose aujourd’hui. Je ne me permettrais pas de dire que les applications RCP remplaceront les applications WEB, mais je pense que ca vaut le coup de s’interesser à RCP avec l’arrivée de Eclipse E4. Les applications WEB ont pris une ampleur considérable ces dernières années et Javascript a repris une jeunesse avec AJAX qui permet de communiquer avec le serveur avec Javascript via XMLHTTPRequest. Ce dernier permet d’éviter par exemple de rafraîchir toute une page après avoir sélectionné une liste de pays qui doit rafraîchir la liste des villes associées au pays sélectionné, de fournir des fonctionnalités d’aide à la saisie (autocomplétion) qui recherche des informations d’une BD, de charger des images dont on a besoin lorsqu’un utilisateur navigue dans une carte d’une application de cartographie. De nombreux frameworks comme GWT, Struts2, RichFaces (JSF), Wicket, .. propose par défaut des composants AJAX prêts à être employé.

I-A .Richesse Interface Utilisateur

Les widgets HTML (champs texte, checkbox…) étant relativement primitives (je ne comprends pas pourquoi W3C ne propose toujours pas des widgets comme le treeview ou la grid dans la norme HTML), Javascript est utilisé pour obtenir des widgets complexes (treeview, grid…). La réalisation de tel composant est complexe, malgré les nombreux frameworks Javascript qui fournissent des widgets prêtes à être employées (Dojo, jQuery…). Développer un composant AJAX (ou uniquement Javascript) est une tâche très côuteuse, ce que je je ne m’imaginais pas avant d’avoir commencer le projet JSControlsTags, qui propose des composants AJAX d’autocompletion, treeview, swap…..Adapter un composant AJAX d’un framework Javascript pour lui ajouter des fonctionnalités manquantes est aussi très compliqué. Une interface utilisateur complexe basée sur Javascript peut souffrir de lenteur, surtout aujourd’hui avec IE6 (qui est malheureusement utilisé dans beaucoup d’institution). En terme de développement, je pense que si on vous donne le choix de développer entre Java et Javascript, le choix est vite fait (GWT permet de gérer son interface utilisateur via des widgets Java, mais son côté boîte noire m’effraie un peu).

Avec RCP les widgets sont riches car SWT (librairies de composants graphiques utilisés dans Eclipse) propose la plupart des widgets utilisés dans une application (comme le treeview (SWT Tree), les grid (SWT Table)…), il est aussi possible d’étendre la biblihothèque en Java pour bénéficier de nouvelles widgets. Nebula est un exemple de projet qui enrichit les widgets SWT.

I-B .Déclaration Interface Utilisateur

Dans une application WEB l’interface utilisateur est déclarative via HTML. La présentation (couleur de font, gras, italique…) de l’interface utilisateur peut être déleguée à une feuille de style CSS. Ces 2 solutions couplées est un véritable gain de temps pour la construction d’interfaces utilisateurs (je ne m’étais jamais rendu compte de cela avant d’avoir coder des interfaces Swing ou SWT) et il est possible d’avoir une vue d’ensemble de l’interface utilisateur en lisant le HTML.

Dans une application RCP, SWT est utilisé et la construction d’interfaces utilisateurs est très pénible (les layouts sont par exemple le truc que je déteste le plus). L’un des buts de Eclipse E4 est de simplifier le développement d’interface utilisateur et proposent un moteur CSS (voir examples CSS pour SWT (ou autres) et une solution déclarative (XWT (déclaration de son interface utilisateur via XML) , TM (déclaration de son interface utilisateur via EMF)).

I-C .Métier client

Selon l’application à développer, le métier coté client peut est très important. Dans une application WEB, si le métier coté client consiste à effectuer des validations simples (ex : contrôle de validité d’une saisie de date), Javascript peut suffire. Mais si le métier est beaucoup plus complexe, Javascript peut devenir horrible à maintenir. Il est plus judicieux de développer des services de validation coté serveur qui sont ensuite appelés via AJAX par exemple. Mais cette solution nécéssite un appel serveur.

En RCP ce problème n’existe pas, car le client est Java. Il est donc possible d’executer les services de validation coté client.

I-D .Robustesse

Dans une application WEB, il est très difficile de maîtriser le cycle de vie du client. Comment détecter par exemple que l’utilisateur ferme son navigateur WEB? Comment détecter qu’il navigue d’une page à une autre via les boutons Suivant/Précédant? Ce manque de maîtrise du cycle de vie du client peut être problématique dans l’application, car par exemple on ne peut pas avertir l’utilisateur que ses données n’ont pas été sauvegardé lors de la fermeture de son navigateur.

Avec RCP, le cycle de vie du client est maitrisée, on peut détecter par exemple que l’application se ferme et effectuer une validation selon l’état de l’interface utilisateur.

I-E .Déploiement

En terme de déploiement, une application WEB a l’avantage d’être simple car seul la mise à jour du serveur suffit pour bénéficier d’une nouvelle version de l’applicatiopn. Les client (navigateur WEB ) n’ont pas besoin de se mettre à jour. Avec une application de type client lourd, le déploiement est nécessaire (l’application cliente doit être réinstallée). J’ai entendu parler de P2 (qui remplace depuis Eclipse 3.4, l’Update Manager eclipse qui permet d’installer les plugins) qui apporterait beaucoup, mais je ne suis pas expert. C’est une piste que je souhaiterais aussi étudier.

II .Conclusion

Je pense que le choix WEB vs RCP doit s’effectuer entre robustesse, maintenance, performance de l’application (coté client) et déploiement de l’application (mais je n’ai pas encore bien étudié P2). Je pense que ca vaut le coup de s’investir aujourd’hui dans OSGI car par exemple la plupart des serveurs (JBoss, Websphere, ….) implémente OSGI du moins en interne. De plus en plus de framework WEB commence à intègrer OSGI (Wicket, Struts2). L’arrivée de Eclipse E4 va permettre aussi beaucoup de chose. Ce sont toutes ces raisons qui me donnent envie de m’investir dans RCP et OSGI. Enfin pour la partie OSGI nous avons fait le choix d’utiliser Spring DM car étant basé sur Spring, nous pouvons bénéficier de la puissance de Spring pour les autres problématiques (IOC, AOP, Spring remoting). Mais je pense qu’il ne faut pas exclure ECF et OSGI Declarative Services.

Vous pouvez lire le billet suivant [step1].