Téléchargé parSébastien Mosser
Le Framework jSeduite
Le document présente le framework jseduite qui permet la diffusion d'informations en utilisant une architecture orientée services (SOA) et des technologies Web 2.0. Il détaille la mise en œuvre de web services, d'orchestrations, et d'une interface utilisateur pour gérer ces informations dans un contexte éducatif. L'objectif est de créer un système adaptable aux besoins des établissements tout en facilitant la maintenance et l'extension des services proposés.
Le Framework jSeduite
- 1. LE FRAMEWORK JSEDUITE SOA, WEB 2.0 & DIFFUSION D’INFORMATIONS Sébastien Mosser Université de Nice - Sophia Antipolis, CNRS, I3S, Equipe Modalis http://www.jseduite.org JM2L, 27 Novembre 2009
- 2.
- 5. LE WEB 2.0,UN WEB ... PARTICIPATIF !
- 6. UN FRAMEWORK ESTNÉCESSAIRE !!
- 7. AGENDA •Une approche SOA • Mise en oeuvre : • Web Services & Orchestrations • Clients Web (Affichage / Admin) • Conclusions & Perspectives • Résultats obtenus • Communauté, Recherche
- 8. ARCHITECTURES ORIENTÉES SERVICES 7
- 9. EN (TRÈS TRÈS)BREF ... • «SOA» en 3 lignes et 20 mots: • Un «service» est une entité élémentaire • Lire un flux RSS, Interroger Picasa, Stocker des Tweets, ... • Une «processus métier» est un assemblage de services • Interroger Picasa & Flickr puis concatener les résultats • Une «architecture» est ... la somme des précédents ! 8
- 10. PROPRIÉTÉS DES SERVICES •Sans état, Indépendant • Gros Grain PartnersKey • On ne fait pas de l’objet • Interface • Explicitation d’un contrat WeatherBug • Couplage lâche • Pas d’interconnections 9
- 11. UN SERVICE EXPOSE DES OPÉRATIONS WeatherBug findCity(search) -> cities forecast(key,city) -> weather live(key,city) -> weather 10
- 12. PROCESSUS MÉTIERS ? := receive() := PartnersKey::get(‘weather’) := WeatherBug::forecast( , ) reply( w ) 11
- 13. UN PROCESSUS ESTUNE OPÉRATION DE SERVICE ProxyMétéo getMétéo(city) -> weather := receive() PartnersKey := PartnersKey::get(‘weather’) := WeatherBug::forecast( , ) reply( w ) « Partenariat » WeatherBug 12
- 14. ARCHITECTURE DE DIFFUSION D’INFORMATION? Provider getMyInfo(id) -> info* 13
- 15. VERSION NAÏVE RSS Provider TimeTable WeatherBug 14
- 16. VERSION NAÏVE Cache RSS Provider TimeTable PartnersKey WeatherBug 14
- 17. VERSION NAÏVE (IRL) Cache RSS Provider TimeTable PartnersKey WeatherBug 15
- 18. VERSION NAÏVE (IRL) Pasvraiment «métier» !! Cache Provider PartnersKey 15
- 19. VERSION NAÏVE (IRL) Pasvraiment «métier» !! Cache Provider PartnersKey Hétérogénéité des infos !! 15
- 20. IDENTIFICATION DES MÉTIERS Cache RSS CachedReader PictAlbum Provider PartnersKey WeatherProxy TimeTable WeatherBug 16
- 21. IDENTIFICATION DES MÉTIERS CachedReader PictAlbum Provider WeatherProxy 16
- 22. IDENTIFICATION DES MÉTIERS CachedReader PictAlbum Provider WeatherProxy Hétérogénéité des infos !! 16
- 23. SEDUITE 1.0 & SOURCES D’INFORMATION Cache FeedSource RSS CachedReader Provider PictSource PictAlbum PartnersKey WeatherSource WeatherProxy TTSource TimeTable WeatherBug 17
- 24. SEDUITE 1.0 & SOURCES D’INFORMATION FeedSource Provider PictSource WeatherSource TTSource 17
- 25. SEDUITE 1.0 & SOURCES D’INFORMATION FeedSource Provider PictSource WeatherSource TTSource 17
- 26. AVANTAGES DE L’ARCHITECTURE • Maintenance facilitée • Orientation métier des processus • Couche d’abstraction «Info» • Ecriture d’outils génériques • Extensibilité assurée • Facilité d’ajout de nouveaux types d’info 18
- 27.
- 28.
- 29. CHOIX TECHNOLOGIQUES • Environnement de production hétérogène • Technologie multi-plate-forme, e.g. Java • Univers SOA : Logiciels Propriétaires vs Preuve de concepts • Choix de Glassfish, Implém. de référence • Langages support stables, reconnus & outillés • (Web) Services en Java (JAX-WS), • Processus : Orchestrations BPEL • Exécution & Déploiement : Canevas JBI 21
- 30. MISE EN OEUVRE: WEB SERVICES 22
- 31. WEB SERVICES (JAVAJAX-WS) • Implémentation Java du standard Web Services • e.g., Requêtes SOAP, Contrats WSDL, Schémas XSD, ... • Les services sont des Classes Java • Avec quelques annotations supplémentaires • Les artefacts sont générés automagiquement • Contrats WSDL & Schémas XSD 23
- 32. TYPE DE DONNÉES: HYPER_EVENT 24
- 33.
- 34. MISE EN OEUVRE: ORCHESTRATIONS 26
- 35. BPEL : «BUSINESSPROCESS EXECUTION LANGUAGE» • Langage d’orchestration (XML) orienté messages • Réception & Retour de messages, Invocation de service • Manipulation des messages: affectations, boucles, ... • Standard Industriel d’assemblage de services • Maintien du couplage lâche, Bus de Services (ESB), ... 27
- 36.
- 37. VISION «GRAPHE» 29 (IDE Netbeans 6.5)
- 38. MISE EN OEUVRE: DIFFUSEUR & ADMINISTRATION 30
- 39. OBJECTIFS • Problème : Il faut «gérer» les informations !! • Diffusion d’informations : • Récupérer les informations, « skinner » le diffuseur, ... • Administration : • Rentrer les «news», configurer les différents écrans, ... • Avec des technologies simples & peu contraignantes • => On fait du Web ! 31
- 40. DIFFUSION D’INFORMATIONS CLIENT WEB /JAVASCRIPT 32
- 41. AVANTAGES WEB : SKIN == STYLE CSS !! http://.../?display=hall&tpl=polytech http://.../?display=hall&tpl=n2i 33
- 42. BOUCLES DE DIFFUSION le c le u a o p B ci rin P in ue nt Co u cle Bo 34
- 43.
- 44. PRINCIPES D’AFFICHAGE Provider GetInformations 35
- 45. PRINCIPES D’AFFICHAGE Provider GetInformations 35
- 46. PRINCIPES D’AFFICHAGE Provider GetInformations Dispatch 35
- 47. PRINCIPES D’AFFICHAGE Provider display 35
- 48. PRINCIPES D’AFFICHAGE Provider Transform display 35
- 49. PRINCIPES D’AFFICHAGE Provider Transform display 35
- 50. PRINCIPES D’AFFICHAGE Provider display 35
- 51. PRINCIPES D’AFFICHAGE Provider display Transform getScreens 35
- 52. PRINCIPES D’AFFICHAGE Provider display Transform getScreens 35
- 53. PRINCIPES D’AFFICHAGE Provider display Transform 35
- 54. PRINCIPES D’AFFICHAGE Provider display 35
- 55. PRINCIPES D’AFFICHAGE Provider GetInformations display 35
- 56. EXEMPLE DE TRANSFORMATION: FLUX RSS 36
- 57. AVANTAGES: CRÉATION DE TEMPLATES«IN A NUTSHELL» Transformations Dispatch 37
- 58. ADMINISTRATION DES INFORMATIONS 38
- 59. SOLUTION NAÏVE : ACCÈS BASE DE DONNÉES ... ... Provider ... ... ... ... Accès direct aux tables MySQL ... 39
- 60. SOLUTION NAÏVE : ACCÈS BASE DE DONNÉES ... ... Provider ... ... ... ... t ir an ? r ? ga e t nc en re m hé m o o c Accès direct aux tables MySQL ... C la XML ? SqLite ? Postgres ? Fichiers ?39
- 61. MÉTHODOLOGIE DE DÉVELOPPEMENT Provider FeedBusiness ... Diffuser les informations FeedFinder FeedCRUD Retrouver toutes Gérer le les informations stockage existantes 40
- 62. PATTERN «BUSINESS~ CRUD ~ FINDER» • Business: • Diffuse les informations utiles pour le client d’affichage • CRUD : FeedBusiness • Create, Read, Update, Delete • Finder : FeedCRUD (et explore) toutes les • Liste informations stockées 41 FeedFinder
- 63. AVANTAGES DE CEPATTERN • Maintenance facilitée • Développement cohérent • Séparation des préoccupations • Chaque service est «simple» • Interconnexion assurée • Tout est Web Services !! 42
- 64.
- 65. CONCLUSIONS 44
- 66. RÉSULTAT OBTENU: UTILISATEURS &DÉVELOPPEURS 45
- 67. POUR LES UTILISATEURS •Un système de diffusion d’information • Adapté aux milieux scolaires • Une liaison avec les outils collaboratifs Web 2.0 • Photos Picasa / Flickr, Google Calendar, ... • Une installation « définitive » avec un ./install.sh • La gestion des infos et des écrans passe ensuite par le Web • Et surtout adaptable à l’établissement • C’est à une CSS près !! 46
- 68. POUR LES DÉVELOPPEURS •Publication de 23 Web Services pour la communauté • Twitter, Picasa, News, iCal, Cache de données, Cantine, ... • Diffusion de 7 orchestrations « métier » • (Le Web manque cruellement d’exemples BPEL & SOA) • Diffusion d’un « Provider » complet • Orchestrations sources, manipulation de listes d’informations • Mise à disposition de jDisplayer et de WebAdmin • Exemple de templates, de style CSS, ... 47
- 69. PERSPECTIVES : VERS UNE«COMMUNAUTÉ» ? 48
- 70. NOUS AVONS BESOINS D’UTILISATEURS !!!!!!! • jSeduite est déployée à Polytech’Nice • Partenariat avec l’IES Clément Ader • Prise en compte du handicap en cours ... • Et peut-être bientôt chez vous ?? 49
- 71. ET AUSSI DE DÉVELOPPEURS !!!!!!! • Développement de nouvelles sources d’informations ... • Horaires des Bus, Vidéos YouTube, ... • Ou encore de nouveaux providers ... • Gestiondes pauses (informations filtrées), profils utilisateurs plus précis, ... • Voir de nouveaux interacteurs !! • Téléphone portables, PDA, Desktop, ... 50
- 72. PERSPECTIVES : «RECHERCHES » 51
- 73. IDENTIFICATION DE FRAGMENTS RÉUTILISABLES • Développement de processus métiers par composition • Définir initialement des processus métiers simples • Et utiliser des fragments pour les enrichir • Capitaliser les connaissances des architectes http://www.adore-design.org 52
- 74. EXEMPLE • Processus initial: • Récupérer toutes les informations disponibles • Fragments : • «Pas avant» + TV => pas la télé avant 16h • «Pas après» + RestoU => plus de menu après 14h • «Mélanger» + «Tronquer» + PictAlbum => photos différentes • Système final « customisé » sans avoir écrit de code !! 53
- 75. GÉNÉRATION AUTOMATIQUE DESYSTÈMES DE DIFFUSION • Permettre à l’utilisateur de définir ses informations • Menu, Alarmes, Absences, Flickr, Picasa, WeatherBug, ... • Fournir un ensemble de politiques • Pas avant, Pas après, Mélanger, Authentifier, ... • Laisser l’utilisateur «cocher» ce dont il a besoin • Et générer automagiquement l’application qu’il a spécifié 54
- 76. CONSTRUCTION AUTOMATIQUE D’ARCHITECTURE ORIENTÉESSERVICES • Métamodélisation des processus • Quel est mon métier dans la SOA ? • Quelle en est l’évolution ? • Définition de méta-outils • Composition de processus • Génération des codes associés 55
- 77. L’ÉQUIPE JSEDUITE • Team Leaders • Mireille Blay - Fornarino, Sébastien Mosser • Styles CSS & Visuels • Céline Auzias ( C.line Design ) • Etudiants ayant participé au projet : • Clémentine Delerce - Mauris, Lionel Palacin, Stéphane Martarello, Steve Colombié 56
- 78. MERCI DE VOTREATTENTION ! http://www.jseduite.org