Plusieurs signes me font penser qu’il n’est pas simple de définir ce qu’est Eclipse Scout. Lors du premier Stammtisch Eclipse à Zurich (qui était plutôt un DemoCamp, mais passons), la présentation donnée n’a pas forcément réussi à expliquer ce qu’était Eclipse Scout… Le forum d’Eclipse Scout commence à être animé avec des questions de personnes qui souhaitent en savoir plus.
La définition que l’on trouve est la suivante:
« Eclipse Scout est un framework moderne et ouvert qui permet de réaliser facilement des applications métiers orientés services« . Mais qu’y a t’il dernière cette définition?
Eclipse Scout propose en fait de nombreuses choses… Certaines sont spécifiques, pratiquement inventées pour Eclipse Scout, mais pour une grande majorité, il s’agit de la mise en place de bonnes pratiques, d’utiliser ou de raccorder au framework d’autres briques logicielles.
Voici quelqu’un des points qui me semblent importants :
La cible des développeurs
Tout d’abord, il me semble important de replacer Eclipse Scout dans le contexte. Il a été créé pour les besoins d’une entreprise (BSI Business Systems Integration AG) pour accélérer le développement de ses applications. Eclipse Scout peut donc intéresser les développeurs qui auraient des problématiques proches (applications d’entreprise, client-serveur, appuyées sur une base de données, avec un client installé sur le bureau…).
Une partie Outil (SDK) et une partie runtime (RT)
La partie runtime apporte un ensemble de composants réutilisables. Ces éléments vont faciliter le travail du développeur en effectuant un certain nombre de choix pour lui : la partie interface utilisateur est modélisée à travers un ensemble limité d’éléments graphique (voir ci-après). La partie sécurité est prévue pour reposer sur JAAS (Java Authentication and Authorization Service). La partie Runtime ajoute un système de Service Registery qui va permettre d’avoir une architecture orientée services. Un système de tunnel entre le client et le serveur est mis en place, de telle sorte que le développeur n’a plus à s’en préoccuper pour les tâches simples. Le modèle de l’interface utilisateur est conçu pour travailler avec ses propres objets de transfert de données…
Toute cette partie Runtime est ouverte… Qui voudra utiliser d’autres éléments peut le faire. Par exemple si les objets de transfert de données doivent reposer sur JPA… Cela est possible, car rien n’est caché. L’objectif d’Eclipse Scout est d’être suffisamment modulaire pour que cela soit possible.
La partie SDK ajoute à Eclipse des outils qui accélèrent l’écriture du code. Ces outils sont principalement regroupés dans une perspective supplémentaire qui vient s’ajouter dans l’IDE Eclipse. Ces outils sont de différents types : il y a une vue Explorateur qui va représenter l’application. De nombreux assistants permettent l’ajout de code (nouveau formulaire, ajouter un élément, …). Une vue propriétés permet de configurer les différents éléments.
La partie SDK n’est en aucun cas une obligation. Il s’agit d’un bon d’un complément à la partie runtime, car le code généré l’utilise. Cependant il est aussi possible d’écrire son code Java à la main sans utiliser la perspective Eclipse Scout. D’ailleurs ce changement est possible à tout instant… Les outils du SDK se synchronisent avec le code Java (qui est à tout instant la seule référence, il n’y a pas d’autres fichiers de configuration ou de cache…). Ainsi une modification à l’aide des outils du SDK modifie le code Java, et une modification du code Java « à la main » dans l’éditeur Java se reporte dans les vues de la perspective Scout. Cela permet d’effectuer les modifications d’une manière ou d’une autre, en fonction de ses habitudes ou de son niveau d’expérience d’utilisation d’Eclipse et de connaissance d’Eclipse Scout (les débutants préfèreront utiliser les outils de la perspective, les utilisateurs confirmés d’Eclipse préférerons garder leurs raccourcis pour éditer le code Java).
Côté client : utilisation d’un modèle indépendant des bibliothèques graphiques
L’interface utilisateur est définie par un modèle simple de composants réutilisables… Ces composants définissent l’interface utilisateur. Ils sont indépendants de toutes bibliothèques graphiques (SWT, Swing…), permettant ainsi de se concentrer sur le code métier. Le développeur d’application Eclipse Scout n’a pas à écrire le code correspondant à l’interface graphique. Il peut se concentrer sur le modèle correspondant à la manipulation de ses données.
Ce modèle du client influence également les objets de transfert de données qui vont servir entre le client et le serveur. Ces objets de transfert de données sont presque identiques au modèle du client, mais débarrassés de la partie propre au client. Ils sont connus du client et du serveur (où s’effectue la persistance des données).
Ce modèle est extensible. Il est possible de le compléter par des composants au niveau du modèle ainsi qu’au niveau des moteurs de rendu.
Avoir un modèle indépendant des bibliothèques graphiques permet de réaliser du single-sourcing avec un code permettant d’être rendu de différentes manières. Eclipse Scout est livré avec un moteur de rendu fonctionnant avec la bibliothèque graphique SWT et un autre avec Swing. Un moteur de rendu sous forme d’application web est en préparation (en utilisant la bibliothèque graphique Eclipse RAP).
Construire son application à travers des clics
Cet aspect n’est pas souvent évoqué, mais construire une application Eclipse Scout consiste à cliquer dans la perspective Eclipse. La courbe d’apprentissage se trouve ainsi grandement accélérée. Cette approche existe depuis longtemps, mais l’avantage d’Eclipse Scout réside dans le fait que le code produit est du java lisible et modifiable… Bien souvent ces approches génèrent des fichiers illisibles et non modifiables… ici tout est transparent, le code Java fait foi.
Par exemple, ajouter un nouveau service s’effectue à travers un assistant. Le code est généré au bon endroit : une interface dans le plug-in shared (partagé entre le client et le serveur), une classe qui implémente l’interface côté serveur, des ajouts dans les fichiers plugin.xml du client et du serveur…
Au final l’application obtenue respecte une architecture classique… On ne perdra pas un développeur expérimenté. Cette architecture laisse de l’espace et peu servir de socle à des développements supplémentaires.
Eclipse Scout exploite les briques logicielles qui existent déjà , et les adapte pour qu’elles profitent au framework (et ainsi à toutes les applications créées avec ce framework).
En savoir plus
* Ma page Developpez.com consacrée à Eclipse Scout
* Premiers pas avec Eclipse Scout – Tutorial pas à pas de création d’une application Eclipse Scout
* Site officiel : www.eclipse.org/scout