Mod`ele de services P2P

La finalit´e du mod`ele P2P est de fournir `a des usagers un service d’une mani`ere distribu´ee. La mod´elisation des informations de gestion des services P2P est donc un point crucial d’une infrastructure de supervision d’applications P2P. D’apr`es le mod`ele Core de CIM, un service est une fonctionnalit´e fournie par un ´el´ement logiciel ou mat´eriel. D’apr`es cette d´efinition, un service peut ˆetre, par exemple un logiciel de traitement de texte ex´ecut´e sur un ordinateur, une application cliente de courrier ´electronique ou un service d’impression. Certains services sont locaux `a la machine qui les utilise alors que d’autres sont distants et accessibles par le r´eseau. Pour repr´esenter cette caract´eristique, CIM utilise la notion de point d’acc`es qui repr´esente la mani`ere d’acc´eder `a un service. Par exemple, dans le cas d’une application de messagerie ´electronique, le point d’acc`es du service est l’adresse protocolaire utilis´ee pour retirer les courriers du serveur.

La figure 5.6.a repr´esente les classes CIM du mod`ele de services tel qu’il est d´efini dans le mod`ele Core. La classe CIM Service repr´esente un service d´efini `a travers des fonctionnali-t´es logiques. C’est pourquoi elle h´erite de la classe CIM EnabledLogicalELement. Un service se caract´erise principalement par son nom (Name), les coordonn´ees d’une personne physique ou morale responsable de ce service (PrimaryOwnerName et PrimaryOwnerContact), et surtout deux m´ethodes qui permettent, par le biais de la gestion, de d´emarrer (startService()) ou arrˆeter un service (stopService()) ; l’´etat r´esultant ´etant mentionn´e dans l’attribut Started. Deux classes d’auto-association permettent de repr´esenter la composition de service (CIM ServiceComponent) et la d´ependance d’un service par rapport `a un autre (CIM ServiceServiceDependency). Les diff´e-rentes associations entre la classe CIM Service et CIM ManagedElement repr´esentent la mani`ere dont l’ex´ecution d’un service d´epend et se r´epercute sur un ou des ´el´ements administr´es.

Ensuite, la classe abstraite CIM ServiceAccessPoint mod´elise un point d’acc`es particulier pour un service donn´e, repr´esent´e particuli`erement par son nom (Name). Cette classe est g´en´erique, et des points d’acc`es concrets sont d´ecrits dans ses sous-classes, comme c’est le cas des classes CIM ProtocolEndpoint, CIM ServiceAccessURI ou CIM RemoteServiceAccessPoint. Enfin, la classe d’association CIM ServiceAccessBySAP met en relation un service et ses points d’acc`es, et la classe CIM ServiceSAPDependency repr´esente la d´ependance entre un service et ses points d’acc`es. Nous ne d´ecrivons pas plus en d´etail le mod`ele de services de CIM. Des informations compl´ementaires

5.3. Proposition d’un mod`ele de l’information de gestion

ServiceAccessPoint

CreationClassName: string {key} Name: string {override, key}

ServiceAccess BySAP

*

*

(See Core Model (Overview))

ManagedElement

*

*

(See Core Model (Overview))

EnabledLogicalElement ServiceAvailableToElement ProvidesServiceToElement (D) ServiceAffectsElement ServiceSAP Dependency ParticipatingPeers HostedP2PService P2PServiceParticipatingPeers

*

CreationClassName: string {key} Name: string {override, key} PrimaryOwnerName : string {write} PrimaryOwnerContact : string {write}

StartMode: string (10) {D, enum}

Started: boolean StartService(): uint32 StopService(): uint32 ServiceService Dependency

*

*

*

*

*

*

*

*

*

*

*

*

*

(See P2P Model (Peer and Community))

Peer

1..n

*

(See P2P Model (Peer and Community)) Community 1..n 1 1 P2PServiceAccessPoint

*

*

*

*

*

*

*

Fig. 5.6 – Diagramme de classes CIM du sous-mod`ele P2P de services. (a) Classes issues du mod`ele Core. (b) Classes du sch´ema d’extension P2P.

sont disponibles dans [40, 18].

Diagramme de classes CIM du mod`ele de services P2P

La d´efinition de service propos´ee par CIM le d´ecrit comme ´etant centralis´e. Dans le cadre d’un mod`ele P2P, nous avons ´etendu cette d´efinition pour consid´erer l’aspect distribu´e du mod`ele et proposons la suivante : Un service P2P est une fonctionnalit´e logicielle distribu´ee fournie et ou consomm´ee par un ensemble de pairs appartenant `a une mˆeme communaut´e.

