p seduite : une approche soa de lamh/rr/2009/rr-09.01-s.mosser.pdf · architectures orientées...
TRANSCRIPT
LABORATOIRE
INFORMATIQUE, SIGNAUX ET SYSTÈMESDE SOPHIA ANTIPOLIS
UMR 6070
PLATEFORME SEDUITE : UNE APPROCHESOA DE LA
DIFFUSION D’ INFORMATIONS
Clémentine DELERCE-MAURIS, Lionel PALACIN, Stéphane MARTARELLO, SébastienMOSSER, Mireille BLAY-FORNARINO
Equipe MODALIS
Rapport de rechercheISRN I3S/RR–2009-01–FR
Février 2009
Laboratoire d’Informatique de Signaux et Systèmes de Sophia Antipolis - UNSA-CNRS2000, rte.des Lucioles – Les Algorithmes – Bât Euclide B – B.P. 121 – 06903 Sophia-Antipolis Cedex – France
Tél.: 33 (0)4 92 94 27 01 – Fax: 33 (0)4 92 94 28 98 – www.i3s.unice.frUMR6070
RÉSUMÉ :Le projet présenté dans ce document s’inscrit dans le cadre des applications SOA (Service Oriented Architecture). Le projet
Séduite a pour but la diffusion d’information, en utilisantune architecture SOA. Nous proposons dans ce document une implé-mentation de référence de Séduite à l’aide de différentes orchestrations et Web Services. Cette application est déployée sur l’undes serveurs de Polytech’Nice et permet de valider le projetANR FAROS.
MOTS CLÉS:Architectures Orientées Services, Orchestration, Web Service
ABSTRACT:The project presented in this document is part of applications SOA (Service Oriented Architecture). The project Seduite aims
to disseminate information, using a SOA architecture. We propose in this paper a reference implementation of Seduite, usingdifferent orchestrations and Web Services. This application is deployed on a server of Polytech’Nice and will validatethe projectANR FAROS.
KEY WORDS :Services Oriented Architecture, Orchestration, Web Services
2
Remerciements
Au terme de ce projet, nous tenons à remercier très sincèrement nos deux tuteurs, Mme Mireille BLAY-FORNARINO, maître de conférence à l’EPU, et Mr. Sébastien MOSSER, thésard à l’ED STIC de l’UNSA (sur financement MESR obtenu au concours 2007), pour leur implication, leur temps, leurs conseils ainsi que leur attention.
3
Table des Matières REMERCIEMENTS .......................................................................................................................................... 2
1. INTRODUCTION ..................................................................................................................................... 4
1.1. LE CONTEXTE DU PROJET .............................................................................................................................. 4 1.1.1. Le contexte applicatif : plateforme Seduite .................................................................................. 4 1.1.2. Le contexte technique ................................................................................................................... 5
1.2. L’OBJECTIF DU PROJET ................................................................................................................................. 6
2. CONCEPTION D’UN SEDUITE SOA ........................................................................................................... 7
2.1. FONCTIONNEMENT DE SEDUITE ..................................................................................................................... 7 2.2. ANALYSE ET CONCEPTION ............................................................................................................................. 7 2.3. ANALYSE DE L’EXISTANT ............................................................................................................................... 9 2.4. POINTS‐CLEFS DE NOTRE PROJET .................................................................................................................. 10
3. MISE EN ŒUVRE : ORCHESTRATION INFOPROVIDER ............................................................................ 12
3.1. PERSONNALISATION DES INFORMATIONS ....................................................................................................... 12 3.2. RECUPERATION DES INFORMATIONS ............................................................................................................. 15
3.2.1. Continuité de service ................................................................................................................... 19 3.3. CONSTRUCTION DU RESULTAT ..................................................................................................................... 20
4. TESTS DE STABILITE ............................................................................................................................. 24
5. ORGANISATION AU SEIN DU GROUPE .................................................................................................. 28
5.1. PREMIERE PERIODE : OCTOBRE‐DECEMBRE 2008 ............................................................................................ 28 5.2. DEUXIEME PERIODE : JANVIER‐FEVRIER 2009 ................................................................................................. 28
6. DIFFICULTES RENCONTREES ................................................................................................................. 29
7. CONCLUSION ....................................................................................................................................... 30
7.1. OBJECTIFS ATTEINTS .................................................................................................................................. 30 7.2. PERSPECTIVES .......................................................................................................................................... 30 7.3. APPORTS PERSONNELS ............................................................................................................................... 30
REFERENCES ................................................................................................................................................ 31 GLOSSAIRE .................................................................................................................................................. 32 TABLES DES ILLUSTRATIONS ........................................................................................................................ 33 ANNEXES ..................................................................................................................................................... 34
4
1. Introduction
1.1. Le contexte du projet
Dans le cadre de sa thématique "Workflow expressiveness, evolution and optimization", les membres de l'équipe Modalis (Laboratoire I3S / CNRS UNSA) développent une plateforme de référence nommée "Séduite". Cette plateforme permet l'illustration des recherches menées par l'équipe dans le domaine des architectures orientées services ([MacKenzie et al., 2006], [Papazoglou and Heuvel, 2006]). Au sein du projet ANR FAROS ("Fiabilité des Architectures Orientées Services", projet exploratoire de 2005 à 2009), les membres du consortium (France Télécom R&D équipe MAPS, EDF, IRISA équipe Triskell, Alicante, INRIA Lille EPI Adam, I3S équipes Modalis & Rainbow) s'efforcent de mettre en place un procédé (basé sur des techniques d'ingénierie des modèles) permettant la construction d'application SOA fiable. La plateforme Séduite présentée dans ce document est une des plateformes cibles du procédé FAROS ([Blay-Fornarino et al., 2007a]), dont la gouvernance est donnée aux équipes de l'I3S. L'équipe Modalis travaille plus particulièrement à la définition et à l'évolution des flots utilisés à l'aide de la plateforme ADORE ([Mosser et al., 2008b], [Mosser et al., 2009]), et l'équipe Rainbow travaille aux différentes interactions entre utilisateurs et système, en utilisant la plateforme WComp ([Joffroy et al., 2007b], [Blay-Fornarino et al., 2007b]).
1.1.1. Le contexte applicatif : plateforme Seduite
La plateforme présentée dans ce rapport, nommé Seduite, vise à permettre la diffusion d’information au sein des établissements scolaires. Les informations concernées par cette diffusion sont de différentes natures :
• des données générales (ex : vacances scolaires, jour de présence de l'assistante sociale)
• des données de groupes (ex : emplois du temps, absence de professeurs) • des données personnelles (ex : courriers, convocation, agenda, notes) • des données de repérage (ex : localisation d'une personne, recherche d'un
enseignant, ...)
Dans un premier temps, l’objectif est de diffuser une partie de ces informations sur un (ou plusieurs) grand écran situé dans l’enceinte des établissements. Mais demain ces informations pourraient être diffusées sur d’autres supports plus personnels, comme un PDA ou un téléphone. En fonction du contexte d’usage, les informations reçues sont différentes. La notion de contexte inclut donc le profil de l'utilisateur (ses préférences, son handicap éventuel, ...). Ce système va être mis en place dans le hall de l’Ecole Polytechnique Universitaire de Sophia-
5
Antipolis (EPU) ainsi qu’à l’Institut Education Sensorielle Clément Ader à Nice (IES).
1.1.2. Le contexte technique
Les architectures orientées services sont utilisées pour créer des systèmes évolutifs, grâce au faible couplage présent entre les différents services mis en jeu au sein des systèmes. Les composants techniques métiers sont exposés sous la forme de services (dans notre cas, des Services Web [Newcomer, 2002]). Leurs interfaces sont clairement définies au sein d'un contrat (WSDL, [Christensen et al., 2001]), utilisé par des générateurs de code pour créer des talons (stubs) à destination des services exposés. En l'état, ces services découplés les uns des autres n'ont que peu d'intérêt. La création de processus métiers répondant aux besoins des utilisateurs passe par la définition d'Orchestrations (i.e. assemblages) de services ([Peltz, 2003]). Ces orchestrations, définies de manière séparée du code source des services (séparation des préoccupations), permettent d'ordonnancer les invocations des services métiers, de composer différents services en un seul, ... Pour les implémenter, nous utilisons le langage BPEL ([Jordan et al., 2007]). La figure 1 donne un rapide aperçu de ce type d'architecture.
Figure 1 : Architecture orientée services pour la diffusion d’informations
6
1.2. L’objectif du projet
Notre objectif est de réaliser une implémentation concrète du projet de recherche Seduite, en mettant en place une architecture orientée service (SOA). Celle-ci permettra de récupérer des informations internes à l’EPU (emploi du temps, news internes,…) ainsi que des informations extérieures accessibles par des web services ou disponibles sous forme de flux RSS (météo, horaires des bus,…). Pour implémenter cette architecture, nous avons fait le choix d’utiliser une architecture à base d’orchestrations et de Web Services. Le but étant de se rapprocher le plus possible des architectures utilisées dans le monde industriel. Le serveur d’application J2EE GlassFish a été choisi pour déployer notre solution car il fournit une implémentation de référence (Web Services, BPEL, J2EE).
Notre implémentation de la plateforme sera hébergée sur un serveur de l’EPU, anubis, et permettra de remettre en route l’écran d’affichage du hall de l’EPU, futur client de notre application, qui affichera ainsi à nouveau des informations.
Plusieurs tentatives ont déjà vu le jour. Une première version en .Net avait été mise en place à l’EPU ainsi qu’à l’IES, à Nice. Malheureusement, cette application utilisait le framework Microsoft .Net 1.0 et lors de la migration à .Net 1.1 celle-ci n’a pas survécu. L’équipe de Seduite s’est donc tournée vers une solution Java. Ainsi les problèmes de rétrocompatibilité devraient être moindres de même que les coûts de licence (solution libre disponible). Là encore, l’équipe a essuyé plusieurs échecs :
- ODE : cette solution ne disposait d’aucun outil, ce qui impliqua un développement long, fastidieux et complexe, ainsi qu’une maintenance difficile (https://odejava.dev.java.net/).
- Tomcat-Apache : de gros problèmes de fuite mémoire du serveur ont été rencontrés, rendant cette solution impossible à déployer hors cadre de prototypage (http://tomcat.apache.org/).
Notre projet consiste donc à repenser l’application, l’implémenter puis la valider. La seconde partie de ce rapport présente la conception d’une architecture orientée service. La partie 3 présente la mise en œuvre d’une orchestration appelée InfoProvider.
7
2. Conception d’un Seduite SOA
2.1. Fonctionnement de Seduite
Le rôle de Seduite est de fournir un système d’informations pour les établissements scolaires, permettant la diffusion d’informations sur différents supports. Dans le cadre de ce travail, le support de diffusion visé est un grand écran visible par tous. Les informations collectées puis affichées sur cet écran proviennent de différentes sources. Par exemple, un système de lecture de flux RSS (Really Simple Syndication) ou encore un système de news interne à l’établissement scolaire. L’application permet donc d’interroger ces différentes sources d’informations, de réunir les informations reçues et de les envoyer au client responsable de l’affichage sur l’écran. L’application permet aussi de définir des profils d’utilisateurs. Chaque utilisateur pouvant choisir quelles informations il souhaite récupérer.
2.2. Analyse et conception
En suivant cette approche nous avons défini une orchestration, nommée InfoProfider, qui permet de récupérer un ensemble d’informations venant d’une multitude de sources différentes (Flux RSS, horaires de Bus, etc.).
Vous pouvez voir sur la Figure 2 un schéma qui représente les points clefs de l’orchestration définie.
8
Figure 2 : Aperçu général de l’orchestration InfoProvider
Comme nous pouvons le constater à l’aide de la figure 2, l’architecture mise en place comporte trois phases :
1. La personnalisation :
Cette première partie permet de personnaliser les informations que l’on va récupérer. Pour un client, nous allons définir un profil, et ainsi savoir quelles sources d’informations consulter.
2. La récupération des données :
Cette partie permet de récupérer des données à partir d’un ensemble de sources hétérogène. L’ordre d’interrogation des différentes sources n’ayant aucune importance, nous avons souhaité utiliser un traitement en parallèle pour cette partie.
3. Construction du résultat :
Une fois toutes les informations récoltées auprès des différents partenaires, il nous reste à les réunir pour les transmettre au client.
L’ensemble des informations récupérées doit être exposé via un écran. Ce point là impose une contrainte assez forte, nous devons à tout prix fournir au client
9
(un écran) une réponse correcte, et donc éviter de renvoyer une erreur. Pour répondre à ce besoin nous avons pris le soin de faire un traitement des erreurs invisible au client. Le dernier point, et sans doute le plus important de cette architecture est de pouvoir permettre de rajouter assez aisément de nouvelles sources d’informations et donc de permettre une bonne extensibilité de la plateforme.
2.3. Analyse de l’existant
Lorsque nous avons débuté notre travail, nous avons commencé par étudier une orchestration nommée CachedRssReader qui permet de lire des flux RSS. Celle-ci est construite autour de trois Web Services et d’une base de données permettant un système de cache. C’est à l’aide de CachedRssReader que nous nous sommes familiarisés avec les orchestrations et c’est celle-ci qui nous a servie de première source d’information dans notre architecture. Cette orchestration se déroule comme suit :
Le client fournit un nickname. A l’aide de celui-ci l’orchestration va récupérer l’URL du flux RSS associé. L’orchestration fonctionnant avec un système de cache, elle va vérifier la validité (temporelle) des informations se trouvant dans celui-ci. Si le cache est à jour, les informations du flux RSS sont récupérées dans celui-ci et transmises au client. Si le cache n’est plus valide, l’orchestration commence par lire le flux RSS, met le cache à jour puis renvoie les informations au client.
Cette orchestration utilise trois web services lors de son déroulement :
• RssRepositoryService: Une URL étant quelque chose d’assez complexe à retenir par un utilisateur, un système de nickname a été mis en place. Ce service permet donc d’associer un nickname à une URL.
• DataCacheService: L’orchestration utilise une base de données pour gérer son système de cache, ce service sert d’interface pour utiliser la base de données.
• RssReaderService: Ce dernier service est utilisé pour lire les flux RSS.
Pour représenter cette orchestration nous utilisons le formalisme des diagrammes d’activité d’UML 2.0 (cf. Figure 3).
10
Figure 3 : Diagramme d’activité UML de CachedRssReader
2.4. Points-clefs de notre projet
Voici les points clefs résultant de la conception d’une version SOA de Seduite:
1) Personnalisation des informations : Les informations renvoyées doivent pouvoir être personnalisées, c’est-à-dire adaptées à l’utilisateur ayant fait appel à l’orchestration. Un écran, placé par exemple dans une salle réservée aux enseignants, devra afficher les emplois du temps des enseignants alors qu’un écran placé dans la cafétéria des étudiants affichera les emplois du temps des différentes promotions. 2) Traitement de l’information : L’orchestration doit appeler toutes les sources d’information de manière à récupérer les informations demandées par l’utilisateur. L’ordre n’ayant pas d’importance ici, nous traiterons ces informations en parallèle.
11
3) Stabilité du système : L’application doit supporter une utilisation sur le long terme ainsi qu’une utilisation par plusieurs clients en même temps. 4) Continuité de service : Pour assurer une continuité de service notre orchestration doit pouvoir gérer les erreurs venant des différents partenaires. Elle ne doit pas non plus propager les erreurs au client. Un système de récupération des erreurs (catch) permettra de stopper la propagation, pendant qu’un système de logs enregistrera une trace de l’erreur. Ceci permettra d’intervenir plus rapidement en cas de panne pour résoudre le problème. 5) Envoi des informations au client : Une fois toutes les informations récupérées, l’orchestration doit les rassembler, puis les transmettre au client. L’information envoyée au client doit être typée pour que celui-ci ait le moins de traitements possibles à effectuer.
12
3. Mise en œuvre : orchestration InfoProvider
Pour chaque point clef identifié précédemment nous décrivons à présent les solutions que nous proposons et précisons quand cela nous semble nécessaire leur mise en œuvre. Les traitements présentés ici sont implémentés dans l’orchestration InfoProvider.
3.1. Personnalisation des informations
Nous avons choisi de mettre en place un web service chargé de nous fournir les profils utilisateurs. Chaque profil définit les services accessibles, et les paramètres personnels pour ces services. Pour cela, les profils ainsi que leurs préférences sont enregistrés dans une base de données. Ce web service, nommé ProfileManager, récupère ces préférences et les transmet à l’application, comme le montre le schéma de la figure 4.
Figure 4 : Personnalisation des informations
Ces informations doivent bien sûr être préalablement remplies par l’utilisateur, à l’aide d’un client qui se chargera de mettre à jour la base de données. Un profil par défaut est inséré dans la base de données, avec des préférences correspondant aux besoins de la majorité des utilisateurs, par exemple, tous les bus passant devant l’arrêt de l’EPU dans les 30 prochaines minutes. Ainsi, les informations affichées par l’écran conviendront à une majorité de personnes.
13
Lorsque notre orchestration sera appelée par un client, celui-ci fournira un identifiant (récupéré grâce à un lecteur de badge par exemple dans un mode interactif ou au lancement lors d’un écran partagé). L’orchestration appellera directement le ProfileManager, web service responsable des profils utilisateurs, pour connaitre les sources auxquelles l’utilisateur s’est abonné.
Implémentation : Ce web service dispose d’une seule méthode, GetArguments, dont voici la signature: public Service [] GetArguments ( int profile) ;
Cette méthode utilise une bibliothèque, DatabaseConnection, pour se connecter à la base de données MySQL jSeduite, et récupérer ainsi tous les tuples, de la table webservice, concernant le profil passé en paramètre. Suite à cet appel, un tableau à deux dimensions, correspondant aux tuples, est renvoyé.
Exemple de tuples de la table webservice:
id serviceName methodeName args
1 InternalNews getValidNews type= ‘‘[‘‘conference’’]’’
1 CachedRssReader getFeedContent arg= ‘‘TV5_sport’’
1 CachedRssReader getFeedContent arg= ‘‘meteo_antibes’’
2 InternalNews getValidNews type=
‘‘[‘‘conference’’,‘‘evenement’’]’’
Un traitement est effectué pour organiser ces tuples afin d’avoir une liste de web services, avec pour chaque web service son nom et les méthodes demandées. Chaque méthode dispose d’un nom et d’arguments. La chaine contenue dans la colonne args est découpée pour séparer les arguments s’ils sont plusieurs, et définir si ce sont des chaines (String) ou des tableaux de chaines (String[]). On récupère ainsi une hiérarchie des données qu’on renvoie.
14
Nous pouvons voir en figure 5 ce que nous renvoie ProfileManager si on lui demande les préférences d’un profil pour un identifiant utilisateur donné :
Figure 5 : Message XML de préférences renvoyés par ProfileManager (instance)
Ici, nous devons appeler deux Web Services (InternalNews et CachedRssReader). Le premier est InternalNews et le second CachedRssReader. Nous devons appeler la méthode getValidNews de InternalNews avec comme argument conference et nous devons appeler deux fois la méthode getFeedContent de CachedRssReader : une première fois avec TV5_sport, et une deuxième fois avec meteo_antibes.
<WS> <name>InternalNews</name> <call> <name>getValidNews</name> <args> <tableau>conference</tableau> </args> </call> </WS> <WS> <name>CachedRssReader</WS> <call> <name>getFeedContent</name> <args> <chaine>TV5_sport</chaine> </args> </call>
<call> <name>getFeedContent</name> <args> <chaine>meteo_antibes</chaine> </args> </call> </WS>
15
3.2. Récupération des informations
Une phase importante de l’orchestration est la récupération des informations à partir des différentes sources que l’on a à notre disposition. Chaque source d’information est indépendante de notre application (Horaire de Bus, Météo, Résultats sportif, etc.), donc potentiellement hors de notre contrôle (ex: erreur réseau, surcharge), il est donc impossible de prédire le temps de réponse de chaque source. Dans un souci d’optimisation, nous avons opté pour une invocation en parallèle des différentes sources. Cette optimisation est bien entendu conceptuelle, il faudrait un système multiprocesseur pour permettre l’appel simultané effectif de plusieurs sources (Figure 6).
Figure 6 : Récupération des informations
Comme vu dans la phase précédente, notre plateforme permet à l’utilisateur de définir des préférences quant aux sources d’informations auxquelles il désire accéder. Il faut donc traiter ces préférences, transmises par le système de personnalisation, afin de pouvoir les exploiter, et ainsi appeler les sources d’informations concernées avec les bons paramètres (cf. Figure 7).
16
Figure 7 : Traitement des préférences utilisateur
Le but étant ensuite de collecter les résultats renvoyés par les différentes sources et de les transmettre à l’étape de construction du résultat.
Implémentation : La partie complexe de cette étape réside dans la sélection des différentes sources à contacter et des paramètres à fournir. Les sources, étant des Web Services, prennent en entrée un message XML et renvoie comme résultat un autre message XML. Pour que l’appel à la méthode du Web Service se déroule bien, le message d’entrée doit être formé. Pour construire ces différents messages, nous appliquons une transformation XSL par source, sur le message de réponse de ProfileManager. Cette transformation XSL permet d’extraire les informations de paramétrage relatives à l’appel d’une source, et de construire le message d’appel à cette source à partir de ces informations. Exemple :
Les préférences pour le client « ecran_hall » indiquent qu’il est abonné à deux sources, CachedRssReader et InternalNews. Pour la source CachedRssReader, deux appels à la méthode getFeedContent sont enregistrés avec comme paramètre « TV5_sport » pour le premier appel et « meteo_antibes » pour le second appel.
17
Pour la source InternalNews, un appel à la méthode getValidNews est enregistré avec « conference » comme paramètre.
Deux transformations XSL, une pour CachedRssReader, une pour InternalNews, sont appliquées sur les préférences (Figure 8).
Figure 8 : Traitement : mise en oeuvre
La figure 9 montre la transformation XSL pour la source InternalNews. Les préférences de l’utilisateur sont placées en entrée, le résultat crée sera utilisé comme message d’entrée de la méthode getValidNews de InternalNews.
18
Figure 9 : Résultat des transformations Xsl sur les préférences
Le fait de paralléliser les appels aux différentes sources pose un problème pour l’envoi des résultats au client. En effet, l’orchestration retourne au client, une seule variable contenant l’ensemble des informations qu’il a demandé. Cette seule variable ne peut donc pas être accédée en parallèle, à cause de problème d’accès concurrentiel en écriture. Nous utilisons une variable par source d’information. Cette variable est utilisée pour le stockage des résultats renvoyés par une source d’information. La mise en commun de ces différentes variables est réalisée de manière séquentielle par l’étape suivante.
<WS> <name>InternalNews</name> <call> <name>getValidNews</name> <args> <tableau>conference</tableau> </args> </call> </WS> <WS> <name>CachedRssReader</WS> <call> <name>getFeedContent</name> <args> <chaine>TV5_sport</chaine> </args> </call>
<call> <name>getFeedContent</name> <args> <chaine>meteo_antibes</chaine> </args> </call> </WS>
<inputInternalNews> <input>conference</input> </inputInternalNews>
<inputCachedRssReader> <nickname>TV5_sport</nickname>
<nickname>meteo_antibes</nickname> </inputCachedRssReader>
Transformation XSL
19
3.2.1. Continuité de service
Notre orchestration va fournir un ensemble d’informations, obtenu par l’intermédiaire d’un ensemble de sources. Ces différentes informations vont être affichées sur un grand écran visible par tous. C’est pour cela que nous souhaitons éviter de transmettre une erreur (une faute) au client utilisant notre orchestration. Le problème posé par l’architecture développée vient du fait que nous utilisons un ensemble de sources sur lesquelles nous n’avons aucun moyen de contrôle. L’une de ces sources peut à tout moment ne plus répondre à nos demandes, c’est pour cela que nous devons être capables de récupérer les erreurs émises lors de l’appel à ces différentes sources. Nous avons donc mis en place une architecture permettant d’absorber les erreurs émises tout en en gardant une trace pour l’administrateur du système. Ce mécanisme doit permettre à notre application, de continuer à s’exécuter si l’une des sources vient à ne plus fonctionner correctement.
Implémentation :
Pour mettre en œuvre cette architecture nous avons mis en place un Web Service permettant d’effectuer des logs dans une base de données. Celui-ci, appelé LogService, nous permet de garder une trace en cas d’erreurs venant de l’une de nos sources. La solution adoptée est donc assez simple, si une erreur survient lors de l’appel à une source d’information, la trace de l’erreur est stockée dans une base de données et l’information donnée par la source est une information vide. Vous pouvez voir sur la figure 10 un schéma simplifié qui représente le traitement des erreurs effectué.
20
Figure 10 : Traitement d'une erreur
Avec ce système de gestion des erreurs, lorsqu’une erreur survient, elle est complètement invisible pour le client. De plus si nous le souhaitons nous pouvons accéder aux erreurs via la base de données et l’application continue de fonctionner.
3.3. Construction du résultat
Comme vue précédemment, après avoir appelé les sources d’information qui nous intéressent, il faut rassembler ces informations dans une seule variable pour les envoyer au client. Les variables des sources, pouvant contenir plusieurs résultats d’une même source, doivent être concaténées au sein d’une seule et même variable : le résultat de l’orchestration (cf. Figure 11).
21
Figure 11 : Construction du résultat
Implémentation :
Pour la concaténation de plusieurs variables, la norme BPEL impose l’utilisation de transformations XSL. Après plusieurs tentatives infructueuses pour mettre en place des transformations XSL nous permettant de réaliser cette concaténation, nous nous sommes rendu compte qu’il était impossible de le faire à cause d’une limitation du serveur GlassFish. Pour pallier à ce problème nous nous sommes permis de dévier de la norme BPEL en accédant aux éléments (les résultats) des variables comme on accède aux éléments d’un tableau (cf. Figure 12).
InternalNews ResultsNews ; CachedRssReader ResultsRss ; InfoProvider Results ; doXslTransform(« concat.xsl », Results, ResultsNews) ; doXslTransform(« concat.xsl », Results, ResultsRss) ;
Figure 12 : Construction du résultat en respectant la norme BPEL (pseudo-code)
Si on reprend l’exemple du chapitre précédent, on obtient deux variables, nommées CachedRssReaderTemp et InternalNewsTemp. Ces deux variables contiennent les résultats des appels aux sources d’informations CachedRssReader et InternalNews. La méthode getFeedContent du Web Service CachedRssReader a été sollicitée deux fois : une fois avec comme paramètre TV5_sport et une fois avec meteo_antibes. Ces deux appels ont
22
renvoyé un résultat chacun, ces deux résultats sont donc stockés dans la variable CachedRssReaderTemp.
Ces différents résultats sont copiés un à un vers la variable de retour de infoProvider (cf. Figure 13).
Figure 13 : Construction du résultat en déviant de la norme BPEL (pseudo-code)
Cette façon de construire la variable de retour de l’orchestration est assez simple et demande peu d’effort à mettre en place. Cependant, il existe un problème plus difficile à résoudre : la propagation des types. Conformément à la démarche SOA, tous les Web Services sont indépendants (couplage lâche), chaque résultat de Web Service possède donc son propre type. Ce type est défini dans le XML Schema de chaque Web Service, de même que le type de retour de l’orchestration qui est défini dans le XML Schema de l’orchestration. La difficulté réside donc dans le fait de faire cohabiter ces différents types et au final de pouvoir stocker dans la variable de retour toutes les informations contenues dans les variables temporaires sans en perdre la structuration lors du changement de type. Dans notre première conception de l’architecture, nous avions décidé de définir comme anytype les champs stockant l’information récupérée dans les variables temporaires. Grâce à cela, nous pouvions copier directement d’une variable à une autre sans tenir compte du typage (cf. Figure 14).
InternalNews ResultsNews[] ; CachedRssReader ResultsRss[] ; InfoProvider Results[] ; Int index = 0 ; For(i=0 ; i < ResultsNews.size() ; i++) { Results[index] = ResultsNews[i] ;
Index++ ; } For(i=0 ; i < ResultsRss.size() ; i++) { Results[index] = ResultsRss[i] ;
Index++ ; }
23
Figure 14 : Première solution pour la copie des résultats
L’inconvénient de cette méthode est que l’on perd le typage lors du transfert des données. Cela rend l’exploitation des données par le client extrêmement compliquée voire impossible. Par exemple, si un client Java utilise cette orchestration, le résultat qu’il obtiendra sera une liste d’Object. Chaque Object représentant un résultat. Pour pallier à ce problème, on peut lors de la définition de la variable de retour de l’orchestration (XML Schema), utiliser le système de choice offert par le XML Schema. Ce système permet d’affecter plusieurs types à une variable (ou au champ d’une variable complexe), comme le montre la figure 15. Le type réel du champ sera déterminé à l’exécution. Cela permet au client d’utiliser les différents types complexes renvoyés par les sources d’information.
24
Figure 15 : Deuxième solution pour la copie des résultats
4. Tests de stabilité
La première version de l’application Java utilisait ODE (incubateur apache) qui ne supportait pas l'utilisation intensive du service (effondrement pour des problèmes de fuites mémoire). Nous avons donc mis en place des tests permettant de vérifier si la nouvelle solution, développée en utilisant Java et déployée sur un serveur GlassFish supportait la montée en charge.
25
Expérience Objectif de l'expérience : Cette expérience a pour but de valider l'utilisabilité du prototype implanté sur le long terme par une technique de simulation. Elle simule en condensé une utilisation intensive de l'application décrite dans ce rapport. Protocole : Cx est un programme client de l'orchestration. Il effectue une invocation de l'orchestration, puis décide d'un temps de pause aléatoire entre 0 et 3000 ms. S est le serveur d'application ou s'exécute l'orchestration. Une sonde journalise consommation mémoire du processus exécutant le serveur J2EE sur S. On commence par lancer quatre clients C1, C2, C3, C4. Au bout d'une heure, on lance 4 nouveaux clients supplémentaires C11, C12, C13 et C14. Etalonnage du banc de test : On utilise D une orchestration de démonstration comme cible des Cx. Cette orchestration n'utilise aucune ressource externe au serveur d'application, et se contente de manipuler des objets constants. Les résultats obtenus (consommation mémoire du serveur en fonction du temps) sont disponibles en figure 16.
Figure 16 : Charge mémoire de l'orchestration étalon
26
On utilise maintenant E, un web service de démonstration, comme cible des Cx. Ce web service est le service CalculatorWS, fourni comme exemple d’implémentation de Web Service pour le serveur GlassFish. Les résultats obtenus (consommation mémoire du serveur en fonction du temps) sont semblables à ceux de l’orchestration précédente. Les résultats de l'étalon montrent qu'une utilisation sur le long terme du serveur d'application est envisageable. Ces résultats sont néanmoins à nuancer car obtenu à l'aide d'une micro-application 'preuve de concept' qui n'a pas la même échelle que l'application testée.
Expérimentation : On utilise l'orchestration infoProvider développée dans le cadre de ce document comme cible des Cx. Les résultats obtenus (consommation mémoire du serveur en fonction du temps, latence des clients) sont disponibles en figure 17 et 18.
Figure 17: Charge mémoire de l'orchestration infoProvider
27
Figure 18: Latence des clients
Conclusions : Au niveau de l'orchestration infoProvider, on observe une forte augmentation de la mémoire utilisée. Après avoir testé tous les services utilisés par infoProvider indépendamment, nous avons identifié la source du problème : les transformations XSL utilisées dans la phase de traitement des préférences utilisateur. Il apparait clairement que le serveur GlassFish ne supporte pas ce type de transformation. Le serveur GlassFish arrive ici à saturation après 100 000 appels à notre orchestration, alors que le serveur Tomcat, hébergeant l’ancienne version de Seduite, saturait au bout de 100 appels. Le passage à GlassFish a donc changé l’échelle d’un facteur de 1000. Même si la consommation mémoire du serveur augmente rapidement, cela n’affecte pas le client qui reçoit toujours les informations en un temps acceptable (Figure 18). Une solution envisageable pour résoudre ce problème serait de supprimer les transformations XSL effectuées lors du traitement des préférences utilisateur. Pour cela, le traitement des préférences ne doit plus être centralisé, mais réparti au niveau des appels aux sources d’information. Pour chaque source d’information, l’orchestration demande à ProfileManager si le client est abonné à cette source, avant de lancer l’invocation.
28
5. Organisation au sein du groupe
5.1. Première période : octobre-décembre 2008
Pour l’organisation du travail, nous avons suivi le planning fourni en annexe. Tout d’abord, nous avons pris du temps pour nous familiariser avec les technologies et le projet.
Ensuite, Stéphane et Lionel ont commencé à développer différentes versions de l’orchestration InfoProvider.
• InfoProvider v1.0 : Permet de récupérer des informations en utilisant
l’orchestration CachedRssReader.
• InfoProvider v1.1 : Ajoute à l’orchestration la gestion des nouvelles internes.
• InfoProvider v1.2 : Gère le traitement des erreurs, la gestion des logs d’erreurs. Prise en charge de la gestion des profils.
En parallèle, Clémentine a développé les différents Web Services utilisés par l’orchestration.
5.2. Deuxième période : janvier-février 2009
Durant la deuxième période, nous avons finalisé l’application:
• création d’une nouvelle version des web services (InternalNews et ProfileManager)
• ajout de transformations XSL pour gérer les résultats des différents
web services dans l’orchestration
• création de scripts de déploiement de l’application (orchestrations, web services, base de données)
• déploiement de l’application sur le serveur de l’école • création de clients pour tester la stabilité de l’application
• rédaction de la documentation wiki
• rédaction du rapport et préparation de la soutenance
Le détail des tâches effectuées (personnes concernées, durée,…) est visible sur le diagramme de Gantt fourni en annexe.
29
6. Difficultés rencontrées
Lors du développement de cette architecture nous avons rencontré différents problèmes. La première difficulté était due à l’environnement de développement utilisé, nous avons fait le choix d’utiliser la suite Netbeans intégrant le serveur GlassFish, de ce fait nous avions accès à une implémentation de référence (Web Services, BPEL, J2EE) totalement gratuite. Toutefois cet environnement était extrêmement lourd, et l’utilisation de GlassFish nous a posé certaines difficultés pour le déploiement des orchestrations et pour le débogue.
L’une des plus grandes difficultés fût de prendre en main BPEL car nous utilisions pour la première fois ce langage. Celui-ci est principalement utilisé dans le monde industriel, de ce fait la documentation est extrêmement limitée ou payante. Nous avions donc beaucoup de difficultés à résoudre les problèmes rencontrés lors de son utilisation.
L’un des points qui fût aussi extrêmement complexe à résoudre fût la création du résultat de notre application. Nous avons perdu énormément de temps sur ce point là, car nous avons tenté de suivre la norme BPEL dans un cas où les outils utilisés nous en empêchaient. Pour réaliser cette opération nous n’avons eu d’autre choix que de dévier de la norme.
La dernière difficulté rencontrée était de pouvoir effectuer une propagation des différents types utilisés vers l’utilisateur de notre orchestration InfoProvider. Lors des premiers tests d’utilisations de cette orchestration, l’utilisateur obtenait comme résultat un ensemble d’objets abstraits et non exploitables. Nous avons donc pris le choix de propager les différents types pour que les résultats récupérés soit utilisables.
30
7. Conclusion
7.1. Objectifs atteints
Nous avons pu mettre en œuvre une solution répondant à la majorité de nos objectifs :
Notre architecture est évolutive car nous pouvons étendre le nombre de sources utilisées assez facilement (cf. partie 4). De plus, notre application permet une gestion naïve de profils, permettant ainsi une personnalisation des informations renvoyées.
Notre orchestration possède un système de récupération sur erreur qui permet une continuité de service tout en gardant une trace des erreurs survenues dans la base de données. Comme démontrer par nos tests, notre plateforme n’est pas stable pour l’utilisation en continue. Cependant, nous avons pu identifier la source du problème et proposer une solution possible pour y remédier.
7.2. Perspectives
Grâce à notre projet, l’écran plasma situé dans le hall du bâtiment de l’EPU devrait, dans les mois qui viennent, afficher de nouveau des informations. Seul un client graphique, basé sur la technologie Flash, reste à implémenter.
Notre implémentation va servir de preuve de concept pour le projet Faros. Un wiki a été mis en place pour cela. Celui-ci est accessible à l’adresse suivante: http://anubis.polytech.unice.fr/jSeduite.
Des étudiants en Master 1, de l’université de Nice, vont prendre le relais et créer de nouveaux services adaptés cette fois-ci à l’institut Clément Ader (IES), à Nice, institut accueillant des jeunes déficients visuels ou auditifs.
7.3. Apports personnels
Ce projet nous a permis de nous familiariser avec la méthodologie SOA, ainsi qu’avec les technologies en découlant, telles que BPEL et J2EE. Cette expérience acquise lors du projet est un atout puisque le SOA est très présent dans les entreprises et donc les personnes connaissant ce domaine sont très demandées.
31
Références
[MacKenzie et al., 2006] MacKenzie, M., Laskey, K., McCabe, F., Brown, P., and Metz, R. (2006). Reference Model for Service Oriented Architecture 1.0. Technical Report wd‐soa‐rm‐cd1, OASIS.
[Blay‐Fornarino et al., 2007a] Blay‐Fornarino, M., Collet, P., Lahire, P., Lavirotte, S., Pinna‐Déry, A.‐M., and Tigli, J.‐Y. (2007a). Contrats et compositions de services de l'application seduite (services de diffusion ubiquitaire d'informations dans des etablissements scolaires). Technical Report F.4.1, RNTL Faros.
[Mosser et al., 2008b] Mosser, S., Blay‐Fornarino, M., and Riveill, M. (2008b). Web Services Orchestration Evolution : A Merge Process For Behavioral Evolution. In 2nd European Conference on Software Architecture (ECSA'08), Paphos, Cyprus. Springer LNCS.
[Mosser et al., 2009] Mosser, S., Blay‐Fornarino, M., and Montagnat, J. (2009). Orchestration Evolution Following Data�ow Concepts : Introducing Unanticipated Loops Inside a Legacy Work�ow. In International Conference on Inter‐net and Web Applications and Services (ICIW), Venice, Italy. IEEE Computer Society.
[Papazoglou and Heuvel, 2006] Papazoglou, M. P. and Heuvel, W. J. V. D. (2006). Service oriented design and development methodology. Int. J. Web Eng. Technol., 2(4) :412�442.
[Joffroy et al., 2007b] Joffroy, C., Pinna‐Déry, A.‐M., Renevier, P., and Riveill, M. (2007b). ARCHITECTURE MODEL FOR PERSONALIZING INTERACTIVE SERVICE‐ORIENTED APPLICATION. In 11th IASTED Interna‐tional Conference on Software Engineering and Applications (SEA'07), pages 379�384, Cambridge, Massachusetts, USA. IASTED, ACTA Press.
[Blay‐Fornarino et al., 2007b] Blay‐Fornarino, M., Hourdin, V., Joffroy, C., Lavirotte, S., Mosser, S., Pinna‐Déry, A.‐M., Renevier, P., Riveill, M., and Tigli, J.‐Y. (2007b). Architecture pour l'adaptation de Systèmes d'Information Interactifs Orientés Services. Revues des Sciences et Technologies de l'Information (RSTI), pages 93‐118.
[Newcomer, 2002] Newcomer, E. (2002). Understanding Web Services : XML, WSDL, SOAP, and UDDI. Addison‐Wesley Professional.
[Christensen et al., 2001] Christensen, E., Curbera, F., Meredith, G., and Weerawarana, S. (2001). Web services description language (WSDL) 1.1. W3cnote, World Wide Web Consortium.
[Peltz, 2003] Peltz, C. (2003). Web Services Orchestration and Choreography. Computer, 36(10) :46�52.
[Jordan et al., 2007] Jordan, D., Evedmon, J., Alves, A., Arkin, A., Askary, S., Barreto, C., Bloch, B., Curbera, F., Ford, M., Goland, Y., Guízar, A., Kartha, N., Liu, K., Khalaf, R., Konig, D., Marin, M., Mehta, V., Thatte, S., Van der Rijn, D., Yendluri, P., and Yiu, A. (2007). Web Services Business Process Execution Language Version 2.0. Technical report, OASIS.
32
Glossaire
SEDUITE : SErvices de Diffusion Ubiquitaire d'InformaTions dans des Etablissements scolaires EPU : Ecole Polytechnique Universitaire I3S : Laboratoire d'Informatique, Signaux et Systèmes de Sophia-Antipolis CNRS : Centre National de la Recherche Scientifique MODALIS : MODels to usAge of large scaLe InfraStructures UNSA : Université de Nice Sophia Antipolis ANR : Agence National de Recherche FAROS : Fiabilité des Architectures Orientées Services EDF : Electricité de France IRISA : Institut de recherche en informatique et systèmes aléatoires INRIA : Institut National de Recherche en Informatique et en Automatique EPI : Equipe Projet INRIA SOA :Service Oriented Architecture ADORE : Activity moDel SuppOrting oRchestration Evolution PDA : Personal Digital Assistant IES :Institut Education Sensorielle RSS : Really Simple Syndication J2EE : Java Enterprise Edition BPEL : Business Process Execution Language ODE : Open Dynamics Engine URL : Uniform Resource Locator UML : Unified Modeling Language SQL : Structured Query Language XML : eXtensible Markup Language XSLT : Extensible Stylesheet Language Transformation IIS :Internet Information Services ROME : Rss and atOM UtilitiEs
33
Tables des illustrations
FIGURE 1 : ARCHITECTURE ORIENTEE SERVICES POUR LA DIFFUSION D’INFORMATIONS................................................................ 5 FIGURE 2 : APERÇU GENERAL DE L’ORCHESTRATION INFOPROVIDER ....................................................................................... 8 FIGURE 3 : DIAGRAMME D’ACTIVITE UML DE CACHEDRSSREADER ...................................................................................... 10 FIGURE 4 : PERSONNALISATION DES INFORMATIONS ......................................................................................................... 12 FIGURE 5 : MESSAGE XML DE PREFERENCES RENVOYES PAR PROFILEMANAGER (INSTANCE) ......................................... 14 FIGURE 6 : RECUPERATION DES INFORMATIONS................................................................................................................ 15 FIGURE 7 : TRAITEMENT DES PREFERENCES UTILISATEUR .................................................................................................... 16 FIGURE 8 : TRAITEMENT : MISE EN OEUVRE ..................................................................................................................... 17 FIGURE 9 : RESULTAT DES TRANSFORMATIONS XSL SUR LES PREFERENCES .............................................................................. 18 FIGURE 10 : TRAITEMENT D'UNE ERREUR ........................................................................................................................ 20 FIGURE 11 : CONSTRUCTION DU RESULTAT ...................................................................................................................... 21 FIGURE 12 : CONSTRUCTION DU RESULTAT EN RESPECTANT LA NORME BPEL (PSEUDO‐CODE) .................................................. 21 FIGURE 13 : CONSTRUCTION DU RESULTAT EN DEVIANT DE LA NORME BPEL (PSEUDO‐CODE) ................................................... 22 FIGURE 14 : PREMIERE SOLUTION POUR LA COPIE DES RESULTATS ........................................................................................ 23 FIGURE 15 : DEUXIEME SOLUTION POUR LA COPIE DES RESULTATS ....................................................................................... 24 FIGURE 16 : CHARGE MEMOIRE DE L'ORCHESTRATION ETALON ............................................................................................ 25 FIGURE 17: CHARGE MEMOIRE DE L'ORCHESTRATION INFOPROVIDER ............................................................................. 26 FIGURE 18: LATENCE DES CLIENTS ................................................................................................................................. 27
34
Annexe 1 : Diagramme d’activité d’infoProvider
35
Annexe 2 : Ajout d’une source d’information
Notre architecture doit permettre d’ajouter de nouvelles sources d’information facilement. Pour cela, nous avons donc identifié les parties de InfoProvider à modifier.
1) Traitement des préférences
L’ajout d’une nouvelle source implique qu’un client pourra s’y abonner. Cela entraîne que les préférences données par notre service ProfileManager
pourront contenir des appels à cette source. Il faudra donc ajouter une transformation XSL spécifique à celle-ci.
2) Appel à la nouvelle source
Il va falloir ajouter un nouveau partenaire (notre nouvelle source) à l’orchestration. Cela implique la génération des stubs pour ce service web. Il faut ensuite ajouter l’invocation de ce service en parallèle des autres sources.
3) Propagation du typage
Pour que le client de l’orchestration puisse utiliser pleinement les informations données par la nouvelle source, il faut que InfoProvider propage les types de ces informations. Pour réaliser cela, le type complexe du résultat de InfoProvider doit être étendu de manière à contenir le nouveau type.
4) Construction du résultat
Comme vu précédemment (cf. Figure 12), la construction du résultat final se fait par l’intermédiaire de boucles, une par source d’information. Il va donc falloir ajouter une nouvelle boucle pour concaténer le résultat de la nouvelle source au résultat de InfoProvider.
36
Annexe 3 : Planning
Plannin
g d
e la p
remière p
ériode (o
ctobre –
décem
bre 2
008)
37
Plannin
g d
e la d
euxièm
e pério
de (jan
vier – février 2
009)
38
Annexe 4 :Pseudo-code de notre client de test (pour tester la stabilité de notre application)
Voici le code principal de la boucle de test. La méthode 'perform()' est implémentée pour invoquer le service distant (soit l'étalon, soit infoProvider).
public static void main(String[] args) throws Exception {
long cpt = 0; DateFormat dateFormat = new SimpleDateFormat("yyyy/MM/dd HH:mm:ss"); Random bag = new Random(); bag.setSeed(System.currentTimeMillis()); while (true) {
long start = System.currentTimeMillis(); String result = perform(); long stop = System.currentTimeMillis(); Date date = new Date(); String head = dateFormat.format(date); int sleep = bag.nextInt(3000); System.out.println(++cpt +" " + head + " " + (stop-start) + " "+ sleep + " " +result); Thread.sleep(sleep);
} }