Le nouveau portail
47
Le nouveau Portail OSGi + Vaadin + Felix + iPojo
-
Upload
cedric-gillet -
Category
Software
-
view
120 -
download
0
Transcript of Le nouveau portail
Le nouveau Portail OSGi + Vaadin + Felix + iPojo
● La soupe technologique
● Le portail : plate-forme d’entreprise
● L’existant
● La migration
Le nouveau Portail
La soupe technologique
● Une vieille idée o Consortium fondée en 1999
La soupe technologique : OSGi
● Un objectif : la modularité o Et si on pouvait déployer/installer des
briques logicielles JAVA à chaud ?
o Et si on pouvait faire coexister deux versions
d’une même implémentations ?
o Et si on pouvait consommer et exposer
dynamiquement des services ?
o Etc.
La soupe technologique : OSGi
● Une architecture en couche
La soupe technologique : OSGi
● Bundle : l’unité de base o Petit livrable se présentant sous la forme d’un JAR
o Activator : implémente BundleActivator, point d’entrée et de
sortie du bundle
o Manifest : fichier text décrivant le bundle (version,
dépendances, etc.)
La soupe technologique : OSGi
● La couche service
o Permet de gérer la consommation et
l’exposition dynamique des services
o Le service est là / pas là / sera là / doit être
là / était là mais il est parti
La soupe technologique : OSGi
● Le cycle de vie : une norme o Géré par l’API : c’est comme ça et puis c’est
tout !!!
La soupe technologique : OSGi
● La couche modules o Décrit la manière dont un bundle importe et
exporte du code
o Différent de la notion de service
o MANIFEST.MF au centre de ce mécanisme
La soupe technologique : OSGi
● La couche sécurité o Qui a le droit d’accéder à quoi
● L’environnement d’exécution o Chaque instance de bundle est cloisonnée
o Plus de contexte commun
o Configuration des imports/exports
fondamentale
La soupe technologique : OSGi
● Articulation autour d’une spécification o Version actuelle : OSGi release 6 (Juin
2014)
o Version SCL : OSGi release 5 (Juin 2012)
● Implémentation o Felix
o Equinox (Eclipse)
La soupe technologique : OSGi
● Implémentations Apache d’OSGi o Core : principe de base (lifecycle,
environnement d’execution)
o Compendium : service standardisé (log,
event, configuration, persistence, etc.)
La soupe technologique : Felix
● Peut être le contenant ou le contenu d’un
autre contexte d’exécution o Chez SCL : instancié par une webapp
(portal, backoffice-externe)
La soupe technologique : Felix
● Fait parti du projet Felix Apache
● Facilite la gestion de la modularité OSGi
● Diminue drastiquement la “boiler plate”
inhérente à OSGi
La soupe technologique : iPOJO
● Rend l’exposition et la consommation de
service beaucoup plus simple
La soupe technologique : iPOJO
Expose un service
Consomme un service
● Permet de se brancher sur le lifecycle simplement par
callback
La soupe technologique : iPOJO
● Le pattern Factory à l’honneur o Chaque composant sous entend une factory gérée
par iPOJO et dont sont issues les instances
o Possibilité de récupéré une référence de cette factory
La soupe technologique : iPOJO
● Gestion des event par callback
La soupe technologique : iPOJO
● Modification du byte code à la compilation
La soupe technologique : iPOJO
● Framework de création d’application web o Fourni un jeu de composants
o Basé sur GWT
o Développement en JAVA
La soupe technologique : Vaadin
● Nombreux add-ons fournis par la
communauté
La soupe technologique : Vaadin
Le portail : plate-forme d’entreprise
● Une stack technique partagée
● Factorisation o Authentification
o Composants graphiques / Menu
● Unicité de la charte graphique
● Cohérence ergonomique
Le portail : plate-forme d’entreprise
● Un contenant dans lequel on déploie les
applications
Le portail : plate-forme d’entreprise
L’existant
● Objectif initial : proposé une alternative
crédible à Notes
● Basé sur Felix, Vaadin, Spring et Gemini
● Première version faites un week-end
L’existant
● Problèmes rencontrés o Pas de gestion réellement dynamique
o Rechargement à chaud souvent impossible
o Mauvaise gestion des propriétés
o Pas de gestion du bus d’event
o Fichier de configuration Spring nécessaire
o Pas de migration sur Spring 4 prévu à moyen
terme
L’existant
● Autres problèmes o Remontée des erreurs aléatoire et peu parlant
o Gestion du publish/subscribe via un bundle
non-system
o Beaucoup, beaucoup de package-export à
gérer dans le felix.properties
L’existant
La migration
● Anticiper la migration Spring 4
● Profiter des retex pour améliorer
o Un véritable rechargement à chaud
o Un mécanisme d’event natif
o Une meilleure articulation View / Presenter
o Une meilleure gestion des erreurs et des log
o Une amélioration de la productivité
La migration
● Mise en place de bundle system issue du projet
Apache Felix
La migration
Avant
MIGRATION !!!!!
Après
● Mise en place du bus d’event natif
La migration
● Plus aucune logique d’héritage pour créer un module et
des vues
La migration
● Plus aucune logique d’héritage pour créer un module et
des vues
La migration
● Instanciation des modules via un fichier de config
● Création des vues via un fichier de config
La migration
● Gestion des logs par un service OSGi
La migration
● Une ligne de commande pour simplifier le debugage et
mieux appréhender l’environnement
La migration
● Une ligne de commande pour simplifier le debugage et
mieux appréhender l’environnement
La migration
● Une ligne de commande pour simplifier le debugage et
mieux appréhender l’environnement
La migration
La migration
La migration
La migration
La migration
La migration
● Et plus encore
o Installation des dépendances automatiquement
(OBR)
o Push sur le portail pour interagir directement avec
l’utilisateur
o Etc.
La migration
Questions ?
