Sp´ecialisation du mod`ele de l’information g´en´erique pour Jxta

tion pour la mise en œuvre d’un service et de sa supervision est int´eressante. Cette int´egration permet entre autres d’´eviter les traductions dues `a des changements de technologies et simplifie le travail des d´eveloppeurs de services qui voudraient ajouter des fonctions de supervision `a leur applications. Les outils que nous avons utilis´es sont ainsi un ensemble de biblioth`eques Java que nous mentionnons dans le tableau 8.1.

Outil Version Java JDK v1.4.2 08

Jxta Java Implantation v2.3.3 JMX Reference Implementation v1.2 JGraph v5.2

Log4j v1.2

Tab. 8.1 – R´ecapitulatif des outils utilis´es

Remarque : La conception et la r´ealisation de la plate-forme de supervision pour Jxta pr´esent´ee dans ce chapitre s’inscrit principalement dans le cadre du travail de th`ese que j’ai effectu´e. En outre, l’´equipe Madynes participe au projet RNRT<sup>1</sup> Safari<sup>2</sup> qui propose l’´etude, la r´ealisation et l’exp´erimentation d’une architecture de r´eseau int´egr´ee pour la conception, le d´eploiement et l’exploitation optimale de services dynamiques sur un r´eseau IPv6 hybride ad hoc/filaire. Son principal objectif est de mettre `a disposition des fournisseurs de services un environnement logiciel d´edi´e aux services `a valeur ajout´ee capables d’ˆetre exploit´es sur des infrastructures `a forte dynamique, couplant les r´eseaux ad hoc et les r´eseaux fixe au travers d’une couche de convergence IPv6 ´etendue. Un des sous-projets de Safari concerne la conception et la mise en œuvre d’une infrastructure de supervision adapt´ee aux objectifs du projet. La plate-forme retenue est Jxta. Notre travail s’applique ainsi directement `a ce contexte.

8.2 Sp´ecialisation du mod`ele de l’information g´en´erique pour

Jxta

Le mod`ele de l’information g´en´erique que nous avons pr´esent´e dans le chapitre 5 ne permet pas de prendre en compte toutes les particularit´es de Jxta. Nous l’avons donc sp´ecialis´e afin d’int´egrer les concepts relatifs `a la plate-forme ainsi que l’ensemble des m´etriques fournies par le projet MMP qui instrumente la plate-forme. Ceci a conduit `a la conception d’un nouveau sch´ema, nomm´e Jxta. Par souci de simplicit´e, nous n’avons pas utilis´e le mod`ele de m´etriques de CIM [46] mais nous avons ins´er´e les m´etriques directement dans les classes auxquelles elles se rapportent.

Remarque : La sp´ecification MOF de ce mod`ele est donn´ee en annexe C.

8.2.1 Sous-mod`ele de l’organisation

L’extension du sous-mod`ele de l’organisation que nous avons con¸cue pour Jxta est repr´esent´ee sur la figure 8.2. Tout d’abord, elle montre que nous avons ´etendu les notions g´en´eriques de pair et de communaut´e `a travers les classes Jxta JxtaPeer et Jxta JxtaPeergroup qui correspondent

1

R´eseau National de Recherche en T´el´ecommunications

2

aux concepts introduits par Jxta. Le rˆole d’un pair dans une communaut´e est d´ecrit `a l’aide de la classe d’association Jxta JxtaParticipatingPeer, qui h´erite de la classe P2P ParticipatingPeers et dont les attributs sont mentionn´es sur la figure 8.3. Parmi ceux-ci, les attributs bool´eens isRendezvous et isRelay renseignent sur le rˆole ´eventuel de rendez-vous ou relais d’un pair. Ensuite, pour repr´esenter les relations topologiques entre les pairs, nous avons con¸cu trois classes d’associations qui h´eritent toutes de la classe g´en´erique P2P TopologicalLink : la classe Jxta RendezvousConnection repr´esente un lien entre un pair simple et un pair de rendez-vous, la classe Jxta RelayConnection, un lien entre un pair et un relais, et enfin la classe Jxta Rendezvous-PeerView, un lien entre deux pairs de rendez-vous3. Par le biais de ce mod`ele, nous sommes capables de repr´esenter les diff´erents pairs Jxta, les groupes et leur organisation hi´erarchique, ainsi que les diff´erentes relations topologiques que les pairs entretiennent.

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

