Mod´elisation de la communication

Les applications P2P de type overlay utilisent des protocoles de niveau applicatif pour as-surer la communication entre les pairs, chaque pair utilisant une adresse de niveau transport pour communiquer. CIM mod´elise ce type de communication par le biais de canaux de commu-nications virtuels, appel´es pipes, dont plusieurs types sont repr´esentables. Nous en pr´esentons quelques exemples sur la figure 5.7. Tout d’abord, un pipe peut ˆetre unidirectionnel (5.7.a) ou bidirectionnel (5.7.b). En outre, CIM autorise deux types de composition qui sont la composition s´erie (5.7.c) et la composition parall`ele (5.7.d). Pour chaque composition, un pipe de haut niveau permet de repr´esenter de mani`ere abstraite la composition de pipes sous-jacents.

Pipe de haut niveau Pipe de bas niveau

(a) (b)

(c) (d)

Fig.5.7 – Exemples de pipes : (a) Pipe unidirectionnel. (b) Pipe bidirectionnel. (c) Composition de pipes en s´erie. (d) Composition de pipes en parall`ele.

Remarque : La notion de pipe telle qu’elle est d´efinie dans le mod`ele Common et telle que nous la consid´erons dans notre mod`ele de l’information, est similaire `a celle de Jxta, en ce sens qu’elle repr´esente un canal de communication virtuel entre plusieurs pairs. Le seul point qui diverge concerne les diff´erents types de pipes. Jxta consid`ere des pipes unicasts qui correspondent au

cas illustr´e dans la figure 5.7.a et des pipes propag´es qui ne sont pas directement repr´esentables `

a l’aide du mod`ele Common. Ce point est abord´e plus en d´etail dans la section 8.2.2.

Diagramme de classes CIM du mod`ele de communication

La s´emantique de pipe propos´ee par CIM est identique `a celle que nous proposons pour le mod`ele P2P. C’est pourquoi, nous avons choisi de r´eutiliser directement les classes du sous-mod`ele de r´eseaux [42] du sous-mod`ele Common. La figure 5.8 repr´esente l’extension du sous-mod`ele CIM que nous proposons. Celle-ci est construite autour de la classe CIM NetworkPipe, qui h´erite de la classe CIM EnabledLogicalElement du mod`ele Core. En accord avec la d´efinition de pipes donn´ee dans la section pr´ec´edente, cette classe se caract´erise par sa directionnalit´e (Directionnality), son type d’agr´egation (AggregationBehavior) et son identifiant (InstanceId). Les extr´emit´es d’un pipe sont repr´esent´ees `a travers la classe CIM ProtocolEndpoint, une sous-classe de la classe CIM ServiceAccessPoint pr´esent´ee dans la section 5.3.2. Le lien entre un pipe et ses points d’acc`es est mat´erialis´e par la classe d’association CIM EndpointOfNetworkPipe, qui stipule qu’un pipe est strictement d´efini par deux extr´emit´es, mais qu’une extr´emit´e peut appartenir `a z´ero ou plusieurs pipes. Enfin, la composition de pipes est prise en compte par la classe de composition CIM NetworkPipeComposition qui relie la classe CIM NetworkPipe `a elle-mˆeme.

(See Core Model)

EnabledLogicalElement

InstanceID: string {key} Directionality: uint16 {enum} AggregationBehavior: uint16 {enum}

NetworkPipe

HostedP2PPipe

ProtocolEndpoint (See Core and Networks Model (Protocol Endpoints)) EndpointOf NetworkPipe NetworkPipe Composition

(See P2P Model (Peer and Community))

Community (See P2P Model (Peer

and Community)) Peer ParticipatingPeers 1

*

*

*

*

*

Fig. 5.8 – Diagramme de classes CIM du mod`ele de communication

Etant donn´e ce mod`ele, nous avons simplement ´etendu la classe CIM NetworkPipe en y ajoutant la sous-classe P2P P2PPipe. Cette classe n’apporte aucun nouvel attribut, et poss`ede la mˆeme s´emantique que sa classe ancˆetre, mais elle permet d’ajouter deux liens d’associa-tion qui n’influent pas sur le mod`ele CIM. Le premier, repr´esent´e par la classe d’associad’associa-tion P2P PeerUsesPipe, permet de relier un pipe P2P aux deux pairs qui l’utilisent. Comme dans le cas de la classe d’association CIM EndpointOfNetworkPipe, la cardinalit´e stipule qu’un pipe P2P est li´e `a deux pairs alors qu’un pair peut disposer de z´ero ou plusieurs pipes. Le second lien que nous avons ajout´e exprime la d´efinition d’un pipe dans le contexte d’une communaut´e. Ceci est fait par le biais d’une association faible¹¹ du cˆot´e du pipe. Par ce biais, on identifiera toujours un pipe dans le cadre d’une communaut´e.

11

5.4. Synth`ese

5.4 Synth`ese

La premi`ere ´etape vers la construction d’une infrastructure de gestion pour les r´eseaux et services P2P concerne la mod´elisation des informations de gestion. Durant cette ´etape, nous avons recens´e les diff´erentes caract´eristiques du mod`ele P2P qu’une infrastructure de gestion doit poss´eder. Ceci a conduit `a la proposition de cinq mod`eles qui concernent l’organisation fonctionnelle et topologique des pairs, les ressources offertes par une communaut´e, la mani`ere dont les pairs communiquent, les services qu’ils proposent, et enfin deux services particuliers en rapport avec le routage. Comme formalisme d’expression, nous avons choisi le Mod`ele Commun de l’Information, CIM. Sa nature orient´ee objet, son grand nombre de classes existantes et son caract`ere standard, le placent comme meilleur candidat `a la repr´esentation d’informations de gestion pour le mod`ele P2P. Ainsi, nous avons con¸cu un sch´ema d’extension de CIM qui caract´erise les r´eseaux et services P2P du point de vue de la gestion et offre ainsi une vue abstraite `a un gestionnaire.