Mod`ele de l’organisation des pairs et des communaut´es

Dans le domaine P2P, un pair repr´esente un ´el´ement, ex´ecut´e sur une machine particuli`ere, d’une application distribu´ee construite selon une approche d´ecentralis´ee. Une telle application peut couvrir des domaines tr`es vari´es, du calcul distribu´e `a la diffusion de contenu multim´edia. Le service, tel qu’il est offert et consomm´e, provient de l’agr´egation des pairs et de la mise en commun de leur ressources dans ce contexte particulier. Afin de repr´esenter le regroupement de pairs autour d’un int´erˆet commun, on utilise le terme de communaut´e [119]. Une communaut´e est un ensemble de pairs participant `a un ou des services communs.

P1 _P2 P3 P1 _P2 P3 P1 _P2 P3 P2 P3 P3 (a) (b) (c) (d) P5

Fig. 5.3 – Exemples de cas repr´esentables avec le mod`ele organisationnel. (a) Une commu-naut´e contient plusieurs pairs. (b) Une commucommu-naut´e contient une sous-commucommu-naut´e. (c) Un pair appartient `a plusieurs communaut´es. (d) Un ordinateur ex´ecute plusieurs applications P2P.

La figure 5.3 repr´esente diff´erents cas de relations qui peuvent apparaˆıtre entre des pairs et des communaut´es. Tout d’abord, la figure 5.3.a illustre le fait qu’une communaut´e contienne un ensemble de pairs, allant de un `a plusieurs. Nous consid´erons qu’une communaut´e vide ne peut exister, car le concept de communaut´e est simplement l’abstraction du regroupement de pairs dans le cadre d’un service. Ainsi, si aucun pair n’existe, aucun groupement non plus, et donc aucune communaut´e. Ensuite, la figure 5.3.b montre qu’une communaut´e peut contenir des sous-communaut´es, et qu’un pair peut appartenir simultan´ement `a une communaut´e ainsi qu’`a ses sous-ensembles. C’est par exemple le cas d’une application de discussion o`u un pair appartient `a la communaut´e des utilisateurs du client d’une communication et `a diff´erentes sous-communaut´es qui repr´esentent les sujets de discussion auxquels il s’est abonn´e. La figure 5.3.c montre qu’un pair peut aussi appartenir simultan´ement `a des communaut´es diff´erentes et

disjointes. Ce cas s’illustre par l’exemple d’une plate-forme de service comme OSGI⁹ ou Jxta [119]. Celle-ci peut accueillir et ex´ecuter diff´erents services P2P au sein de son infrastructure, et ainsi repr´esenter un pair appartenant `a plusieurs communaut´es. Enfin, la figure 5.3.d consid`ere le cas o`u, au sein d’une machine particuli`ere, plusieurs applications P2P sont ex´ecut´ees, conduisant ainsi `a la repr´esentation de diff´erents pairs appartenant `a diff´erentes communaut´es.

Diagramme de classes CIM du mod`ele de l’organisation

Le mod`ele de l’organisation des pairs et des communaut´es que nous proposons est repr´esent´e sur la figure 5.4. Ce mod`ele est la racine de l’ensemble des autres mod`eles que nous avons int´egr´es dans notre sch´ema d’extension.

(See Core Model)

EnabledLogicalElement

System

CreationClassName : string {key} Name : string {override, key} NameFormat : string PrimaryOwnerName : string {write} PrimaryOwnerContact : string {write} Roles : string[ ]

ComputerSystem NameFormat {override, enum} OtherIdentifyingInfo : string[ ] IdentifyingDescriptions : string[ ] Dedicated : uint16[ ] {enum} ResetCapability : uint16 {enum}

PowerManagementCapabilities : uint16 [ ] {D, enum} SetPowerState (

[IN] PowerState : uint32 {enum}, [IN] Time : datetime) : uint32 {D}

ComponentCS

*

*

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

Community

CreationClassName: string {key} Name: string {override} PeerId: string {key} ArrivalTime: date Peer HostedPeer

*

NameFormat: string {override, enum} AdminDomain ContainedDomain

*

*

*

*

Fig. 5.4 – Diagramme de classes CIM du sous-mod`ele P2P de l’organisation fonctionnelle et topologique

Un pair est repr´esent´e `a l’aide de la classe P2P Peer. Il se caract´erise par son nom (Name)¹⁰, son identifiant (PeerId) et sa date d’arriv´ee (ArrivalTime). L’attribut CreationClassName permet, lors de l’instanciation d’un objet, de renseigner sur le nom de la classe effective de cr´eation d’un objet de type P2P Peer. Il est notamment utile pour distinguer plusieurs objets d’attributs identiques mais de classes, h´eritant de la classe P2P Peer, diff´erentes. En outre, un pair est un

9

Open Service Gateway Initiative - http ://www.osgi.org

10

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