Community

CreationClassName: string {key} Name: string {override} PeerId: string {key} IsBehindFirewall: boolean ArrivalTime: date Peer ParticipatingPeers 1..n W 1..n P2PTopologicalLink

*

JxtaPeerGroup IsManageable: boolean JxtaPeer RendezvousConnection RelayConnection

*

*

*

RendezvousPeerView JxtaParticipatingPeer W 1..n 1..n 1 1

*

*

Fig.8.2 – Le sous-mod`ele de l’organisation de Jxta

ParticipatingPeers Antecedent: ref Community {key, 1..*} Dependent: ref Peer {key, 1..*} ArrivalTime: datetime

JxtaParticipatingPeer Antecedent : ref JxtaPeerGroup {key, 1..*} Dependent : ref JxtaPeer {key, 1..*} State : string

IsRendezvous : boolean IsRelay : boolean

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

RendezvousConnection Antecedent: ref JxtaPeer {key, 1} Dependent: ref JxtaPeer {key, *} PeerId: string State: string TransitionTime: datetime Lease: uint64 BeginConnectionTime: uint64 Connected: boolean Connecting: boolean TimeConnected: uint64 Disconnected: boolean DisconnectTime: uint64 NumConnectionsBeguns: uint32 NumConnectionsEstablished: uint32 NumConnectionsRefused: uint32 TotalTimesToConnect: uint64 LastLeaseRenewalTime: uint64 NumLeaseRenewals: uint32 NumDisconnects: uint32 TotalTimeConnected: uint64 TimeConnectionEstablished: datetime RelayConnection

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

RendezvousPeerView Antecedent: ref JxtaPeer {key, *} Dependent: ref JxtaPeer {key, *}

Fig.8.3 – Les classes d’association du sous-mod`ele de l’organisation

3

8.2. Sp´ecialisation du mod`ele de l’information g´en´erique pour Jxta

8.2.2 Sous-mod`ele de la communication

La conception d’un sous-mod`ele de la communication qui repr´esente les pipes Jxta `a l’aide du formalisme CIM n’est pas directe. En effet, les deux mondes n’ont pas la mˆeme conception d’un pipe. Jxta, de son cˆot´e, stipule qu’un pipe peut ˆetre unicast, et connecter ainsi un pair source `a un pair destination, ou propag´e et connecter un pair source `a plusieurs destinations. La mod´elisation de ces deux types de pipes par le biais de la classe CIM NetworkPipe du mod`ele commun pour les r´eseaux [42], n’est pas directe car dans le formalisme CIM, un pipe est li´e strictement `a deux endpoints. La repr´esentation d’un pipe propag´e pose donc probl`eme.

BindingTime : datetime Type : string {enum} IsClosed : string

JxtaPipe InstanceID: string {key}

Directionality: uint16 {enum} AggregationBehavior: uint16 {enum}

NetworkPipe

HostedNetworkPipe

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

NetworkPipe

(See P2P Model (Peer and Community))

Community (See P2P Model (Peer and Community)) Peer ParticipatingPeers 1

*

2

*

*

*

1..n 1..n PeerUsesPipe

*

2 W JxtaPipeEndpoint NumMessagesReceived : uint64 JxtaInputPipeEndpoint NumMessagesSent : uint64 JxtaOutputPipeEndpoint NetworkPipe Composition

Fig. 8.4 – Le sous-mod`ele de la communication de Jxta

En outre, apr`es plusieurs tests sur l’implantation Java de Jxta, nous nous sommes aper¸cu qu’en fait, un pipe unicast pouvait relier plusieurs sources `a une destination. De la mˆeme mani`ere, un pipe propag´e peut en fait relier plusieurs sources `a plusieurs destinations.

Pour r´esoudre ce probl`eme, nous avons con¸cu le sous-mod`ele repr´esent´e sur la figure 8.4. La classe Jxta JxtaPipe repr´esente un pipe tel qu’il est d´ecrit dans les documentations fournies par Sun et pas tel qu’il apparaˆıt dans l’implantation de la plate-forme. Les attributs de cette classe permettent de r´ef´erencer la date de cr´eation du pipe (BindingTime), de diff´erencier les pipes unicast et propag´es (Type) et d’indiquer l’´etat du pipe qui peut ˆetre ouvert ou clos (IsClosed).