La d´efinition d’un point d’acc`es `a un service P2P est identique `a celle propos´ee dans le mod`ele Core. Plus pr´ecis´ement, dans le cadre du mod`ele P2P, un point d’acc`es repr´esente l’adresse d’un pair qui permet de joindre une communaut´e. Par exemple, dans le cadre des DHTs, on parle souvent de pair amorce, qui permet `a d’autres de s’ins´erer, et dans le cas d’applications de partage de fichiers ou de Jxta, c’est une liste de pairs connus, maintenue et ´eventuellement publi´ee sur le Web.

Etant donn´es ces concepts, nous avons con¸cu le sous-mod`ele de services repr´esent´e sur la figure 5.6.b. Tout d’abord, nous avons d´efini la classe abstraite P2P P2PService qui h´e-rite de la classe CIM Service et qui repr´esente un service P2P dans sa globalit´e, tel un ser-vice travail collaboratif. Nous n’avons pas ajout´e de propri´et´e `a cette classe car celles d´efi-nies dans la classe CIM Service nous ont sembl´ees suffisantes et, l’objectif de cet h´eritage est, d’un point de vue de l’information de gestion, de diff´erencier la s´emantique d’un service CIM standard, d’un service P2P tout en restant g´en´erique. De plus, dans le cadre d’une instan-ciation sur une infrastructure concr`ete, des attributs sp´ecifiques peuvent ˆetre ajout´ees `a des sous-classes de P2P P2PService. Ensuite, avec la mˆeme d´emarche, nous avons ajout´e la classe abstraite P2P P2PServiceAccessPoint qui repr´esente un point d’acc`es `a un service P2P. Une de ses sous-classe concr`ete est P2P PeerAccessPoint. Elle se caract´erise par l’identifiant du pair (PeerId) qui permet l’acc`es `a un service. On peut en outre envisager d’autres m´ethodes d’ac-c`es `a un service, comme par exemple une adresse P2P anycast. Les classes P2P P2PService et P2P P2PServiceAccessPoint sont li´ees grˆace `a la classe d’association P2P P2PServiceAccessBySAP qui associe un service P2P `a son ou ses points d’acc`es ; un point d’acc`es pouvant ˆetre attach´e `a plusieurs services P2P.

Le second point qui nous a sembl´e int´eressant est la mani`ere dont un service est distribu´e dans une communaut´e. Pour cela, nous avons ajout´e deux classes d’association `a ce mod`ele. La premi`ere, P2P HostedP2PService permet, en accord avec notre d´efinition de service P2P, d’identifier la communaut´e `a laquelle un service appartient. D’un point de vue des cardinalit´es, on voit qu’un service appartient `a une et une seule communaut´e, alors qu’une communaut´e regroupe z´ero ou plusieurs services. La seconde association, P2P P2PServiceParticipatingPeers met en relation les services et les pairs qui y participent. Un service peut ˆetre ex´ecut´e par z´ero et plusieurs pairs et, de mˆeme, un pair peut participer `a z´ero ou plusieurs services. Par ce biais, une infrastructure de gestion peut identifier les diff´erents services d’une communaut´e ainsi que les pairs qui y participent.

Vue locale et vue globale d’un service P2P

Habituellement, un service est localis´e sur une machine particuli`ere. C’est par exemple le cas d’une application de traitement de texte qui r´eside sur un ordinateur personnel. Au pire, un service est situ´e sur un serveur distant, accessible par le r´eseau. Dans tous les cas, le service est une entit´e fonctionnelle fournie par un ´el´ement distinct. Par contre, dans le contexte P2P, un service est une fonction distribu´ee qui r´esulte de l’agr´egation d’instances particuli`eres ex´ecut´ees

5.3. Proposition d’un mod`ele de l’information de gestion

par des pairs. On voit donc qu’un service P2P peut ˆetre vu de mani`ere globale `a une communaut´e, mais aussi de mani`ere locale `a chaque pair. D’un point de vue de la gestion, il est important de distinguer ces deux niveaux d’abstraction car les informations qui leurs sont inh´erentes sont diff´erentes. Par exemple, consid´erons le cas d’un service de d´ecouverte de fichiers construit sur une DHT. D’un point de vue global, les informations de gestion int´eressantes vont porter sur le pourcentage de requˆetes accomplies avec succ`es, ou le temps moyen n´ecessaire au routage d’un message, le nombre moyen de sauts, . . . Par contre, d’un point de vue local, les informations vont porter sur la mani`ere dont un pair particulier ex´ecute le service, comme par exemple, le nombre total de requˆetes qu’il a re¸cues et fait suivre, le nombre de requˆetes qui lui ont ´et´e destin´ees, . . . Le mod`ele P2P pr´esente donc une vue `a deux niveaux des services et nous avons pris en compte cette sp´ecificit´e en int´egrant la classe P2P LocalP2PService `a notre mod`ele de services. Cette classe est reli´ee `a la classe P2P P2PService par le biais de la classe d’agr´egation P2P LocalServiceComponent et repr´esente un service tel qu’il est ex´ecut´e sur un pair particulier. A l’inverse, la classe P2P P2PService repr´esente un service vu dans sa globalit´e. Les cardinalit´es de l’association de ces deux classes stipulent qu’un service global est l’agr´egation de z´ero ou plusieurs services locaux alors qu’un service local n’appartient qu’`a une seule vue globale. De cette mani`ere, nous sommes capables de prendre en compte le caract`ere distribu´e des services P2P.