• Aucun résultat trouvé

Service d'agrégation d'événements dans une plateforme coopérative

N/A
N/A
Protected

Academic year: 2021

Partager "Service d'agrégation d'événements dans une plateforme coopérative"

Copied!
47
0
0

Texte intégral

(1)

HAL Id: inria-00000497

https://hal.inria.fr/inria-00000497

Submitted on 10 Nov 2005

HAL is a multi-disciplinary open access

archive for the deposit and dissemination of

sci-entific research documents, whether they are

pub-lished or not. The documents may come from

teaching and research institutions in France or

abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est

destinée au dépôt et à la diffusion de documents

scientifiques de niveau recherche, publiés ou non,

émanant des établissements d’enseignement et de

recherche français ou étrangers, des laboratoires

publics ou privés.

Service d’agrégation d’événements dans une plateforme

coopérative

Sawsan Alshattnawi

To cite this version:

Sawsan Alshattnawi. Service d’agrégation d’événements dans une plateforme coopérative. [Stage]

2005. �inria-00000497�

(2)

Servi e d'agregation d'evenements

dans une plateforme ooperative

M 

EMOIRE

22juin 2005

pourl'obtention du

DEA Informatique de Lorraine -

E ole Do torale IAEM Lorraine

par

Sawsan ALSHATTNAWI

Composition du jury

DominiqueMery ProfesseurUHP-Nan yI et ESIAL DidierGalmi he ProfesseurUHP-Nan yI

Noelle Carbonell ProfesseurUHP-Nan yI OlivierFestor Dire teur de re her he INRIA

(3)

à mes parents, à Mohammed,

(4)

Remer iement

Je remer ie euxqui m'ont apportéleur soutienpendant e stage de DEAenparti ulier :

 Les membres du jury

Pouravoira eptédejugerpouravoira eptédejugermontravailetpourleurs presen es jusqu'à e jour.

 Mon en adrant

Pour sesnombreux onseils.

 Mon hef

 Florent Jouille

Pour sonaide on ernant leprojetlibresour e.

(5)

1 Introdu tion 1 1.1 Contextedustage . . . 1 1.2 Sujet . . . 2 1.3 Présentation du do ument . . . 2 2 Problématique 3 2.1 La Collaboration . . . 3 2.1.1 Dénition . . . 3 2.1.2 Exemples . . . 3 2.1.3 La ons ien e de groupe . . . 4

2.1.4 La ons ien e de groupe ontextuelle . . . 6

2.2 La plateforme oopérative LibreSour e . . . 7

2.2.1 Les omposants deLibreSour e . . . 7

2.2.2 Les événementsdansLibreSour e . . . 8

2.2.3 La ons ien e de groupedansLibreSour e . . . 9

2.3 Obje tifsetproblèmes abordés . . . 9

3 L'ar hite ture fon tionnelle 10 3.1 Introdu tion . . . 10

3.1.1 Groupe ommuni ationdansle Web . . . 10

3.2 Ar hite turePair-à-Pair pourla ons ien ede groupe ontextuelle . . . 11

3.3 Une ar hite ture fon tionnelle in luant un serveur. . . 13

3.3.1 Colle tion . . . 14 3.3.2 Filtrage . . . 15 3.3.3 Agrégation . . . 15 3.3.4 Répartition . . . 15 3.3.5 Noti ation . . . 15 3.3.6 Adaptation etVisualisation . . . 15

(6)

4 L'agrégation sur le serveur 16

4.1 Introdu tion . . . 16

4.2 Choix dela te hnique d'agrégation . . . 16

4.3 Les événements omplexes . . . 17

4.3.1 Le Traitement desévénements omplexes . . . 17

4.3.2 La hiérar hie d'abstra tiondes événements . . . 18

4.4 La miseen oeuvre . . . 18

4.4.1 Les Agentsde Traitement d'Evénements (EPA) . . . 18

4.4.2 La spé i ation desmotifs . . . 20

4.4.3 Les lasses d'EPAs . . . 20

4.4.4 Les réseauxde Traitement d'Événement (EPN) . . . 21

4.4.5 La Classe EPN . . . 22

4.5 Des événements omplexes dansLibreSour e . . . 23

4.5.1 Dénition desressour es d'agrégation . . . 24

4.5.2 Ressour esd'agrégation par défaut etprédénies . . . 25

4.6 La réalisation . . . 25

Con lusionet perspe tives 27 Annexes 28 A Les événements dans LibreSour e 28 B Les événements dans LibreSour e qui passent du ltre 31 C Les événements dans LibreSour e au niveau 2 dans la hiérar hie d'Événe-ment 33 D Un exemple pourdénir un ltre et un Map 34 E un exemple pourfaire l'agrégateur pour SO6 et Files servi es, la lasse pour So6 36 E.0.1 Filtre etagrégateur prédénit . . . 37

(7)

3.1 L'ar hite ture fon tionnelledans leP2Pmodèle[Bouthier, 2003 ℄ . . . 13

3.2 l'ar hite ture fon tionnelle pour le lient/servermodèle . . . 14

4.1 Hiérar hie(partielle) d'abstra tion dansLibreSour e . . . 19

4.2 Règle d'agrégation pourl'a tivité réation d'unequeue So6 . . . 19

4.3 interfa e of anevent pro essing agent lassMAP . . . 21

4.4 Interfa e ofan event pro essingagent lassMAP . . . 21