Un pipe au sein de la sp´ecification Jxta va donc s’apparenter `a la composition de pipes de bas niveau. Ces derniers sont repr´esent´es directement `a l’aide de la classe CIM NetworkPipe car ils correspondent bien au concept de pipe tel qu’il est pr´esent´e dans CIM.

Concernant les endpoints, chaque pipe de bas niveau, repr´esent´e par la classe CIM Network-Pipe, va bien se trouver li´e `a deux endpoints. Par contre, un pipe de haut niveau tel qu’il est con¸cu par Jxta va pr´esenter plusieurs endpoints. Arbitrairement, nous avons choisi de repr´esenter l’ensemble des endpoints sources `a travers une seule classe, et de mˆeme pour l’ensemble des endpoints destinations. L’identifiant de ces endpoints virtuels ´etant donn´e par la concat´enation des endpoints de niveau sous-jacent.

8.2.3 Sous-mod`ele de services

Le sous-mod`ele de services pour Jxta que nous avons con¸cu a ´et´e dict´e par les donn´ees de gestion fournies par MMP. MMP instrumente huit services du noyau de la plate-forme pour lesquels il propose un large panel de m´etriques. La figure 8.5 pr´esente notre proposition de sous-mod`ele de services et la figure 8.6 d´etaille les m´etriques pr´esentes dans chacun des services. On constate tout d’abord que nous avons con¸cu les classes Jxta PeerService et Jxta PeerGroupService qui h´eritent toutes les deux de la classe P2P LocalP2PService. Celles-ci repr´esentent respective-ment les instances locales des services de pair et de groupe Jxta tels qu’ils sont d´efinis par la plate-forme4. Les huit services instrument´es par MMP sont des services de groupe qui doivent ˆetre implant´es par tout pair qui d´esire joindre le groupe par d´efaut appel´e NetPeerGroup.

P2PServiceAccessBySAP P2PServiceAccessPoint P2PService LocalP2PService LocalServiceComponent 1

*

1..n 1..n

HandlerName : string {key}

JxtaHandler

(See Detailled JXTA P2P Services)

JxtaQueryHandler

JxtaPeerGroupService

JxtaLocalPeerGroupService

(See Detailled JXTA P2P Services)

JxtaLocalPipeService

(See Detailled JXTA P2P Services)

JxtaLocalEndpointService JxtaPeerService

(See Detailled JXTA P2P Services)

JxtaLocalRendezvousService

(See Detailled JXTA P2P Services)

JxtaLocalResolverService

(See Detailled JXTA P2P Services)

JxtaLocalAlwaysAccessService

(See Detailled JXTA P2P Services)

JxtaLocalDiscoveryService

(See Detailled JXTA P2P Services)

JxtaLocalMembershipService

(See Detailled JXTA P2P Services)

JxtaLocalPeerInfoService

(See Detailled JXTA P2P Services)

JxtaSRDIHandler

1

JxtaHandlerForService

1..n

Fig. 8.5 – Le sous-mod`ele de services de Jxta

Afin de repr´esenter les points d’acc`es, nous avons con¸cu la classe abstraite Jxta JxtaHandler qui h´erite de la classe P2P P2PServiceAccesPoint et qui permet de faire la distinction entre les points d’acc`es Jxta et un point d’acc`es g´en´erique. Dans la plate-forme, deux types de points d’acc`es particuliers sont utilis´es : l’un est sp´ecifique au service SRDI et l’autre est g´en´erique `a l’ensemble des autres services. Ces deux points d’acc`es diff´erents ont conduit `a la conception de deux classes qui sont Jxta JxtaSRDIHandler et Jxta JxtaQueryHandler. D’apr`es la figure 8.6, on constate que MMP ne fournit pas seulement des m´etriques relatives aux services Jxta mais aussi des m´etriques relatives `a leurs points d’acc`es.

Remarque : Nous n’avons pas encore con¸cu de classes qui repr´esentent une vue globale des 4

Dans le document Supervision des réseaux et services pair à pair (Page 139-143)