Présentation du framework jSeduite pour les JM2L. L’équipe MODALIS du laboratoire CNRS / I3S s’interesse à la définition de modèles pour les architectures largement distribuées. Dans le cadre de nos recherches sur les Architectures Orientées Services (SOA), nous avons mis en place (en partenariat avec l’Institut d’Education Sensoriel Clément Ader, établissement scolaire niçois accueillant de jeunes handicapés) une architecture orientée services permettant de diffuser des informations en milieu scolaire : menu de la cantine, Horaire de bus, Albums Photos, Vidéos, ... Le framework ainsi créé (jSeduite, publié sous licence LGPL) est déployé sur le site de l’EPU Polytech’Nice - Sophia Antipolis ainsi qu’à l’IES. Nous nous proposons d’illustrer le fonctionnement d’une SOA sur cet exemple. Comment le Web 2.0, de par sa nature participative, nous permet de mettre en place un système de diffusion d’information libre relié aux principaux acteurs du marché (Google, Yahoo, Twitter, ...) ? Comment intégrer la multitude d’information existantes sur la toile dans le système ? Comment techniquement déployer une architecture orientée service sans être débordé ? Quelles solutions ’libres’ peuvent supporter une telle infrastructure ? Comment manipuler les informations récupérées pour les diffuser efficacement aux utilisateurs ? C’est à ces questions que nous tenterons de répondre en décrivant l’architecture ainsi que la mise en oeuvre du 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. 2

5. LE WEB 2.0, UN WEB ... PARTICIPATIF !

6. UN FRAMEWORK EST NÉ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 EST UNE
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)
Pas vraiment «métier» !!
Cache
Provider
PartnersKey
15

19. VERSION NAÏVE (IRL)
Pas vraiment «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. MISE EN OEUVRE
(IMPLÉMENTATION)
19

28. AVERTISSEMENT:
ZONE « DÉVELOPPEUR »
20

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 (JAVA JAX-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. WEB SERVICE :
HYPER_MACHIN_SERVICE
25

34. MISE EN OEUVRE :
ORCHESTRATIONS
26

35. BPEL : «BUSINESS PROCESS
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. CODE XML D’UNE
ORCHESTRATION...
28

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. PRINCIPES D’AFFICHAGE
Provider
35

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 CE PATTERN
• 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. RÉSULTAT : WEBADMIN
43

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
DE SYSTÈ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ÉES SERVICES
• 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 VOTRE ATTENTION !
http://www.jseduite.org