´el´ement logiciel qui peut prendre diff´erents ´etats. C’est pourquoi, la classe P2P Peer h´erite de la classe CIM EnabledLogicalElement du mod`ele Core, introduite dans la section 5.2.4.

Une communaut´e de pairs est repr´esent´ee `a l’aide de la classe P2P Community. Cette classe pr´esente deux attributs qui sont son nom (Name) et son identifiant (CommunityId). La classe P2P Community h´erite de la classe CIM AdminDomain, d´efinie dans le sous-mod`ele de r´eseaux [42] du mod`ele Common, qui repr´esente un ensemble quelconque d’´el´ements appartenant `a un mˆeme domaine d’administration. Afin de couvrir l’ensemble des cas de figure d´ecrits dans la figure 5.3 de la section pr´ec´edente, nous avons choisi de lier la classe P2P Peer `a la classe P2P Community par le biais de la classe d’association P2P PeerParticipating. Sa cardinalit´e de type 1..n - 1..n indique qu’un pair peut appartenir `a une ou plusieurs communaut´es, et de mˆeme, une communaut´e contient au moins un pair. La notion de sous-domaine est prise en compte par la classe d’association CIM ContainedDomain qui relie la classe CIM AdminDomain `a elle-mˆeme. Sa cardinalit´e signifie qu’un domaine peut contenir z´ero ou plusieurs sous-domaines, de mˆeme qu’il peut ˆetre contenu dans plusieurs sur-domaines. Ce dernier cas ne semble pas envisageable dans le cadre d’une communaut´e P2P, mais, par souci de souplesse et de g´en´ericit´e, nous avons pr´ef´er´e conserver la classe CIM ContainedDomain plutˆot que de la sous-classer pour en restreindre la cardinalit´e.

Pour finir la description de ce mod`ele, nous pr´esentons la mani`ere dont nous associons un pair `a la machine qui l’h´eberge. Le sous-mod`ele de syst`emes [44] du mod`ele Common propose la classe CIM ComputerSystem qui repr´esente un ordinateur, et nous avons choisi de la lier `a la classe P2P Peer de notre mod`ele par le biais de la classe d’association P2P HostedPeer. Sa cardinalit´e indique qu’un pair appartient `a une machine, mais qu’une machine peut h´eberger z´ero ou plusieurs pairs. On peut noter que nous avons choisi de lier la classe P2P Peer `a la classe CIM ComputerSystem plutˆot que la classe CIM System, car la classe CIM ComputerSystem repr´esente un ordinateur, de la station de travail au cluster de machines, alors que la classe CIM System repr´esente simplement l’agr´egation d’´el´ements g´er´es, qui peut ˆetre dans ce cadre un domaine administratif ou une librairie de stockage.

Mod´elisation de la topologie virtuelle

Les applications P2P sont souvent construites sur un overlay de niveau applicatif. La topo-logie virtuelle que ce r´eseau engendre peut reposer sur diff´erents crit`eres relationnels. Elle peut ˆetre par exemple construite `a l’aide des tables de routage des pairs. On consid`ere alors qu’un pair P1 r´ef´erenc´e dans la table de routage d’un pair P2, est un voisin de ce dernier. Ce concept est celui retenu pour expliquer la construction topologique des DHTs. Cependant, la topologie peut aussi ˆetre construite selon un crit`ere de communication : deux pairs qui ´echangent des donn´ees sont consid´er´es comme voisins dans la topologie virtuelle. Enfin, la topologie peut aussi reposer sur la connaissance globale que des pairs ont des autres ind´ependamment des tables de routage. C’est, par exemple, le cas de Gnutella [84, 133] ou Freenet [26] o`u le fait de faire suivre un message dans lequel est indiqu´ee la source du message va permettre aux pairs situ´es sur le chemin d’ajouter le pair source dans leur table de r´ef´erences.

Dans notre mod`ele, nous avons choisi de repr´esenter les liens topologiques entre les pairs, sans d´efinir de s´emantique particuli`ere `a cette relation. La figure 5.4 montre que nous avons d´efini la classe P2P P2PTopologicalLink qui lie la classe P2P Peer `a elle-mˆeme. Sa cardinalit´e * - * indique que les pairs peuvent poss´eder z´ero ou plusieurs liens topologiques entre eux. Pour remplir notre contrainte de g´en´ericit´e de la relation, nous avons d´efini les attributs repr´esent´es sur la figure 5.5 : Tout d’abord l’aspect asym´etrique de la relation topologique est pris en compte par la d´efinition d’un attribut Antecedent et Dependent. L’ant´ec´edent de la relation poss`ede la

relation topologique alors que le d´ependant est r´ef´erenc´e par la relation. Par exemple, dans le cas d’une relation topologique fond´ee sur la connaissance, l’ant´ec´edent est celui qui connaˆıt, et le d´ependant est celui qui est connu. Ensuite, la sym´etrie d’une relation est repr´esent´ee par l’attribut IsSymetric. Enfin, l’attribut Description permet de d´ecrire la s´emantique de la relation.

Dependency

Antecedent: ref ManagedElement {key, *} Dependent: ref ManagedElement {key, *}

P2PTopologicalLink Antecedent: ref Peer {key, *} Dependent: ref Peer {key, *} IsSymetric: boolean Description: string

Fig. 5.5 – La classe d’association de lien topologique