Description de la migration d'un portail d'entreprise maison réalisé au sein de la société Santéclair de la version 1.0 basée sur OSGi (Felix) + Vaadin + Gemini vers une archi OSGi (Felix) + Vaadin + iPOJO

1. Le nouveau Portail
OSGi + Vaadin + Felix + iPojo

2. ● La soupe technologique
● Le portail : plate-forme d’entreprise
● L’existant
● La migration
Le nouveau Portail

3. La soupe technologique

4. ● Une vieille idée
o Consortium fondée en 1999
La soupe technologique : OSGi

5. ● 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

6. ● Une architecture en couche
La soupe technologique : OSGi

7. ● 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

8. ● 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

9. ● 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

10. ● 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

11. ● 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

12. ● 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

13. ● 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

14. ● 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

15. ● 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

16. ● Rend l’exposition et la consommation de
service beaucoup plus simple
La soupe technologique : iPOJO
Expose un service
Consomme un service

17. ● Permet de se brancher sur le lifecycle simplement par
callback
La soupe technologique : iPOJO

18. ● 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

19. ● Gestion des event par callback
La soupe technologique : iPOJO

20. ● Modification du byte code à la compilation
La soupe technologique : iPOJO

21. ● 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

22. ● Nombreux add-ons fournis par la
communauté
La soupe technologique : Vaadin

23. Le portail : plate-forme d’entreprise

24. ● 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

25. ● Un contenant dans lequel on déploie les
applications
Le portail : plate-forme d’entreprise

26. L’existant

27. ● Objectif initial : proposé une alternative
crédible à Notes
● Basé sur Felix, Vaadin, Spring et Gemini
● Première version faites un week-end
L’existant

28. ● 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

29. ● 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

30. La migration

31. ● 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

32. ● Mise en place de bundle system issue du projet
Apache Felix
La migration
Avant
MIGRATION !!!!!
Après

33. ● Mise en place du bus d’event natif
La migration

34. ● Plus aucune logique d’héritage pour créer un module et
des vues
La migration

35. ● Plus aucune logique d’héritage pour créer un module et
des vues
La migration

36. ● Instanciation des modules via un fichier de config
● Création des vues via un fichier de config
La migration

37. ● Gestion des logs par un service OSGi
La migration

38. ● Une ligne de commande pour simplifier le debugage et
mieux appréhender l’environnement
La migration

39. ● Une ligne de commande pour simplifier le debugage et
mieux appréhender l’environnement
La migration

40. ● Une ligne de commande pour simplifier le debugage et
mieux appréhender l’environnement
La migration

41. La migration

42. La migration

43. La migration

44. La migration

45. La migration

46. ● 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

47. Questions ?