4.5 La stru ture de réseaude EPAsde [Lu kham,2001 ℄. . . 22

4.6 Exemple de lasseEPN . . . 23

E.1 L'ar hite ture lassepour lemergeragent . . . 36

(8)

Introdu tion

1.1 Contexte du stage

L'un des servi es de base de toute plateforme oopérative est le servi e de ons ien e de groupe qui permet aux parti ipants de setenir au ourant des a tivités du groupe. Ce type de servi eore notamment desmé anismes pour suivre l'a tivité desautres parti ipants ainsique l'étatdel'espa ede travailpartagé.Ilorelapossibilitédeper evoiret omprendrel'a tiondes autres et ainsi de mieux oordonner ses propres initiatives ave l'ensemble du groupe. Il ore également la possibilité de per evoir et omprendre l'avan ement global du travail et ainsi de situersespropres initiativespar apportà l'obje tif global.

Cetypede servi esebasesurl'utilisation etladiusion d'événementsproduits parla plate-formesupportantl'a tivité oopérative,etleursmiseàdispositiondesutilisateurssousuneforme ompréhensible. Des nombreux travaux ont déjà été réalisés sur e sujet depuis une quinzaine d'années.

Quand on travaille ensemble sur un projet ommun en utilisant une plateforme de olla-boration, les événements qui se dé len hent sur ette plateforme sont nombreux. Le nombre d'événements augmente ave la omplexité duprojet:taille dugroupede parti ipants, nombre d'objetsetde do umentsmanipulés,nombred'a tivitésmisesenjeu,grandevariétédesrlesau seinde l'organisation.

Cette omplexité onduit enparti ulier à :

 Submerger les parti ipants de noti ations etd'informations, rendant ainsitrès omplexe la ompréhension globalede l'a tivitédugroupepar haqueparti ipant,

 diminuer la pertinen e des informations oertes aux utilisateurs, qui reçoivent des infor-mations quine les on ernent pasdire tement aumoment où ils lesreçoivent.

Une part des travaux ee tués jusqu'à présent sur letravail oopératif ont visés à résoudre e problème en onstruisant des outils qui diminuent les nombres de noti ation message et présentent aux parti ipants desinformationsplus adaptés àleur travail. Enparti ulier, une ap-pro he a étéproposéedanslathèsede ChristopheBouthier [Bouthier,2003 ℄.Cette appro he se basesurlare onnaissan eetlapriseen omptedu ontexted'a tivitédesdiérentsparti ipants d'unprojetpour :

(9)

de plushaut niveau etplus ompréhensibles,  diuser esinformations demanière plussele tive,

 adapter la présentation des informations à la situation individuelles des parti ipants, en faisantvarier notamment leniveau dedétailetlemoment delaprésentationqui peutêtre retardé.

Cetteappro he est basée surune ar hite ture d'égal-à-égal. L'outil de ons ien e de groupe proposé est réparti sur l'ensembles des ma hines des parti ipants d'un projet. Chaque site est hargé de déte ter, agréger etdiuser les informations lo ales, etre evoir, adapter etprésenter lesinformations enprovenan e desautres parti ipants.

1.2 Sujet

Notre obje tif est de proposer une appro he de ons ien e de groupe traitant le problème delasur harge d'informationsdansle asd'uneplateforme de oopérationbaséesurunserveur et des lients répartis. A la diéren e d'une ar hite ture purement pair-à-pair, une plateforme ollaborative lient/serveur entralise un ertains nombre d'informations sur l'état ourant du projet : stru ture organisationnelle, a tivités et tâ hes, do uments partagés. Ces informations sont parti ulièrement utiles pour la ons ien e de groupeetsamiseen oeuvre.

Notreappro heestbasésurl'adaptationdumodèleproposédanslathèsede C.Bouthierau as d'uneplateforme ollaborative Client/Serveur.

Notretravailest on entrésurl'étaped'agrégationpouragrégerlesévénementsquisedé len hent surle serveur. La plateforme d'expérimentation est la plateforme LibreSour e développée dans l'équipeECOO. Lesdéveloppements onsistent àé rire uneressour e libresoour een Java.

1.3 Présentation du do ument La mémoire omprend trois hapitres :

Le hapitre deuxest onsa réàlaproblématique abordéedans etravail.Ilprésentenotamment desdénitionssurla ons ien edegroupeetla ons ien e degroupeen ontexte.Laplateforme LibreSour eetsonar hite turesont présentéesetlesproblèmes àrésoudrepouratteindre notre obje tifsont expli ités.

Le hapitre 2 est onsa ré à la proposition d'une nouvelle ar hite ture fon tionnelle. Cette ar hite ture fon tionnelle reprend les propositions de la thèse de C. Bouthier en les adaptant au asd'uneplateforme Client/Serveur. Le hapitre donned'abord desdétailssurl'ar hite ture de départet présente les propositions d'extensions né essaire à laprise en ompte d'unserveur entralisé.

Le hapitre 3 estdédié à la on eptiond'unmodulepour l'Agrégationdes événementsdans laplateforme oopérative entralisé. L'appro he hoisie pour réaliser ette agrégation est dié-rente de elle utilisée dans l'appro he initiale est se base sur omment l'agrégation s'est faite dansle réseau égal à égal et omment nousavons utilisé une autre te hnologie plus pertinente àla plateforme oopérative qui s'appelle letraitement d'événements omplexes" omplex event pro essing"(CEP), ommentlelangageRAPIDEestutilisépourleCEPetpuisonadapte ette appro he aux événements dansle LibreSour e. Ensuite sera présenté lastratégie d'implementa-tionetnotrea tion surla programmationetses résultats.

(10)

Problématique

2.1 La Collaboration 2.1.1 Dénition

La ollaboration est letravail intera tif entre au moinsdeux personnes danslebut de om-muniquer, partager des ressour es, oordonner, résoudre des problèmes, réaliser un projet ou parti iper à une négo iation [sap, 2005 ℄. La ollaboration peut se dérouler dans une réunion fa e-à-fa emaisàprésent, onessaiede oordonnerletravail lorsquelespersonnessontréparties dansle temps et dansl'espa e, en utilisant une infrastru ture logi ielle. C'est laresponsabilité duCSCW(Computer SupportedCooperativeWork),ouTCAO(Travail Coopératif Assistépar l'Ordinateur).Le CSCWestunedis ipline del'informatique quiapour objetla ompréhension, l'organisationetlesupportdutravail oopératifmédiatisépar ordinateur.Elleétudieles métho-dologiesdutravail ollaboratifentredespersonnestravaillantensemble, ommentleste hnologies informatiquesetasso iéestrouvent leur pla edans e adre[Fitzpatri ketal., 1999 ℄.

2.1.2 Exemples

Le logi iel BSCW, "Basi Support for Cooperative Work projet" [Bentley etal.,1995 ℄ est un exemple lassique de système oopératif. BSCW estun système extensible pour partager et retrouverdesinformations.

Il onsisteenunserveur,a essibledediérentesplateformes,quigèreplusieursespa esdetravil (workspa es). Chaqueworkspa e ontient desobjetspartagés ommedesdo uments, desURLs, desrépertoires,ainsiquedesmembresetdesgroupesquipeuventa éderà esobjets.Leserveur BSCWestimplantéaudessusd'unserveurWeb http,ilgèrel'ensembledesespa esdetravailet ontrle les a ès à es espa esde travail. Pour travailler, un utilisateur doit s'identier auprès du serveurqui lui propose alors de hoisir l'esp e de travail qui lui onvient (au asoù il a des droitssurplusieurs espa esde travail).

BSCWproposeunservi ede ons ien edegroupe basésurlesévénementsetlanoti ation. Un événement est produit à haque hangement d'état d'un espa e de travail. L'ensemble des membres onne tésà et espa ede travail reçoitalors unenoti ation signalant e hangement d'état.

(11)

2.1.3 La ons ien e de groupe

Leterme ons ien e de groupe (groupawareness) désignel'ensembledesinformationset mé- anismespermettantàdespersonnesdeper evoiret omprendretouteslesévolutionsdel'espa e partagé de ollaboration. La ons ien e de groupe re ouvre des informations sur : où les autre travaillent, e qu'ilsfont, et e qu'ilsvont faire[Gutwin and Greenberg,2002 ℄. Ces informations permettentauxmembresdugroupedeparti iperee tivementauxa tivités ollaboratives,etde oordonner leurs a tions onjointes. Dans le asoù espersonnessont dansun même lieu etau même moment ( ollaboration dire tenon médiatisée), esinformations sont aisément obtenues. Danslasituationoùlespersonnessontrépartiesdansl'espa eoudansletemps,la olle tionetla présentation de esinformations estplusdi ile etné essitent un mé anismelogi ielspé ique etintégré à laplateforme de ollaboration.

Beau oup de modèles et de systèmes ont émergé depuis une quinzaine d'années pour proposer des appro hes qui olle tent et présentent les informations de la ons ien e de groupe de ma-nièrepertinente. Onpeut itertoutd'abordlestravauxautourdesmediaspa es,dontlesystème PortHoles [Dourish and Belloti, 1992 ℄ est le premier représentant. Ce type de système base la ons ien ede groupesurl'intégration d'images vidéossurl'é raninformatique. Cesimages per-mettent desuivre l'a tivitédesautres membres dugroupe.

Une autre lasse de systèmes propose des appro hes à base de widgets graphiques spé ialisés pour l'intera tion en situation oopérative [Gutwin andGreenberg, 1996 ℄,[Gutwin etal.,1996 ℄. Cetteappro heproposed'intégrer dansl'interfa ed'a èsàl'espa edetravaildesélémentspour visualiserl'a tion desmembres du groupe.

Une troisième voie orrespond à des infrastru tures pour la déte tion et la diusion d'événe-ments, ommeElvin[Fitzpatri ketal.,1999 ℄ouNessie[Prinz, 1999 ℄.Chaqueévénementproduit orrespondàun hangementd'étatdansl'espa e ollaboratif.Ilfautnoteraussidestravauxplus théoriquesvisant à proposer un modèle de la ons ien e de groupe. Dans[Rodden,1996 ℄,il est proposéunmodèle basésurlamétaphore spatiale :les éléments onstitutifs de la ons ien e de groupe(objets,parti ipants)sontpla ésdansunespa edanslequelonpeut al ulerunedistan e permettantdedéterminer equiestvuparlesparti ipantsdela oopération.Cetypedemodèle permet de modéliser la pertinen e des informations pour les membres de la oopération en se basant surlanotion dedistan e.

A tuellement,deseortssontfaitspouraméliorerlapertinen edesinformationsoertesaux utilisateursparlapriseen omptedeleur ontexted'a tivité.Parexemple,lesystèmeENI(Event andNoti ation Infrastru ture)[Grossand Prinz, 2003 ℄qui ombinedesévénementslogiquesde l'espa elogi iel etdesévénements apturésdansl'espa e physique, pour re onnaître etprendre en ompte lasituation d'usage danslaprésentation desinformations auxutilisateurs.

Les éléments de la ons ien e de groupe

La ons ien e de groupe onsiste en un ensemble d'éléments que les parti ipants doivent onnaître[Gutwin and Greenberg, 2002 ℄,[Fitzpatri ketal.,1999 ℄.Ces éléments sont :

1. Qui(who) :Est- equ'ilya d'autres personnesdansl'espa e de travail? etquisont-elles? 2. Quoi (what) : Ce que font es personnes en général ou en détail, et sur quel(s) objet(s)

travaillent-elles?

3. Où (where):Oùtravaillent espersonnes?

(12)

5. Comment (how) :Comment l'a tivité seproduit?

La réponse à haque question ( qui travaille ave nous, e qu'ils font, où ils sont, quand et omment les événements se produisent) nous donne des indi ations sur les informations que l'outil de ons ien e de groupedoit olle ter.

Parailleurs,[Tam andGreenberg,2004 ℄proposeplusieursperspe tivespouranalyseret stru -turerlesinformationsde ons ien edegroupe,suivantletypedequestionsquel'utilisateurpeut poser au système. Par exemple si le parti ipant est intéressé par un objet, la perspe tive objet de la ons ien e de groupe lui permet de trouver des réponses à toutes les questions relatives à l'état et l'évolution des objets partagés. Si au ontraire il est intéressé par une personne, la perspe tiveorientépersonnes luioredesréponsessurdesquestionsliésauxmembresdugroupe (quefait-elle?,qu'est- e qu'ellea fait?, pourquoi?et omment?).

Les dimensions de la ons ien ede groupe

Certains auteurs identient plusieurs dimensions dans la ons ien e de groupe. Prinz, dans [Prinz,1999 ℄ enidentiedeux prin ipales:La ons ien eso ialeetla ons ien ede l'a tivité.

1. La ons ien e so iale est l'information que l'utilisateur obtient sur ses ollègues dans le ontexted'une onversation so iale.La noti ation pour la ons ien eso iale ontient des informations sur:qui estlàetsonétat dansl'environnement partagé.

2. La ons ien e de l'a tivité orrespond aux informations relatives aux a tivités desautres membres du groupe. Par exemple, être informé de e que les autres membres font à un moment donné. Elle permet aux utilisateurs de oordonner leurs a tivités sur un objet partagé. La noti ation ontient des informations on ernant qui fait l'a tion et sur quel objet. Interlo us[Nomura etal., 1998 ℄estunexempledesystèmequinotieàl'utilisateur tous hangements surlesobjets partagés.

Dans[Steineld etal.,1999 ℄ on trouve en ore lesdimensions suivantes :

1. La ons ien e de présen e : Il y a des appli ations qui ontrlent la présen e et la dis-ponibilité d'unmembre pour fa iliter l'intera tion so iale. ICQ estun systèmepar lequel l'utilisateur peut indiquer sa présen e physique et son envie d'a epter l'intera tion ave les autres.

2. La ons ien edelaperspe tive:lesparti ipantsneveulentpassavoirlesa tionsdesautres dansle passémaisils sont intéresséspar lemoyen émergen ede esa tions.

3. La ons ien edel'environnement: 'estd'êtreau ourantdesévénementsquiseproduisent dansl'espa e physique.Elle estidentiqueàla ons ien eso ialedansPrinz (1999).

Les problèmes de la ons ien e de groupe

Les appro hes pour la ons ien e de groupe proposées jusqu'à présent se sont montrées ef- a es dansdes ontextes pré is. Elles fon tionnent biendans desgroupes de petite taille, par-tageant peu de do uments et souvent de façon syn hrone. C'est par exemple le astypique de l'édition ollaborative d'undo ument ommun.

Par ontre, es appro hes sont prises en défaut lorsqu'il s'agit de on evoir un système de ons ien e de groupe adapté au support de projet ollaboratifs de grande taille, par exemple dansle asde l'ingénierie oopérative.Ces projets se ara térisent, entreautre, par :

(13)

sous- un nombred'objets,dedo uments etde tâ hesquipeutêtregrand,

 un nombre de parti ipants qui peut être grand, ave des situations individuelles (rles, tâ hes, objets manipulés,relations so iales) très diverses.

Dansun tel adre, lesappro hesproposées sont mal adaptées dufait du tropgrandnombre d'informations ou d'événements produits, et de la diversité des situations individuelles. Elles onduisent notamment à :

 Sur harger l'utilisateur d'informations, e qui risque de le onduire soit à passer trop de temps pour per evoir les travail des autres, au détriment de son propre travail, soit à volontairement ne pas traiter ertaines information et ainsiobtenir une vision erronée de l'état dela ollaboration,

 Proposer à l'utilisateur des informations inadaptées à sa situation individuelle, qui intro-duisent ainsiunbruit supplémentaire danslesinformations déjà nombreusesqu'il reçoit. Pourtant, les mé anismes de ons ien e de groupe restent indispensables dans les projets oopératifsde grandetaille.

2.1.4 La ons ien e de groupe ontextuelle

La ons ien e de groupe ontextuelle est une première tentative de réponse au problème de lasur harge d'informationdansles plateformespourprojets oopératifsde grandetaille.L'idée estd'utiliserunereprésentationdu ontextedetravail de haqueutilisateurpouradapter les in-formationsquiluisont oertes.L'adaptation on ernelesinformationsetleur ontenu,ainsique leurprésentation. Onespère ainsiaméliorer lapertinen e desinformations transmises à haque utilisateureten diminuerle volume,limitant ainsilasur hargepotentielle.

Quelquespropositionsontdéjàétéfaitesdans ettevoie.Parexempledans[GrossandPrinz, 2003 ℄, le ontexte de travail re ouvre l'ensemble des informations ara térisant l'environnement phy-sique d'intera tion d'un utilisateur. Le système tient ompte de e ontexte pour proposer un représentation desinformations adaptée à la situation donnée (en réunion, en dépla ement, au bureau...).

Dans [Bouthier,2003 ℄, le ontexte de travail est limité au ontexted'a tivité à l'intérieur de la plateformede ollaboration (àl'ex lusiondu ontextephysique).Par ontre, e ontexteest uti-liséégalement àla sour e pour agréger les événements olle tésavant de les diuser auxautres parti ipants. Les informations transmises sont ainsi moins nombreuses et de plus haut niveau. Le ontexte est ensuiteutilisé pour adapter la représentation de esinformations à lasituation individuellede haqueparti ipant. I i,le ontextesedénit omme l'ensemble desinformations hautniveaureçuesparl'outilde ons ien edegroupe.Cesinformationshautniveauproviennent àla foisde l'agrégation d'événements lo aux issusde l'a tivité de l'utilisateur,etdes outilsdes autresmembres dugroupe.

Cetteappro headon undoubleeetsurlasur harged'information:l'agrégationpermetde diminuerle nombre d'informations é hangés entre les membres du groupe, l'adaptation permet d'améliorer lapertinen e desinformationsnalement proposéesà haqueutilisateur.

Les dimensions du ontexte de travail

Onpeutdistinguer plusieurs dimensionsdu ontexte detravail :

 le ontextegéographiqueetlalo alisation(dansquelbâtiment,quelétageetquelbureau).  le ontexte organizationnel (dans quel projet et dans quel département les personnes se

(14)

 le ontextepersonneletso ial(dansquellefamilleetquelssontsesamis)[Abowdetal.,1999 ℄.  letemps (quandlapersonne se onne teet quandelle sedé onne te).

 l'a tivité(quellesontlesa tivitésqu'elleafait,sona tivité ourante)[GrossandPrinz, 2003 ℄.  l'outil utilisé pour interagir ave l'espa e de ollaboration (ordinateur de bureau, PDA,

téléphone...)

Ces diérentes dimensions ont toutes une inuen e sur l'adaptation des informations de la ons ien edegroupequ'ilfautréaliser.Ainsi,demanièreidéale,unoutilde ons ien edegroupe devraitêtre apabledere onnaître etde prendreen omptetoutes esdimensionsetfa ettesdu ontexte detravail desutilisateurs.

2.2 La plateforme oopérative LibreSour e

LibreSour e [Lib,2005 ℄ est un environnement oopératif distribué orant des servi es pour héberger deséquipesdistribuées. Ilpermetnotammetà une équipe distribuée de s'organiser,de travaillerensembleetde oopéreràlaréalisationd'unprojetautraversd'unouplusieursespa es detravail partagés.

LibreSour e ombine d'une part des outils de produ tion oopérative : servi e de partage de  hiers et de oordination et d'autre part des outils de gestion de ommunautés : servi es de ommuni ation etde gestionde ontenu.

LibreSour eestuneplateformeorientéeWeb:lesservi essonta essiblesautraversduproto ole http via un serveur Web. Les lients permettant l'a ès aux servi es sont don desnavigateurs web.

LibreSour e est le produit d'un projet RNTL asso iant le projet ECOO du Loria, la so iété Artenumetl'Université deParis 7.

2.2.1 Les omposants de LibreSour e

LibreSour e est un ensemble de omposants modulaires que l'on assemble au moment de la onguration d'un projet en fon tion des besoin de e projet. De nombreux omposants sont lassiques:forum,wiki,tra eur debugs,gestionnairede groupes.Deux omposantsontune im-portan eparti ulièreetsontoriginaux:So6ungestionnairede ongurationd'untypenouveau, etBonita,un systèmede gestionde workow.

So6 est un outil de gestion de ongurations basésur un outil de fusion de données robuste et unié(un algorithme ommunàtouslestypesdedonnées).Contrairementauxoutils lassiques, il n'est pas basé surla notion de version, mais se base surla gestion des histoires d'opérations appliquéesaux donnéeset utilise des mé anismes de transformationsd'opérations pour réaliser les fusions. Bonita est un outil de gestion de ots de tâ hes (workow) exible et dynamique permettant dedé rire desen haînementsd'a tivités etde ontrlerleur exe ution.

Un environnement dans LibreSour e est un ensemble de ressour esorganisé de manière ar-bores ente. Travailler dans un tel environnement onsiste à réer, éditer, modier, dépla er, supprimer des ressour es. Une ressour e peut orrespondreà un servi einstan ié dans un pro-jet:un forum, un wiki,un espa e de do uments, ou à une ressour ede type donnéemanipulée par le projet :un membre, un do ument, un groupe ...Le nommage des ressour esest basé sur leur position dans l'arbre des ressour es. Le nom etla position de la ressour e dans l'arbre est déterminéaumoment desa réation:laressour e rééeestliéeàuneURI omposéenotamment du hemin d'a èsàla ressour edepuis lara ine de l'arbre.

(15)

Æ LibreSour e Æ proje t Æ forum Æ mailingList Æ file Æ timeline Æ proje t Æ file

Lesressour essont lasséesen quatre atégories :

1. Le partage de données:transfert de hiers, fusionde données (So6),

2. La ommuni ation : LibreSour e fournit des forums, liste de diusion et wiki page qui permetauxutilisateur de réer etéditerdespage web en utilisant le navigateur web. 3. La oordination:LibreSour e fournitle"bug tra ker"etlegestionnairede tâ hesBonita. 4. La ons ien e de groupe : LibreSour e gère desqueues d'événements persistants produits

par les ressour es.

2.2.2 Les événements dans LibreSour e

Un événement est un objet persistant rée dans le système haque fois qu'une opération sur une ressour e se produit. Le type de l'événement dépend de la ressour e et de l'opération dé len hésur etteressour e.Ainsi,unévénementpermetd'identierexa tementl'opérationqui s'estdérouléesurle serveur.Ondistingue deuxtypesd'événementsdansLibreSour e :

 Général : e sont des événements orrespondant à desopérations existant pour toutes les ressour es : réer, éditer,etsupprimer.

 Dépendant : e sont des événements orrespondant à des opérations spé iques à une resour e.

Par exemple, les opérations, etdon les événnements, asso iéesà laressour e "Files"sont: - LibreSour eFiles.file. reate

- LibreSour eFiles.file.edit - LibreSour eFiles.file.delete - LibreSour eFiles.file.download

Annex(A) ontient toutes les ressour esave leurs événements dansLibreSour e. Lesaspe ts d'événement sonttrois:

 form : l'événement est un objet qui a des attributs, omme: quandil s'estproduit, où il s'est produit,qui l'a faitetquelle estsasigni ation.

 signi ation :l'événement signieune a tivités.

 relatif :une a tivité est reliée ave une autre a tivité soit par temps ou par ausality ou par l'agrégation.

LibreSour e dirigedesévénements, réer,dépla er, ...les lients peuvent sous rireà l'événe-ment pour re evoir lesmessagesde noti ation par emaillorsqu'unévénement seproduit.

(16)

2.2.3 La ons ien e de groupe dans LibreSour e

La ons ien e de groupe dans LibreSour e est basée sur le mé anisme des événements. Les événements produits par lesystèmesont sto kéesdansune queue persistante.

Les lientsLibreSour epeuventsous rireàunequeued'événementsetreçoiventdesmessagesde noti ationpour haqueévénementajoutédans ettequeue.Cemessage ontientlesinformations on ernant laforme de l'événement :type,datede réation, ressour e on ernée, origine...

Le nombre de es événements peut être très grand, d'une part par e que le nombre d'opé-rations exé utées sur le serveur peut être important, et d'autre ar l'exé ution d'une a tivité par un lient peutmettre en jeuplusieurs ressour esetdon générer plusieurs événements. Par exemple,l'a tivitéde réationd'unprojetva orrespondreaux opérations :

- LibreSour eCore.proje t. reate - kernel. reate

- kernel.bind

2.3 Obje tifs et problèmes abordés

Comme dans de nombreuses plateforme oopérative, le problème de la sur harge d'infor-mations dans la ons ien e de groupe se pose dans LibreSour e. L'obje tif de e travail est de proposer une solution à e problème dansLibreSour e en adaptant l'appro he de la ons ien e degroupe ontextuelleproposée danslathèse deC. Bouthier [Bouthier,2003 ℄.

Aterme,l'obje tifestdon la onstru tion d'unmé anismede ons ien edegroupe utilisant un représentation du ontexte de travail des utilisateurs pour agréger les informations et les adapter aux situations individuelles. De nombreux problèmes sont à résoudre pour atteindre et obje tif, liés entre autre à la représentation et la re onnaissan e du ontexte de travail et aux mé anismes d'adaptation. Dans e mémoire, nous abordons deux problèmes parti uliers on ourant à laréalisationde l'obje tif général :

1. Adapter l'ar hite ture : l'appro he proposée dans [Bouthier, 2003℄ est basée sur une ar- hite ture pair-à-pair. Adapter ette appro he au asde LibreSour e supposede revisiter ette ar hite ture pour intégrer unserveur entralisé.Ceserveurdétient ungrandnombre d'informations sur l'état du projet et les a tivités en ours, et produit des événements permettant de suivre l'a tivité. Le serveura don un rle parti ulier, et ne peutpas être onsidéré omme les autres lients. Il faut don proposer une ar hite ture fon tionnelle re onnaissant e rle parti ulier.

2. Agréger les événements sur le serveur : omme nousl'avons présenté i-dessus, le serveur produitungrandnombred'événements.L'appro heproposéedans[Bouthier,2003 ℄sebase entre autre surl'agrégation des événements àla sour e (sur les diérents lients) pour en diminuer le nombre et améliorer leur niveau sémantique. Le serveur étant lui même une sour e importanted'événements, ilest né essairedeledoterd'unmé anismed'agrégation de es événements.

Les deux hapitre suivant sont onsa rés à la proposition de solutions pour es es deux problèmes.

(17)

L'ar hite ture fon tionnelle

3.1 Introdu tion

L'ar hite ture fon tionnelle qui a été proposée dans [Bouthier,2003℄ est basée sur une ap-pro he égal-à-égal:il n'ya pasde serveur entralisé jouant un rleparti ulier. Lesappli ations des utilisateurs ommuniquent dire tement et il n'y a pas de gestion entralisée des onnais-san es.

Au ontraire,LibreSour eestuneplateformebaséesurunserveur entraliséedétenantunegrande quantité de onnaissan e surl'étatdesprojetshébergésetproduisantdesévénementsindiquant tousles hangementsettransitions dansl'état de es projets.

Ce hapitreapourobjetdeproposerunear hite turefon tionnellede ons ien edegroupepour les plateformes oopératives utilisant une gestion entralisée de l'état desprojets, à l'image de LibreSour e.Cettear hite tureadapteà e adrel'appro hede[Bouthier, 2003 ℄.L'aport prin i-pal onsisteàrépartirlesdiérentesétapesproposéesentreleserveuretles lients,etàidentier les oordinations né essaireentre es étapes.

3.1.1 Groupe ommuni ation dans le Web

Puisque notre ar hite ture adaptée à la plateforme oopérative sur Internet,les lients web peuvent oordonnerleurtravailet ommuniquerfa ilement.Danslewebla ommuni ationtombe dansdeuxtypes:

1. Syn hronous: e typede ommuni ationseréalise quandlesutilisateursdu même groupe sont en ligne au même temps, pour que les membres sa hent qui esten ligne, un message de noti ation est envoyé à tout le groupe haque fois qu'un membre se onne te ou se dé onne te de sasession. Quand lemembre est en ligne il peut envoyer un-ligne message à un autre membre qui aussi est en ligne[Fitzpatri ketal.,1999℄. Il peut aussi faire des onversationstemporel( hatting)[Steineld etal.,1999 ℄parunJavaappletà haquepage. 2. Asyn hronous: e typepasse auxutilisateurslesinformations surles hangementsdansle workspa epar email, ou par atta her les hangementsré entsà haque objetdansleweb page, etles membres peuvent onne ter en utilisant un mailing list [Lib,2005℄, un email est envoyé au listed'adresse.

Lesmembres de groupe peuvent utiliser desmoyensde ommuni ation pour être ons iente auworkspa e oopératif.

(18)

3.2 Ar hite turePair-à-Pairpourla ons ien edegroupe ontex-tuelle

Lesoutilsde ons ien edegroupetraitant desévénementssont engénéralorganisés endeux grandes parties : la partie émettri e et la partie ré eptri e. La partie émettri e d'un outil ol-le telesinformationsetlesdiuseauxmembresdugroupe.Cesinformationssont reçuespar les partiesré eptri es desautres outils, quiprésentent esinformations àleurs utilisateurs.

Dans [Bouthier, 2003℄, ette ar hite ture de base est étendue par des modules utilisant une représentation du ontextede travailde l'utilisateurpouragréger etadapterlesinformations de ons ien edegroupe.Trois étapessontajoutées:uneétaped'agrégationetuneétapedeltrage surlapartie émettri e, une étaped'adaptation surla partie ré eptri e.

Cesétapesutilisentunereprésentationdu ontextedetravailde l'utilisateurfondéesurune mo-délisationprobabilistedestâ hesetdu omportementdel'utilisateur.Cettemodélisationpermet dedéduire l'a tivité ouranted'un utilisateurà partirde l'observation desévénements produits dans son environnement. Elle permet également de déduire d'autre informations sur son om-portement, par exemple son degré d'attention, les relations qu'il rée ave les autres membres dugroupeet ...Lesinformationsdehaut niveau déduitesàpartirdesévénementsdebasniveau onstituent le ontextede travail del'utilisateur.

Cettear hite ture, présentée danslagure(3.1), proposelesétapes suivantes:

1. Colle tion: olle terdesinformationsbasniveausurle ontextedetravailde haque utilisa-teur, esinformationssontobtenuessoitautomatiquementparl'outilsoitparinterrogation de l'utilisateur. L'outil doit apturer le plus d'informations possible pouvant donner des indi ations sur l'a tivité de l'utilisateur. La olle tion des informations dépend aussi de la fréquen eave laquelle l'information est olle tées. Certaines informations sont sus ep-tibles de hanger à tout moment, etdoivent être apturées fréquemment. Par exemple la fréquen e des li ssouris. Certainesinformations ne sont disponibles qu'ave l'ajout d'un materialspé ique. C'estparexemple dessensoroudesweb ampour apturerlesregards ou les gestes.

2. Agrégation : agréger les informations de l'étape pré édente de telle façon à obtenir des informations réduites etdeplus haut niveau.

L'outil les agrège en répondant aux questions suivantes : où dans une seule information haut niveau.

L'outil utilisedesréseauxbayésiens[Charniak, 1991 ℄,[Horvitzetal.,1998 ℄ pour modéliser le omportement de l'utilisateur. Un réseau bayesien permet de représenter des onnais-san es in ertaines sur un phénomène omplexe. Il onsiste à relier des événements obser-vables àune ou plusieurs ausesprobables de es événements. Ensuite, unoutil de raison-nement probabiliste permet, àpartir d'uneséquen e observée d'événement, de déduire les ause probables de ette séquen e. Ce raisonnement revient don à agréger un ensemble d'événementsobservésenleur ause probable.

L'outilutiliseplusieurs anauxd'agrégation orrespondantàdiérentesfa ettesdu ontexte de travail :qui,pourquoi, quand,quoi, omment. Chaqueévénement observé estfournir à l'entré de ha un des anaux. La sortie de haque anal produit des événements de haut niveau ara téristique ha un d'unefa ette du ontexte.

(19)

ha un.Late hniquequiestutiliséedans[Bouthier, 2003℄pourfaireleltrageest onsisteà étiqueter les informations produites par l'étape d'agrégation, puis àprendre une dé ision. L'étiquetage est réalisé en se basant sur les informations ontenues dans le ontexte de travail,etpour haquedestinatairepotentiel.Sur labasede esinformations, unedistan e est al ulée. Cette distan e permet de déterminer le niveau de détail des informations à transmettre au destinataire. Ceniveau peutvarier de au un détail àtous les détails. 4. Diusion : le but de ette étape est diuser les informations de l'étape pré édente aux

personnes on ernées.

5. Ré eption :le but de ette étape estde re evoir des informations etles sauvegarder pour lespasseràl'étapesuivante.Lorsquel'utilisateurestdé onne té,ilnepeutpasre evoirles informationshautniveaudesautresmembresdugroupe.Cesinformationssontsto kéesdu tédel'émetteurdansuntampond'attente.dèsquel'utilisateurestdenouveaua essible sur leréseau,toutes les informationsen attente sontenvoyées dansunmessage unique. 6. Adaptation :lebut de ette étape estd'adapterles informations de l'étape pré édente au

ontexte de travail du ré epteur. Comme dans l'étape de ltrage, la te hnique onsiste à étiqueter les informations reçues pour ensuite prendre une dé ision on ernant la visuali-sation. Cet étiquetagesebasesur:

 Lesinformations reçuesdes utilisateursdistants,

 Le ontextedetravaildel'utilisateur, esinformationssontreçuesdel'étaped'agrégation surlama hine lo ale.

 Desinformations surlarelation entre l'utilisateur ré epteuretl'émetteur.

L'étiquetage onsisteà déterminer unevaleur ara térisant le niveau d'intrusionà utiliser pour présenter l'information. Cinqvaleurssont prévues:

 (-1)signie queles informationsne sont paspertinentes, et sontdon oubliées,

 (0) signie que les informations sont pertinentes mais e n'est pas le moment pour les presenter au lient; elles sont don onservées etla valeur est re al ulée à un moment ultérieur,

 (1,2,3)signient queles informationssont pertinentesetdoivent êtreprésentées à l'uti-lisateur. La valeurdésigne un degré d'intrusion à utiliser pour présenter l'information : peu intrusif (à sa demande uniquement) s'il s'agit d'une information non ru iale, de façon périphérique (par exemple dans un panneau de ontrle), présentation normale s'ils'agit d'uneinformation passusamment importante pour interrompre l'utilisateur danssatâ he ourante,outrèsintrusif(parexemple unefenêtre d'alerte)s'ilestjustié d'interrompre l'utilisateur danssatâ he.

7. Présentation :en ette étape l'outildé ide lafaçon dont l'information vaêtrereprésentées enfon tion du ontextedetravaildel'utilisateur.Elle onsisteàmettreen orrespondan e les valeursd'adaptation ave un mode d'intera tion ave l'utilisateur.

8. Visualisation :lebut de etteétape de presenter les informationsauxutilisateurs.

L'étaped'agrégation réduitlenombredenoti ationsenagrégeant lesévénementsetl'étape deltrageréduit lenombredesinformations enltrant lesinformations non pertinentes.

L'outil utilise le ontexte de travail pour adapter la ons ien e de groupe à l'a tivité de l'utilisateur.Ce ontexte detravail estutilisé à plusieurs étapes:

 L'étape d'agrégation :transformerles informationsde basniveau en informationsdehaut niveau moinsnombreuses, ara téristiques del'a tivité etdu ontextedetravail de

(20)

l'utili-Fig. 3.1L'ar hite ture fon tionnelledansle P2Pmodèle [Bouthier,2003 ℄

 L'étape de ltrage:le ontextede travail estutilisé pour déterminer quellesinformations doivent êtrediusées età qui.

 L'étape de l'adaptation : l'outil détermine le niveau d'intrusion ave lequel l'information doit êtreprésentéeà l'utilisateur selonson ontexte detravail.

3.3 Une ar hite ture fon tionnelle in luant un serveur

Nousproposonsuneextensiondel'ar hite turefon tionnelleprésentée i-dessuspourintégrer unserveurorantune gestion entraliséed'un ertainnombred'informations relativesauprojet supportée.Notre ar hite ture est répartie entre les lients et leserveur. La gure (3.2) montre omment lesétapesde ette ar hite ture sont réparties et omment esparties interagissent. Cetar hite ture a été onstruite en tenant ompte des onsidérations suivantes :

 les informations disponibles sur leserveur sont omplémentaires e elles que l'on est a-pable de déduire sur les lients à partirde la modélisation probabiliste du omportement desutilisateurs.Leserveurdisposed'informationsrelativesàl'exé utiond'a tivitéprévues et formalisées dans le projet : tâ hes et leur en haînement, stru ture organisationnelle, do uments partagés. Le lient quant à lui pourra obtenir des indi ations sur le ontexte d'usage de l'utilisateur (lieu, instruments d'intera tion) et son omportement (attention, a tivité réelle...).

 leserveurproduitbeau oup d'événements, qu'il estné essaired'agréger,

 l'adaptation au ontexteindividuel reste né essaireetdoitsefaire sur haque lient,  ilfautessayerdeminimiserlesé hangesentre lientsetserveur.D'unepartpourminimiser

(21)

l'étape d'agrégation sur les lients.

 la mise en orrespondan e des informations et des destinataires est plus simple à faire surleserveur, puisque elui- idisposed'informations plus omplètes etformalisées surles relationsentrelesmembresdugroupe:stru tureorganisationnelle(parexemple,hiérar hie deresponsabilité),liensliésàdesdépendan esd'a tivité(parexemple,unutilisateurattend lerésultat d'unautre), do umentsou ressour espartagés.

Fig. 3.2 l'ar hite ture fon tionnellepourle lient/servermodèle

Lesétapesproposées dans ette ar hite ture sont détaillées danslasuite.

3.3.1 Colle tion

L'outil olle te des informations sur le serveur et sur le lient. Sur le lient l'outil olle te lesinformations importantes pour ara tériser le ontextedetravail individueldu lient: appli- ations ourantes,  hier ouverts,les fréquen e de frappe lavier ou de li ks souris, la date de haque a tion et ...

Lesinformationssur leserveursont dedeux formes:

 Desinformationspersistantesetstatiquesdéniesàla ongurationduprojet,etévoluant peu : omposition des groupes, hiérar hie, a tivités prévues et ressour es ae tées à es a tivités.

 Des informationstrès dynamiquesliéesàl'exé ution d'a tions surleserveur, ara térisées par desévénements disponibles.

Dans LibreSour e les informations statiques orrespondent au ontenu de l'arbre de res-sour es.Lesinformationsdynamiques orrespondentauxévénementsproduitsparlesopérations exé utéessur lesressour es. Ces événementssont olle tés dansunequeue persistante.

(22)

3.3.2 Filtrage

Dans le serveur beau oup d'événements sont produits lors de la réalisation d'une a tivité omplète.Cetteétapede ltrage onsisteà masquerles événementsquine sontpasintéressants ousigni atifs de façon àalléger l'étaped'agrégation.

3.3.3 Agrégation

Ellesepassesurle téduserveur,etsurla tédu lient.Surle tédu lient,l'agrégation estréalisée ommeprésentéepré édemment,en utilisant desréseauxbayesiens. L'agrégation du téserveurfait l'objetdu hapitre suivant etutilise une te hnique diérente.

3.3.4 Répartition

Cetteétape,pla ée surleserveur,détermineàquilemessagedenoti ationdoitêtreenvoyé etleniveau de détaildesinformations quiviennent de l'étape pré édente.

Les ritères qui ae tent lepro essusde répartitionsont les suivants:

 quandl'utilisateur réeune ressour e,ilest lepropriétairede ette ressour e.Il peut don-ner des permissions d'a ès ou d'exé utions d'opérations sur ette ressour e aux autres utilisateurs, par e qu'il penseque e membredu groupe va avoir besoin d'a éder a ette ressour e:"IletyouseewhatIwantyoutosee".L'outiln'envoiepasdemessagede noti- ation auxutilisateursn'ayant au unepermissionsurlaressour eorigined'unévénement.  si l'utilisateur adéjà utilisé e ressour e plusieurs fois.

 larelationentrele lientetl'utilisateurdanslahiérar hiedegroupeetlalistedepersonnes pro he du lient. Normalement l'outil envoie aux personnes qui sont au même niveau. L'outil envoieaussiauxpersonnespro hesdu lient.

 quelquefois on donne des priorités aux membres de passer tous les événements de es membres àtous lesmembres degroupe ommele hef degroupe.

 Dansleservi eWebl'utilisateur peutdéterminerparunltragequelssont lesévénements qui luisont intéressantsetil va re evoirseulement les événement selon e ltre.

3.3.5 Noti ation

Aprèsavoirdéterminélesdestinatairesd'uneinformation,l'étapedenoti ationréalise l'a he-minementee tifdel'informationversles lients.Cetteétapedéterminelemoded'a heminement àutiliseren fon tion de l'étatde l'intera tion entre le lient etleserveur.

3.3.6 Adaptation et Visualisation

Le rle de es étapes est in hangé par rapport à l'ar hite ture de départ. Elle onsiste à adapterlaprésentation desinformationsenfon tion du ontextedetravail individuelde haque utilisateur.

(23)

L'agrégation sur le serveur

4.1 Introdu tion

Comme nous l'avons vu, dans LibreSour e les événements qui se dé len hent surle serveur sont nombreux. Nous avons mis en eviden e une étape d'agrégation sur la partie serveur. Ce hapitre est onsa ré à la on eption d'un mé anisme d'agrégation d'événements à mettre en oeuvre surlapartie serveur del'ar hite ture.

4.2 Choix de la te hnique d'agrégation

Pour on evoir le mé anisme d'agrégation d'événement surle serveur, nousdevons d'abord hoisir une te hnique d'agrégation.

Surlapartie liente,l'agrégationestfaiteenutilisantlate hniqueproposéedans[Bouthier, 2003℄, baséesur l'utilisation de réseaux bayesiens. L'agrégation estréalisée au travers de plusieurs a-naux, ha un ayant laresponsabilitéde répondreà unedes questionssuivantes :

 Quoi :quel estletype d'a tivité ee tuée?  Qui :qui afait ette a tivité?

 Quand :quand ette a tivités'estproduite?

 Où:où etsurquel ordinateur a tivités'estproduite?

 Comment :quel sontles objets utiliséepour réaliserl'a tivité?  Pourquoi:dansquel adrel'a tivité est-elle-ee tuée?

Les réponses des anaux sont agrégées ensemble dans une seule information haut niveau. L'utilisationdu raisonnement probabilisteetdesréseaux bayesiens sejustiepar l'aspe t in er-taindulienreliantlesévénementsobservésàleurs ausespossibles.Unévénementpouvantavoir plusieurs auses, y omprisdes auses nonidentiées, il estdi ile dedé ider de sa auseréelle defaçon sure.

Dans LibreSour e, par ontre, il n'y a au une in ertitude. Chaque événement à une ause unique et parfaitement identiée puisque un événement est asso ié à une opération sur une ressour e.Lespropriétésdel'événement ara térisentdemanièredéterministelaressour eorigine del'événement.

Par ailleurs, lorsqu'un lient demande l'exe ution d'une a tivité, ette exe ution peut onduire à la produ tion de plusieurs événements sur diérentes ressour es. Par exemple pour l'a tivité " reate workspa e" lesévénements suivantssedé len hent surleserveur:

(24)

- Kernel. reate - Kernel.bind - Kernel. reateA l

- LibreSour e.workspa e. onne tion. reate

A tuellement, le serveur notie les lients de es événements en envoyant inq messages, et 'estl'utilisateur quidoit agréger esévénements etdéduire àpartir d'euxqu'un espa e de tra-vail aété réé. Cependant ette séquen eest onnue d'avan e:pour haquea tivité, l'ensemble d'événements produit peutêtre identié, etil sera toujours le même pour haque exe ution de l'a tivité.

Nouspensons don quel'utilisation d'unete hniqueprobabiliste àbasederéseauxbayesiens n'est pas utile ni justiée : une séquen e d'événements observés permet de déterminer exa te-ment, de manière ertaine et unique, l'a tivité qui en est la ause et l'ensemble de ressour es on ernés. Le problème de l'agrégation onsiste don en la re onnaissan e de séquen es ou de motifs identiés d'événements. Pour réaliser ette re onnaissan e, nous proposons d'utiliser la te hnique desévénements omplexes (CEP) proposéepar [Lu kham, 2001 ℄.

4.3 Les événements omplexes

Un événement omplexe est une agrégation d'autre événements. Les événements membres d'unévénement omplexepeuventêtredesévénementsquiseproduisentàdiérentsmomentset dansdes omposantsséparés dansle système. L'événement omplexe est un événement de plus haut niveau que ses membres, qui permet d'avoir une vue abstraite des a tivités au sein d'un système. En d'autre terme, un événement omplexe est une abstra tion pour l'ensemble de ses événements membres.

Lesrelations entreles événementspeuvent être:

1. Temporelle:l'événement Aestavantl'événement BsiAseproduitavantBselonl'horloge du système.

2. Causalité : la relation entre A et B est ausale si la produ tion de l'événement A est né essaire pour quel'événement Bseproduise.

3. Agrégation : Si l'événement A est une a tivité qui onsiste en ensemble d'événements B1,B2,B3,... alorsA estuneagrégationde toutévénement Bi.Enrevan he lesévénements Bi sont desmembresde l'événement A.

4.3.1 Le Traitement des événements omplexes

Un événement omplexe est déni par une règle d'agrégation qui onsiste en un motif à re onnaître.Unévénement omplexe est réélorsquel'onobserve unensembled'événementsqui re ouvrelemotifdénidanslarègled'agrégation.Lemé anismepourdesévénements omplexes omprend deux omposants :

 Les règles/motifs d'agrégation : un motif est déni par un ensemble d'événement et les relations entre esévénements:AND,OR, ausale,parallèleettemporelle. Larègledéni l'a tion qui va seproduire quandlemotif estre ouvert.

 Des Agents de traitement des événements(Event Pro essing Agents- EPAs) :les Agents sontdesobjetsquiexé utentlesrègles/motifsd'événements.Lesagentssontles omposants

(25)

4.3.2 La hiérar hie d'abstra tion des événements

La hiérar hied'abstra tion desévénementsest une stru turelogique quifait lelien entre :  les événements et a tivités ee tivement observables dansle système (événements de bas

niveau),

 lesévénementseta tivitésquel'onsouhaiteobserverdanslesystème(événementsabstraits de haut niveau).

Cette hiérar hie permet de ombler le fossé qui existe entre le niveau auquel on souhaite observer le omportment du système, et le niveau de produ tion réel des événements. Pour onstruire unetelle hiérar hie, ilest né essaired'identier

1. Le nombrede niveauxné essaire : haqueniveau onsisteen unedes riptiond'a tivitéset des événements orrespondant à esa tivités. Le niveau 1,niveau le plus bas ontient les événements produits dire tement par le système. Dans LibreSour e, il s'agit d'événement JMS ("Java MessageServi e").

2. Un ensemble de règles d'agrégation : à haque niveau, on dénit des règles d'agrégation qui permettent d'obtenir les événements du niveau ourant à partir des événements du niveau inférieur. Lesrègles d'agrégation sont ainsides règlesde transition deniveau dans lahiérar hied'abstra tion.

Lagure(4.1)montreunehiérar hied'abstra tiond'événements(partielle)pourunensemble d'événements dansLibreSour e. Auniveau 1 sont listés les événements observables dans le sys-tème,et les a tivités qui les produisent. Au niveau 2, es événements sont regroupéset mis en orrespondan eave desa tivitésdeplushautniveau.Lagure(4.2)détaillelarègled'agrégation quipermetd'abstrairel'a tivité"Créationd'unequeueSo6"àpartird'unensembled'événement duniveau 1.

L'annexe (A) donne une des ription de tous les événements dans LibreSour e, es événements forment le niveau 1 de notrehiérar hie. Le niveau 2 est omposé desa tivités quel'on souhaite observeretnotier auxutilisateurs. Sesexemplessont donnésdansl'annexe (C).

Par ailleurs, [Lu kham, 2001 ℄ propose un langage de des ription d'événement omplexe, nommé RAPIDEEPL.Nousutiliserons e langage pour exprimerdesrègles d'agrégation.

4.4 La mise en oeuvre

4.4.1 Les Agents de Traitement d'Evénements (EPA)

Un EPA est un objet qui réalise une (ou plusieurs) règle(s) d'agrégation. Il surveille un ensemble d'événements qui lui sont fournis en entrée an de déte ter ertains motifs. Un EPA ontient des règles basées sur des motifs et des variables lo ales dont les valeurs déterminent l'étatde l'EPA. Chaquerègle adeux parties:

 un motif d'événements,

 une a tion àdé len herlorsque lemotif est re ouvert.

L'agent exé utelesa tionslorsque larègle orrespondanteesta tivée. Lerésultatde l'exé ution d'unerèglepeutêtreun hangementdevaleurdesvariableslo alesoula réationd'unévénement du niveau supérieur. Chaque EPA orrespond à un seul thread de ontrle. Plusieurs EPAs peuvent s'exé uter parallèlement et ommuniquent en é hangeant desévénements.

(26)

...

Niveau 2

Niveau 1

Niveau

Activités

Types d’événement

créer So6 queue

créer workspace

libresourceSynchronizer.synchronizer.create

Kernel.create

Kernel.bind

libresourceFiles.file.download

libresourceSynchronizer.workspace.connection.create

Kernel.create

Kernel.bind

Kernel.create

Kernel.chown

libresourceSynchronizer.synchronizer.create

libresourceSynchronizer.synchronizer.edit

libresourceSynchronizer.workspace.connection.edit

libresourceSynchronizer.workspace.connection.updateLastTicket

...

...

...

libresourceSynchronizer.workspace.connection.create

libresourceSynchronizer.synchronizer.delete

libresourceSynchronizer.workspace.connection.delete

Les activités

sur le service

So6

Fig.4.1 Hiérar hie (partielle) d'abstra tiondansLibreSour e

libresourceFiles.file.download

libresourceSynchronizer.synchronizer.create

Kernel.create

Kernel.bind

AND

Pattern

AND Kernel.create AND

AND libresourceFiles.file.download

libresourceSynchronizer.synchronizer.create

Kernel.bind

Action

Create So6 queue

Variables

Types d’événement

Relation

URL throwedby, Date date, String args

URL fromResource, Srting eventtype , String servicename

Element

Declaration

(27)

4.4.2 La spé i ation des motifs

Le langage RAPIDEfournitun ertainsnombred'opérateurspour dé rireles motifs d'agré-gation.Nousen détaillonsdeuxi i :les opérateurs temporelsetles opérateursde répétition.

Les opérateurs temporels

 At(T1):lemotif est re ouvertpar toutévénement seproduisant au temps T1,

 After(T1) : lemotif estre ouvert par toutévénement seproduisant à untemps supérieur au temps T1,

 During(T1,T2) :le motif est re ouvert par tout événement seproduisant entre les temps T1 etT2.

L'opérateur de répetition

L'orpérateur de répétition permet de spé ier des motifs omportant plusieurs o uren es su essivesd'unmême événement. La formegénéraleest lasuivante:

[number of repetition REL relational operator ℄ P;

oùlesrelationnel operator spé ieunerelation entrelesévénementsrépétésetPestl'événement quiserépète. Parexemple :

1. [* REL -> ℄ reate;

indique unmotif onstituéd'un nombrearbitraired'o urren es del'événement "Create", reliés entreelle par une relation ausale,

2. [1..10 REL -> ℄ reate;

indique unmotif onstitué de10 o urren es del'événement "Create",reliésentreellepar une relation ausale,

3. [ I in 1..10 REL ~ ℄ reate;

indiqueunmotif onstituéd'unnombre omprisentre1et10d'o urren esdel'événement "Create", reliésentre elle parune relation quel onque.

4.4.3 Les lasses d'EPAs

Suivant leur rledans lahiérar hie d'abstra tion, on distingue deuxtypes(ou lasses) prin- ipauxd'agentsde traitement d'événements :les ltresetlesMaps.

Les ltres utilisent un motif pour ltrer un ensemble d'événement. Le ltre laisse passer uniquement les événements satisfaisant le motif. La sortie d'un ltre est un sous-ensemble des événements en entrée : unltre ne rée au un événement. Un ltre est utilisé pour éliminer les événements non signi atifs ou inutiles dansla ara térisation desa tivités de haut niveau. La gure(4.3) illustre la lasse ltre : les événements A,B,C sont des événements entrants etA,C sont lesévénements sortants.

(28)

1. ltrage surlenomdesévénements :la onditionportesurles nomsdes événements, 2. ltrage surle ontenu :la onditionportesurles attributs desévénements,

specification

interface

C(...)

B(...)

A(...)

A(...)

C(...)

Fig.4.3 interfa e of anevent pro essing agent lass MAP

Les Maps utilisent un motif d'événements pour agréger plusieurs événements en un seul de plushautniveau.Cet agentest réateurde nouveauxévénements. Lorsquelemotif estre onnu, la règle rée un nouvel événement ave l'a tion generate. La gure (4.4) donne un exemple d'agentmap.Cetagentreçoittroistypesd'événementsentrantsA,B,C(sondomaine)etproduit l'événement seq(A,B,C)en sortie.

specification

interface

C(...)

B(...)

A(...)

Seq(A,B,C)

Fig. 4.4Interfa e ofan event pro essingagent lassMAP

4.4.4 Les réseaux de Traitement d'Événement (EPN)

Unréseau detraitement d'événement (EPN) estunensembled'agents EPA onne tés.Il est représenté graphiquement omme un réseau dont les noeuds sont des agents EPAs et les ar s représentent la ir ulation d'événements dans le réseau. La onstru tion d'un EPN permet de diviserleproblèmedere onnaissan ed'événements omplexeenétapessimples.Pour onstruire unEPN, on doit onne terdes agents de typesltres ou maps de tellefaçon quela sortied'un agent soit l'entrée del'autre.

La gure (4.5) illustre la stru ture générale d'unEPN et la ommuni ation entre les diérents omposants. Les événements du système observé peuvent provenir de diérents omposants de e système. Par exemple on peut observerdes événements en provenan e du réseau, du SGBD ou du middleware. Le rle de la ou he d'adaptation est d'uniformiser la représentation des événements traités par les ou hes supérieures. Le rle de la ou he ltrage est de réduire le nombre d'événements en restreignant aux seuls événement signi atifs. Le rle de la ou he agrégationest deproduire unevue abstraite desa tivitésse déroulant dansle système.

Les diérents agents d'un réseau peuvent être distribués sur plusieurs sites. Une organisation habituelleestderéaliseruneagrégationlo alesur haquesitepuisd'agrégerlesvuesdesdiérents sitesen uneseule.

(29)

événements agrégés

Couche Filtrage

Couche Adaptation

Adapter

in

in

Adapter

filtre

filtre

O

T

C

R

S

T

N

A

B

A

I

Couche Agrégation

Bas niveau

Haut niveau

événements système

événements Adaptés

événements filtrés

Map

Map

Map

Fig. 4.5La stru ture deréseau de EPAsde [Lu kham,2001 ℄

1. Analysee a ed'événements:lesystèmeobservépeutproduiredenombreuxévénements. Ces événements sont ltrésleplus ttpossible pour éviterde sur harger les règles d'agré-gation.

2. Flexibilité :on peutajouteretsupprimer desagentsfa ilement dansl'EPN, 3. Présenter unevue globalede systèmesdistribués.

Connexion entre les agents

Les onnexionsentrelesagentsasso ientlesévénementssortantsd'unagantauxentréesd'un autreagent.Elles peuvent être dediérentstypes:

1. Connexion séquentielle:lesévénementssont onsommésl'unaprèsl'autre,dansl'ordreoù ils sont produits. La onnexion onserve l'ordre.

2. Connexion parallèle : l'ordre de produ tion n'est pas important pour la onsomation des événements.

3. Connexion gardé:la onnexionestsoumiseàlavalidationd'une onditionlogique portant sur les paramètres des événements en sortie. Les événements ne sont transmis à l'entrée onne tés quesila onditionestvalide.

4.4.5 La Classe EPN

La lasse EPN permet d'en apsuler un réseau de façon à le traiter omme un agent EPA. Ce i permet de réutiliser des réseaux omplets et permet de onne ter des réseaux à d'autres

(30)

AgentsEPAsouà d'autresréseauxEPNs.Lagure(4.6) illustrelastru tured'une lasseEPN.

out actions

in actions

Architecture Class

Filtre

Map1

Map2

Map3

Map4

Fig. 4.6Exemple de lasseEPN

4.5 Des événements omplexes dans LibreSour e

Nous proposons de réaliser le mé anisme d'agrégation d'événements dans le serveur Libre-Sour e sur la base sur la base de l'appro he dé rite i-dessus. La stratégie d'intégration de e mé anismedanslaplateforme LibreSour e estlasuivante:

 Les événements de niveau 1 sont les événements produits par la plateforme LibreSour e lors de l'exé ution d'opération surdes ressour es. Ces événements ont une représentation uniforme quelque-soit leur origine : e sont des événements JMS. Nous onservons ette représentation, e quinouspermetdenouspasserde la ou hed'adaptation (plus exa te-ment, 'esten faitLibreSour e quiréalise déjà l'adaptation).

 Comme tout servi e LibreSour e, le servi e d'agrégation est fourni sous la forme de res-sour es. On utiliseradeux typesde ressour esdansle servi ed'agrégation :les ressour es de type Filtre, et les ressour es de type Map. Chaque ressour e réée orrespondra à un agent de traitement d'événements.

 Comme touteressour e LibreSour e, les ressour esdu servi ed'agrégation produisent des événements.Cesévénements orrespondentauxopérationsee tuéessurlaressour e ( réa-tion, modi ation, suppression...)plus les événements desortie de l'agentsde traitement implanté parla ressour e.

 Un réseaude traitementd'événements(EPN)est déniparun arbrederessour esdu ser-vi ed'agrégation. La onnexionentrelesagentsest impli itement déniepar lahiérar hie de l'arbre: les événements produits par une ressour e sont onne tés à l'entrée de la res-sour e/agent immédiatement supérieure dansl'arbre. Les feuilles de l'arbre de ressour es du servi e d'agrégation sont onne tées aux queues d'événements persistants produisant lesévénementsdebaseLibreSour e. Lara inede etarbreproduitdesévénementsagrégés orrespondant à unevue abstraite desa tivitésse déroulant surle serveur.

(31)

1. l'intégration est uniforme ave les autres servi esLibreSour e et réutiliser les mé anismes existants. En parti ulier, un lient souhaitant être notié d'événements de haut niveau doit simplement sous rire à la queue d'événements asso iées à la ressour e d'agrégation qu'il hoisit. Le mé anisme de gestiondes queuesetde sous ription estdéjà présent dans la plateforme, et les lients n'ont pas à modier leur omportement pour béné ier de l'agrégation.

2. lesévénementsproduitsparuneressour ed'agrégationsontexploitablesexa tement omme tous les autres événementsdu système, autravers d'unequeue d'événementsasso iée àla ressour e.

3. lahiérar hied'abstra tionn'estpasgée.Lesressour esetlesréseauxd'agrégationpeuvent être réés et adaptés pour haque projet, voir même par haque lient. On obtient don une grande exibilité etune grande fa ilitéd'utilisation. Il estassez fa ilede rajouter des ressour es dansune hiérar hieexistante.

4. rien n'empè he de onne terdes événementsissus de plusieurs serveurs. Tousles serveurs présentant leurs événements de manière uniforme, on peutparfaitement envisager, même sinousnel'avonspasfait, de onne terdesévénementsissusd'unserveuràdesressour es situés surun autreserveur.

Nousdénissons maintenant lepro essusde réationdesressour esdans e adre.

4.5.1 Dénition des ressour es d'agrégation

DansLibreSour e, lepro essusde réationd'uneressour e estun pro essusintera tif quise dérouledansunepageWeb.Le réateurdelaressour e ongure etteressour eeninteragissant ave leserveur.Dansle asdesressour esduservi ed'agrégation,la réation/ ongurationd'une ressour e onsiste à réer et paramétrer un agent de traitement d'événements. Les paramètres prin ipauxsont :sapositiondansleréseaude traitement,sontype (ltre,map), lesévénements enentrée,lemotif asso iéetles événementsde sortie.

Ainsi,la réationd'uneressour ed'agrégation onsisteà ongurerlesparamètres suivants: 1. Nom de la ressour e : le nom de la ressour e est un hemin dans l'arbre des ressour es. Ce nomidentie la ressour e et a également pour eet de déterminer sa position dans le réseau dere onnaissan e. Lesévénementsissusde etteressour eserontautomatiquement fourni en entrée de laressour e mèredansl'arbre.

2. Type de la ressour e :ltre ou map. Ce hoix onditionne notamment les événements de sortie :sous-ensemblede l'entrée pour un ltre,événementsnouveauxpour unMap. 3. Événements en entrée : de manière impli ite, la position détermine dans l'arbre de

res-sour esdéterminel'ensembled'événementsfournisenentréepourlaressour e ommeétant l'ensemble des événements de sortie des ressour es lles. On peut ependant ajouter une spé i ation expli ite en indiquant des types d'événements à onsommer des les queues d'événementsde LibreSour e. Cette dénitionest utilepour :

 le asdesfeuilles de l'arbre,

 les as où on veutavoir a ès à des événements produits par des ressour esextérieures à l'arbreen ours dedénition. C'est don un moyen d'utiliser les événements de sortie d'une ressour e d'agrégation dans plusieurs autres ressour es d'agrégation. C'est aussi un moyen d'a éder à des événements produits par des ressour es situées sur un autre serveur.

(32)

4. Événements en sortie et règle d'agrégation : es événements sont spé iés par un motif de ltrage/map exprimé dans le langage RAPIDE. Une règle RAPIDE est entrée dansla ressour e etserainterprétée parle odeasso iéàlaressour e.Cetterègledoitindiquer les événements générés dansle asd'unMap ave la lause generatede RAPIDE.

Unexemple estmontrédansl'annexe (D).

4.5.2 Ressour es d'agrégation par défaut et prédénies

Le pro essus de réation d'un réseau omplet de traitement desévénements peut être om-plexeetdi ile.Pouralléger ettetâ henousproposonsdeuxsolutions omplémentaires: l'exis-ten ede ressour esd'agrégation par défaut etla possibilitéde prédénir desressour es d'agré-gationpour uneinstallation deLibreSour e.

Les ressour es d'agrégation par défaut sont des ressour es automatiquement utilisées par le système si un lient donné n'a a ès ou n'a réé au une ressour e d'agrégation dans son environnement.

Cesressour espardéfautréalisentl'agrégation d'événements orrespondant àquelquesa tivités habituelleset ara téristiquesd'une utilisation lassiquede laplateforme LibreSour e :

 réation d'unprojet,

 réation d'unespa e detravail,

 réation d'unequeue desyn hronisation,

 démarrage desa tivités prévuesdanslemodèle de workow ...

La listedesagrégations par défautestouverte.Nousavonsidentié etdé ritlesprin ipales, maisilest relativement aisé d'enrajouter.

Lesressour esd'agrégationprédéniessontdesressour esdéniespar l'administrateurd'une installationLibreSour e, quilesmets àdispositiondesutilisateursdelaplateforme,quipeuvent lesréutiliserdire tement sansavoiràlesre onstruireeux-même.Ladiéren eave lesressour es par défaut estque es ressour es ne sont automatiquement a tives, mais doivent être expli ite-ment réutiliséespar le lient quiveutenproter.

Ces2typesderessour essontfourniesdanslesystèmed'unemanièreanalogue:ils'agitd'un réseaudetraitement en apsuledansuneressour ed'agrégation detypeEPN.Ellesapparaissent don toujours ommeune ressour e unique,même si elles orrespondent à unréseau omplexe.

Unexemplepourfairel'agrégateurpour SO6etFilesservi es,la lassepour So6estmontrée enl'annexe (E)

4.6 La réalisation

Le adrede réalisation de e travailest laplateforme LibreSour e etlalangage de program-mationestJava2enterpriseEdition (J2EE). LibreSour eestdéployé surleserveurJEE JOnAS serveur. JOnAS est un serveurd'appli ation pur Java, open sour e, se onformant à la spé i- ationJ2EE, onstruit par le onsortium françaisObje tWeb.

Nous avons réé un nouveau servi e LibreSour e et implanté les ressour es asso iées. Pour l'instant, seule laressour ede type Filtrea éténalisée. Ceservi es ontient 2 modules: Libre-Sour eAggregator qui onteient les ressour es de types Map, et LibreSour eFilter qui ontient

(33)

lesressour esde typeFiltre.Lesa tionspossiblessur esressour essont lesa tions immunesà toutesles ressour es:

Module Name Servi e Ressour es A tion aggregator LibreSour eAggregator aggregator reate

LibreSour eAggregator aggregator edit LibreSour eAggregator aggregator delete

LibreSour eFiltrage filtrage reate LibreSour eFiltrage filtrage edit LibreSour eFiltrage filtrage delete

L'implantation d'une ressour e revient à réaliser un omposant parti ulier de onformant à une interfa e prédénie ommune à toutes les ressour es. La onformation à ette interfa e permetl'intégration de la nouvelle ressour e dansla plateforme.Il faut aussiréaliserl'interfa e de onguration de la ressour e qui permet de xer les paramètres de la ressour es lors de sa réation.

Du point de vue de la réalisation, le point di ile est la onstru tion de la ma hine d'inter-prétation des motifs RAPIDE. Nous avons seulement réalisé la partie onsa ré aux motifs de ltrage.

(34)

Cemémoireprésenteuneappro hepourl'agrégationdesévénementsde ons ien edegroupe dansune plateforme de oopération basée surun serveur. Nousavonsproposé dansun premier tempsunear hite turefon tionnelleinspiréedetravauxpré édents.Notrepropositionapour ob-je tifderéutiliseretdes'intégreraumieuxave lespropositionsdéjàfaitesdans[Bouthier,2003 ℄, touten prenant en ompte la spé i itéd'une ar hite ture lient/serveur par rapportà une ar- hite turepurementpair-à-pair.Mêmesinousn'avonspasen oreputesterl'intégrationee tive des2appro hes, nouspensons quenotre appro he est ohérente.

Dansundeuxième temps,nousavonsproposéuneméthoded'agrégation desévénementssur leserveur,ainsiquesastratégied'intégrationdanslaplateformeLibreSour e. Cetteméthodeest baséesurlanotionde traitement d'événements omplexe (CEP)proposée par [Lu kham,2001 ℄. Nouspensons que ette stratégie est mieuxadaptée auxbesoinsd'agrégation sur leserveurque ellequiaétéproposéedans[Bouthier, 2003 ℄.Ennl'intégrationdanslaplateformeLibreSour e aété relativement simple à partirdu moment où nousavons hoiside réaliserl'agrégateur sous laformede ressour es ommeles autres servi es.

Il reste beau oup detravail à réaliser, en parti ulier du point de vue de laréalisation. Pour l'instant, seule lesressour es pour leltrageont étéréalisées(et pas omplètement testées).

Notre première perspe tive on erne don la réalisation omplète du servi e d'agrégation dans LibreSour e. Un des intérêts du servi etel qu'il a été onçu est qu'il peut être utilisé tel quel,sansfor ément être omplétépar les autres étapesde l'ar hite ture fon tionnelleproposée dansle hapitre 3.

Notre perspe tive à moyen terme onsiste à réaliser les autres étapes de ette ar hite ture fon tionnelle que nous avons proposé. Si l'agrégation et l'adaptation sur le lient peuvent être réutiliséeàpartirdespropositionsde[Bouthier, 2003℄l'étapederépartitiondoitêtrerevuepour exploiterau mieux les informations et onnaissan es disponibles surle serveurà propos des re-lationsentreles parti ipants d'unprojet.

Enn, notreobje tif àlongtermeestde onstruire,surlabasede ette ar hite ture,un sys-tèmede ons ien ede groupe ontinue, 'estàdire apablede suivrel'utilisateurdansdiérents ontextes d'usage,etde s'adapterà haque ontexte.Ce iné essiteradeprendre en ompte une représentation plus large du ontexte de travail, en y in luant notamment des informations en provenan edel'environnement physique :lieu (bureau, sallede réunion,voiture ...),instrument d'intera tion (ordinateur debureau, PDA, téléphone)...

(35)

Les événements dans LibreSour e

Module Name Servi e Ressour es A tion

Kernel kernel (node) reate kernel (node) delete kernel (node) deleteURI kernel (node) bind kernel (node) unbind kernel (node) moveFrom kernel (node) moveTo kernel (node) hown kernel (node) reateA l kernel (node) deleteA l kernel (node) resetA ls kernel (node) setProperty

membership user edit membership user delete membership group reate membership group edit membership group delete membership group addMember membership group removeMember

Core LibreSour eCore symboli Link reate LibreSour eCore symboli Link edit LibreSour eCore template reate LibreSour eCore template edit LibreSour eCore timeline reate LibreSour eCore timeline edit LibreSour eCore proje t reate LibreSour eCore proje t edit

Figure

Fig. 3.1  L'arhiteture fontionnelle dans le P2P modèle [Bouthier, 2003 ℄
Fig. 3.2  l'arhiteture fontionnelle pour le lient/server modèle
Fig. 4.1  Hiérarhie (partielle) d'abstration dans LibreSoure
Fig. 4.4  Interfae of an event proessing agent lass MAP
+5

Références

Documents relatifs

Les objectifs principaux de ce programme étaient : - de protéger la population européenne d’Érismature à tête blanche en éradiquant l’Érismature rousse du Royaume-Uni ;

I Cette méthode de capture manuelle qui cible les adultes et juvéniles de Grenouille taureau a été testée pendant 3 ans, de 2007 à 2009, sur deux sites d’étude récemment

[r]

L’adresse fournie par l’envoyeur sur le champ Disposition-Notification-To DOIT être capable de recevoir des messages MDN de la [RFC2298] et DEVRAIT être capable de recevoir des

lunette allumette cachette poussette omelette raquette galette fourchette lunette trompette brouette assiette roulette sonnette.. la mienne la tienne antenne Il

Si vous devez corriger les données de base (données de contact, offres de prestations, informations supplémentaires ou paramètres de calcul), vous devez débloquer de nouveau

 Pompe volumétrique : Transmission de l'énergie cinétique du moteur en mouvement de va-et-vient..  Pompe

Cette phrase montre que Solvay prend appui sur son référentiel de compétences dans son nouvel accord de GPEC pour saisir les différentes sources de compétences : lors de la