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 pouv...
● 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,...
● La couche service
o Permet de gérer la consommation et
l’exposition dynamique des services
o Le service est là / pas là ...
● 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 MA...
● La couche sécurité
o Qui a le droit d’accéder à quoi
● L’environnement d’exécution
o Chaque instance de bundle est clois...
● Articulation autour d’une spécification
o Version actuelle : OSGi release 6 (Juin
2014)
o Version SCL : OSGi release 5 (...
● Implémentations Apache d’OSGi
o Core : principe de base (lifecycle,
environnement d’execution)
o Compendium : service st...
● Peut être le contenant ou le contenu d’un
autre contexte d’exécution
o Chez SCL : instancié par une webapp
(portal, back...
● Fait parti du projet Felix Apache
● Facilite la gestion de la modularité OSGi
● Diminue drastiquement la “boiler plate”
...
● Rend l’exposition et la consommation de
service beaucoup plus simple
La soupe technologique : iPOJO
Expose un service
Co...
● 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 instan...
● 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 te...
● 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 gr...
● 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 versio...
● Problèmes rencontrés
o Pas de gestion réellement dynamique
o Rechargement à chaud souvent impossible
o Mauvaise gestion ...
● Autres problèmes
o Remontée des erreurs aléatoire et peu parlant
o Gestion du publish/subscribe via un bundle
non-system...
La migration
● Anticiper la migration Spring 4
● Profiter des retex pour améliorer
o Un véritable rechargement à chaud
o Un mécanisme d...
● 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 ave...
Questions ?
Prochain SlideShare
Chargement dans…5
×

Le nouveau portail

474 vues

Publié le

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

Publié dans : Logiciels
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
474
Sur SlideShare
0
Issues des intégrations
0
Intégrations
8
Actions
Partages
0
Téléchargements
6
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Le nouveau portail

  1. 1. Le nouveau Portail OSGi + Vaadin + Felix + iPojo
  2. 2. ● La soupe technologique ● Le portail : plate-forme d’entreprise ● L’existant ● La migration Le nouveau Portail
  3. 3. La soupe technologique
  4. 4. ● Une vieille idée o Consortium fondée en 1999 La soupe technologique : OSGi
  5. 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. 6. ● Une architecture en couche La soupe technologique : OSGi
  7. 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. 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. 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. 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. 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. 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. 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. 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. 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. 16. ● Rend l’exposition et la consommation de service beaucoup plus simple La soupe technologique : iPOJO Expose un service Consomme un service
  17. 17. ● Permet de se brancher sur le lifecycle simplement par callback La soupe technologique : iPOJO
  18. 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. 19. ● Gestion des event par callback La soupe technologique : iPOJO
  20. 20. ● Modification du byte code à la compilation La soupe technologique : iPOJO
  21. 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. 22. ● Nombreux add-ons fournis par la communauté La soupe technologique : Vaadin
  23. 23. Le portail : plate-forme d’entreprise
  24. 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. 25. ● Un contenant dans lequel on déploie les applications Le portail : plate-forme d’entreprise
  26. 26. L’existant
  27. 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. 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. 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. 30. La migration
  31. 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. 32. ● Mise en place de bundle system issue du projet Apache Felix La migration Avant MIGRATION !!!!! Après
  33. 33. ● Mise en place du bus d’event natif La migration
  34. 34. ● Plus aucune logique d’héritage pour créer un module et des vues La migration
  35. 35. ● Plus aucune logique d’héritage pour créer un module et des vues La migration
  36. 36. ● Instanciation des modules via un fichier de config ● Création des vues via un fichier de config La migration
  37. 37. ● Gestion des logs par un service OSGi La migration
  38. 38. ● Une ligne de commande pour simplifier le debugage et mieux appréhender l’environnement La migration
  39. 39. ● Une ligne de commande pour simplifier le debugage et mieux appréhender l’environnement La migration
  40. 40. ● Une ligne de commande pour simplifier le debugage et mieux appréhender l’environnement La migration
  41. 41. La migration
  42. 42. La migration
  43. 43. La migration
  44. 44. La migration
  45. 45. La migration
  46. 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. 47. Questions ?

×