Diplôme d'etudes Approfondies Réseaux de télécommunications

Transcription

1 UNIVERSITE LIBANAISE (Faculté de Génie) UNIVERSITE SAINT-JOSEPH (Faculté d'ingénierie) Sous l'égide de l'agence Universitaire de la Francophonie AUF Diplôme d'etudes Approfondies Réseaux de télécommunications < Représentation sémantique des informations de Gestion des politiques> Par <CHRISTINE JARDAK> Encadré par : M. Maroun Chamoun Soutenance le 22-Décembre-2004 devant le jury composé de MM. Samir Tohmé Président Mohamad Zoaeter Membre Wajdi Najem Membre Imad Mougharbel Membre Nicolas Rouhana Membre Mahmoud Doughan Membre Maroun Chamoun Membre

2 Remerciements Je tiens à remercier Mr. Maroun CHAMOUN, le responsable de mon projet, pour son aide, son orientation, ses conseils et surtout son temps précieux, indispensables pour la bonne réalisation de ce projet. 2

3 SUJET La gestion des politiques repose sur l exécution d un ensemble de règles qui dictent les droits d accès aux ressources et qui permettent d établir un lien entre les profiles utilisateurs, les applications et les services demandés. Elle permet de résoudre les problèmes de sécurité en contrôlant l accès aux ressources, ainsi qu elle permet d assurer une qualité de service (QoS) par réservation de ressources suivant des classes de services différenciées. Pour pouvoir mettre en œuvre, il convient de définir une ou plusieurs politiques sur différents nœuds du réseau, sachant qu une politique n est que l ensemble de règles permettant d implémenter la qualité de service demandée, et donc la manière dont on va utiliser le réseau, notamment qui va faire quoi, et dans quelle condition. Dans ce cadre trois paramètres sont essentiels : l utilisateur, le service et le temps. L une des approches de politiques de mise en œuvre envisagée est COPS (Common Open Poilicy Services). COPS est un protocole qui va permettre aux routeurs et aux différents équipements du réseau d échanger des informations avec un serveur centralisé qui stocke l ensemble des politiques. Le modèle de politique utilisé s appuie sur les cinq éléments suivants : - Un répertoire de politiques qui contient l ensemble de règles définissant la façon Dont on va utiliser le réseau. - Un éditeur de politiques pour la définition des politiques - Le PDP (Policy Decision Point) : Application centralisée qui réalise le contrôle D admission en se basant sur les politiques d utilisation du réseau, l état du réseau et les messages de réservations des ressources. - Le PEP (Policy Enforcement Point) : Les routeurs qui sont responsables de la Mise en exécution et la vérification des décisions qui ont été prises par le PDP. - Le protocole COPS qui permet au PDP et au PEP de communiquer. 3

4 On peut définir l architecture globale de la politique sous COPS en reprenant ces cinq éléments : Edition Editeur de politique Répertoire de politiques Policy Decision Point (PDP) COPS Policy Enforcement Point (PEP) Notre approche consiste à définir des objets sémantiques en XML pour la définition et la représentation des informations et des règles de politiques de COPS. Travail demandé : 1. Etude du protocole COPS. 2. Etude des standards de la représentation sémantique (RDF, RDF schéma, ontologies, OWL, etc, ) 3. Conception et implémentation d un outil de définition des règles de politique. Ces règles de politiques doivent être définies en SWRL (Semantic Web Rule Language). 4. Définition d une Ontologie pour représenter la PIB (Policy Information Base). 5. Pour valider cette définition, il faudra intégrer l ontologie représentant la PIB, a la plateforme active à base de services Web (ASWA) pour la gestion de politique déjà développée a l ESIB. 4

5 SOMMAIRE PARTIE I CHAPITRE 1: PBN (Policy Based Networking ) p 7 CHAPITRE 2: COPS (Common Open Policy Service) p 11 CHAPITRE 3: COPS-PR (Common Open Policy Service-Provisioning) p 17 CHAPITRE 4: PIB (Policy Information Base). p 24 CHAPITRE 5: SPPI (Structure of Policy Provisioning Information)...p 28 PARTIE II CHAPITRE 1: Ontologie & OWL (Ontology Web Editor).p 35 CHAPITRE 2: Editeurs d Ontologie p 47 CHAPITRE 3: Ajout d un Plugin à Protégé.p 54 CHAPITRE 4: Implémentation du protocol COPS..p 62 CHAPITRE 5: OWL Rules Language (ORL)..p 68 Conclusion...p 78 Perspectives p 79 Références...p 80 5

6 PARTIE I 6

7 CHAPITRE 1 PBN (Policy Based Networking) 1-Définition : La gestion des politiques repose sur l exécution d un ensemble de règles qui Dictent les droits d accès aux ressources. L architecture PBN (Policy Based Networking), est une approche orientée gestion des politiques. 2-Objectif : Son objectif est de délivrer une architecture compréhensive qui permet de grouper tous les utilisateurs, les applications, et les informations politiques dans des actions politiques sur le réseau. Le but de PBN est de pouvoir forcer. Des politiques sur les nœuds du réseau et de pouvoir gérer le système Globalement. 3-Architecture de base : Un système PBN est formé des composants suivants : -Policy management tool : Son travail est d aider le Network Manager a construire et a déployer des politiques, de même il fait du monitoring pour l environnement des politiques. Le policy management tool peut être vu comme une interface entre le Network Manager et le Policy repository -Policy repository : Est un environnement de stockage dans lequel on dépose les politiques, leurs conditions, leurs actions,.en d autres mots c est une base de données. -Policy Decision Point (PDP) : Est une entité logique qui produit les politiques de décisions pour elle même ou bien pour les autres éléments du réseau qui demandent de telles décisions, le PDP peut être par exemple un serveur. -Policy Enforcement Point (PEP) : Es tune entité logique qui reçoit les politiques de décisions du PDP et les appliqués, le PEP a la capacité de prendre une décision de politique 7

8 locale via LPDP, qui est un PDP Local mais comme le PDP est le centre de décision, donc le PEP doit lui communiquer cette décision locale. Nous illustrons cette architecture avec tous ses éléments par ce schema: Policy management tool Network Manager P E P COPS PDP P E P COPS Policy Repository 4-Fonctionnement : COPS est un protocole de signalisation de type requette / réponse basé sur TCP. En effet c est le client PEP qui est responsable d initier une connection TCP avec PDP. Une fois cette connexion est établie le PEP commence à envoyer des requêtes de configurations au PDP et donc il reçoit de la part du PDP des contextes de politiques, donc des configurations qu il essaie d appliquer. Ainsi le PDP peut configurer les PEPs, de même les PEPs peuvent envoyer des rapports au PDP pour lui notifier de leurs configurations, et pour lui reprocher s ils ont pu installer la configuration reçue ou pas. Tous ces messages entre les PEPs et le PDP sont transportés par le protocole COPS qu on détaillera dans le chapitre suivant. 8

9 5-Difficulté de PBN : Après avoir compris l architecture PBN, il est nécessaire de savoir que la difficulté de cette Réside dans la translation des politiques, c.a.d la transformation d une politique, d une forme de représentation a une autre forme de représentation qui peut être comprise par les PEP, il sera nécessaire donc de convertir les entrées d une PIB qui sont des named data structure a un format de ligne de commande. C est ce qu on appelle mapping des politiques qui est très important. 6-Exemples d utilisation d une architecture PBN : 6.1-Exemple 1 : Contrôle d admission Cet exemple concerne les schémas de contrôle d admission, ces schémas sont responsables d assurer que les ressources demandées sont disponibles. De plus ces schémas doivent avoir la possibilité de déployer des contraintes temporelles,d identification et de permission. La Policy Based Admission control, a la possibilité de forcer des règles qui ont des dépendances temporelles ex : Un groupe d utilisateurs peut être permis de faire des réservations seulement Durant les OFF-PEAK HOURS, de même la PBAC, devra supporter les politiques qui prennent en compte l identité de l utilisateur qui demande un certain service ou bien une certaine ressource ex : Une réservation RSVP peut être acceptée ou rejetée dépendamment de l ID du user et Ses droits. 6.2-Exemple 2 : QoS avec Diffserv La qualité de service permet d assurer des services réseau qui seront conformes avec les paramètres spécifiés dans le SLA (Service Level Agreement). La QoS est caractérisée par le délai, le dépit, taux de pertes, Avec Diffserv on distingue des classes, et chaque classe doit être traitée d une manière différente de façon à assurer la QoS demandée pour chaque classe, pour faire ceci on pourra proposer une architecture PBN, ou il y a des politiques qui spécifient pour chaque classe ce qu on doit faire. 9

10 7-Nouvelle Extension de l architecture PBN : La plupart des systèmes appliquent l architecture PBN pour contrôler les équipements de périphérie du réseau ex : routeurs, coupes-feux, passerelles, Les futurs systèmes vont considérer les terminaux des utilisateurs comme étant les PEPs, et cela pour assurer une classification plus fine d un coté et pour traiter les problèmes de classification qui peuvent augmenter lorsque le trafic de l utilisateur sort crypté du terminal. Avec cette solution on résoud deux problèmes : 1-problèmes de congestion du réseau 2-problèmes d adaptation de la QoS Pour pouvoir évoluer vers cette nouvelle extension, il faut quand même étendre le protocole COPS pour pouvoir supporter de nouveaux Client-Type qui permettent d interfacer directement l utilisateur avec le PDP, la nouvelle extension du protocole COPS sera COPS-SLS ( Service Level Specification) le schéma de la nouvelle Architecture sera donc : Policy management tool Network Manager PEP COPS-SLS PDP COPS-SLS PEP Policy Repository 10

11 CHAPITRE 2 COPS (Common Open Policy Service) 1-Généralités : Le Groupe de travail RAP de l IETF, a développé COPS en tant que protocole de politique pour un usage dans des systèmes de gestion de politique réseau. COPS présente une approche révolutionnaire pour la gestion proactive d équipement de réseau. Il a été développé en comparaison aux protocoles traditionnels de gestion de réseau tel que SNMP, lequel s est avéré incapable de supporter efficacement une gestion de politique réseau. La pile du protocole COPS peut être conceptuellement divisée en 3 couches distinctes : le protocole de base, les directives d usage du type client, et la représentation de données de politique. Ces trois couches ainsi que beaucoup d autres avantages offerts par COPS par rapport à des protocoles traditionnels des gestions de réseau, permettent à COPS de s adapter tout à fait à l environnement de gestion de politique réseau. 2-Les objectifs : Le but du protocole COPS est un protocole de requêtes/réponses utiliser pour échanger des informations de politique entre un point de décision de politique (PDP) et ses clients, autrement dit les points de renforcement de politique (PEPs). Le PEP est un routeur ou tout autre équipement qui gère du trafic IP et établit un contrôle d admission basé sur une politique pour des flux d information. Le PDP, qui a une vue sur l ensemble de la zone du réseau (par exemple un système autonome) a travers ses PEPs, décide s il doit ou non accepter l entrée d un flux d informations spécifiques. On suppose qu il existe au moins un PDP par domaine. Ce protocole à deux modèles de gestion de politique qui sont: 11

12 L Outsourcing où l utilisateur et l administrateur du réseau ne communiquent pas; le PEP envoie une requête à son PDP qui lui autorise ou non l établissement de la connexion. Le protocole utilisé pour gérer la QoS dans le modèle d outsourcing est RSVP. Le provisioning où un contrat, le SLA (Service Level Agreement), est établi entre l utilisateur et l administrateur du réseau pour définir la qualité de service attribuée à l utilisateur. Les politiques définies dans ce contrat sont saisies par l administrateur grâce à une console et sont alors enregistrées dans la Policy Repository qui est le serveur où sont stockées les règles de gestion de politiques. Le provisioning est souvent associé à la technique Diffserv dans laquelle les flots sont classifiés en différentes classes. 3-Caractéristiques : Les principales caractéristiques du protocole COPS sont les suivantes : 1. le protocole utilise un modèle client/serveur ou le PEP envoie des requêtes, Des mises a jour, et des annulations au PDP. Ce dernier transmet à son tour les décisions au PEP. 2. COPS utilise le protocole TCP comme protocole de transport pour un échange fiable des messages entre le serveur de politique et ses clients, sans Nécessiter aucun mécanisme supplémentaire. 3. Le protocole est extensible grâce à la puissance de sa conception et peut supporter des informations spécifiques venants de divers clients sans que de nouvelles modifications lui soient apportées. Il a été pour l administration, la Configuration, et l exécution des règles de politiques qu elles soient signalées «Outsourcing» ou fournies «provisioning». Le protocole peut être étendu pour l administration d une grande variété de protocoles de signalisation ainsi que la configuration des équipements réseau. 4. Le protocole fournit un niveau de sécurité en assurant une authentification et une intégrité des messages. Eventuellement, COPS peut utiliser certains protocoles existants pour la sécurité comme IPSEC pour authentifier et sécuriser le canal de communication entre PDP et PEP. 12

13 4- L architecture de la gestion des politiques : Cette architecture se résume par le schéma suivant PDP (Policy Decision Point) Le PDP, que l on peut aussi appeler serveur de politiques, est le point central qui doit décider des politiques à appliquer dans le réseau. Il est défini comme une entité logique prenant des décisions politiques pour elle-même ou pour d autres éléments réseau qui demandent ses décisions Le PDP prend des décisions à sa propre initiative ou en réponse à une requête faite par un PEP; pour ce faire, il consulte le Policy Repository. Le PDP récupère les politiques du Policy Repository grâce au protocole LDAP. Une fois qu il a localisé et pris les règles, il vérifie leur condition d application et les transforme en un format adapté compréhensible par les PEPs (PIB: Policy Information Base ou MIB: Management Information Base). PEP (Policy Enforcement Point) Le PEP est un nœud du réseau qui peut être de différents types: routeur, firewall, switch ou une machine cliente. Il dépend d un PDP duquel il prend les politiques qu il doit obligatoirement appliquer. Il doit aussi faire la correspondance entre la représentation externe (PIB ou MIB) et la configuration interne des équipements du réseau. 13

14 Le PEP doit donc être facilement accessible et paramétrable par le PDP qui doit pouvoir facilement le configurer; il doit rendre compte au PDP de l exécution des décisions, des politiques installées chez lui et des éventuelles modifications, Affin d envoyer une requête au PDP et de pouvoir en recevoir la réponse, le PEP établit une connexion TCP avec lui. 5-Encapsulation des protocoles : 6-La structure des messages COPS : a- Entête COPS: Un message COPS encapsule une série d objets. L entête du message définit principalement le type de client, le type d opération concernée par le message et la longueur totale de celui-ci. L interprétation de tous les objets encapsulés dans un message est relative au champ «Client-Type». Signification de chaque champ : -Version : Indique la version du protocole COPS, la version courante est 1. -reserved : Ce champ est réservé, et doit être mis à 0. -S : Sollicited Message Flag, il est mis a «set»quand le message est Sollicité par un autre message COPS. -Opcode : utilisé pour identifier l opération effectuée, le tableau ci-dessous Indique toutes les valeurs que peur prendre ce champ 14

15 -Client type : Identifie le client de politique.l interprétation de tous les objets encapsulés est liée à cet identificateur, le tableau ci-dessous indique les valeurs que peut prendre ce champ -Message length : La taille du message en octets, en prenant compte de l entête et tous les objets encapsulés, les messages COPs doivent être alignés sur des intervals de 4 octets. -Data : Contient tous les objets. b- Objets COPS : Tous les objets encapsulés sont constitués d une entête au format identique Suivi du contenu de l objet formé par un ou plusieurs mots de 32 bits 15

16 Signification des champs : -Length:longueur de l objet en octet -Class : classe de l objet, défini dans le tableau ci-dessus : -Subclass : un champ sur 8 bits. 16

17 CHAPITRE 3 COPS-PR 1-Définition : COPS-PR est le client-type du protocole COPS crée pour faire la gestion des politiques, il peut être utilisé pour assurer la qualité de service de Diffserv,pourtant l utilisation de COPS-PR n est pas limitée à Diffserv seulement. Les politiques de Diffserv se trouvent dans le SLA, donc lorsque COPS est utilisé pour distribuer ces politiques.un PDP généralement va distribuer des décisions lorsque les SLAs sont mis à jour. Le Client type COPS PR est désigné pour ce travail. 2-Pourquoi COPS-PR pour la gestion des politiques? -Cause 1 : COPS-PR permet d assurer un transport efficace d attributs, des transactions de donnée importante, et permet aussi de renvoyer des rapports d erreurs. -Cause 2 : il y a une seule connexion entre le client et le serveur dans chaque zone De contrôle de politique, qui est identifiée par le client-type, elle garantie donc qu un seul serveur fait la mise a jour pour une configuration particulière. -Cause 3 : il est défini comme étant un real- time event-driven communications Mechanism qui ne demande pas de polling entre PEP et PDP. 17

18 3-Les messages de COPS-PR entre PEP et PDP : Client Open Client Accept Request PIB Decision Usollicited Decision PIB Report State Client Close PEP PDP -Client Open : Ce message est transmis par le PEP pour demander une connexion en lui indiquant le Type du client, ex : COPS-PR, COPS-RSVP. Ce message contient obligatoirement l identité du PEP dans l objet PEPID en plus une entête commune. Les champs entre crochets sont optionnels. Format de ce message : <Client-Open> : : = <CommonHeader> <PEPID> [<ClientSI>] [<LastPDPAddr>] -Client Accept : Ce message est renvoyé au PEP par le PDP pour confirmer la connexion. Par l objet Keep-Alive Timer le PDP indique au PEP l intervalle de temps maximum a respecter entre deux messages d indication de présence. 18

19 Format de ce message : <Client-Accept> : : =<CommonHeader> <KA Timer> [<ACCT Timer>] [Integrity] Si le PDP refuse la connexion il renvoie au PEP le message Client-Close. La raison de refus est mentionnée dans l objet ERROR. <Client- Close>: : = <CommonHeader> <Error> [<PDPRedirAddr>][Integrity] -Request : Lorsque la connexion est ouverte le PEP peut ainsi envoyer une requête au PDP, contenant des informations internes concernant le PEP ex : taille maximale de ces queues,sa capacité, des indications concernant sa configuration s il y en a une, une requête est identifiée par un numéro Client Handle, un client peut envoyer plusieurs requêtes de configurations chacune caractérisée par son Client handle, donc il pourra recevoir plusieurs contextes de configurations, mais un seule peut être actif en même temps. Ce message de requête sert à deux buts : 1-C est une demande de recette pour le PDP pourqu il envoie au PEP une configuration qui lui est convenable. 2-cette requête de configuration permet d ouvrir un canal qui permet au PDP d envoyer d une manière asynchrone au PEP, des décisions de politiques et cela lorsqu il décide que c est nécessaire, ces décisions peuvent être une mise à jour ou bien une nouvelle configuration. Format de ce message: <Request Message> : : = <Common Header><Client Handle> <Context> [<IN-Int>] [<OUT-Int>] [LPDPDecision(s)] [Integrity] < LPDPDecision (s) : : = [<Context>] [<LPDPDecision : Flags>] [< LPDPDecision : Stateless Data>] [< LPDPDecision : Replacement Data>] [< LPDPDecision : ClientSI Data>] [< LPDPDecision : Named Data>] 19

20 -Decision : En réponse au message de requêtes le PDP va étudier le contenu de la requête et aller chercher de la PIB, les politiques conformes au PEP, et donc il va les envoyer dans le message de décision qui porte le même client handle que celui dans la requête. Le PDP peut quand même envoyer des messages de décisions qui ne sont pas sollicités par un message de requête, pour faire une mise à jour de la configuration du PEP. A l aide d un message de décision le PDP peut aussi obliger un PEP de lui envoyer un message de requête, c.a.d ouvrir un nouveau contexte, il peut quand même l obliger à effacer un contexte existent. Ce message peut contenir plusieurs décisions, c.a.d il peut contenir un ensemble de règles qui permettent de supprimer ou bien d ajouter des politiques, il doit être traité par le PEP comme étant une seule transaction, en d autres termes il suffit que le PEP ne supportera une décision pour qu il revienne à sa configuration initiale et ne prenne pas compte de cette nouvelle configuration. Format de ce message : <Decision Message> : : = <CommonHeader> <Client Handle> <Decision (s) <Error> [Integrity] -Report State : Lorsque la décision a été reçue par le PEP, celui-ci utilise le message Report State, pour communiquer au PDP le résultat de la décision, ce message peut être : 1-Success : Le PEP a pu installer toutes les décisions de politiques reçues du PDP dans sa propre PIB 2-Failure : Si une décision a échouer donc le PEP ne prend pas compte de cette nouvelle configuration donc il envoie un report message en indiquant quelle décision a causé l erreur. De même a n importe quel moment le PEP peut envoyer au PDP l état courant de n importe quel contexte dans le message Report-State, c est ce qu on appelle Accounting. Format de ce message : <Report-State> : : = <CommonHeader> <Client Handle> <Report-Type> -Client-Close : Ce message est utilise pour la fermeture de la connexion. 20

21 4-Format de l objet dans COPS-PR : Length S-Num S-Type EEntE Entier de EE Entier de 32 bits Explication des champs : -Length (2 octets) : indique la longueur de l objet en octet -S-Num (1 octet) : définit l objet ex : PRID, PPRID, -S-Type (1 octet) : décrit le codage spécifique utilisé pour cet objet ex: BER, 5-Les objets de COPS-PR : 5.1-Provisioning Instance Identifier: PRID Il a: S-Num = 1 (Complete PRID), S-Type = 1 (BER), Length = variable. Cet objet est utilisé pour transporter l identificateur d une Provisioning Instance. Cet identificateur est codé en suivant les règles de codage pour le OID (object Identifier) en SNMP, spécifiquemnet il est code en utilisant TLV, Type/Longueur/Valeur. 21

22 5.2-Prefix Provisioning Instance Identifier: PPRID Il a : S-Num = 2 (Prefix PRID), S-Type = 1 (BER), Length = variable. C est un identificateur de la PRC, on l utilise dans certaines décisions comme les Décisions de remove, si on veut éliminer toutes les PRI d une PRC on lieu de les Enlever chacune en utilisant son PRID, on les enlève toutes ensemble en utilisant Le PPRID de la PRC a laquelle elles appartiennent. 5.3-Encoding Provisioning Instance Data: EPD Il a: S-Num = 3 (EPD), S-Type = 1 (BER), Length = variable. Cet objet est utilisé pour transporter la valeur code d une PRI, c. a.d la valeur de Chaque attribut de cette PRI est codé en appliquant TLV, ensuite on assemble Toutes les valeurs des attributs, en commencant par l attribut ayant le OID le Plus petit arrivant a celui ayant le OID le plus grand. L ensemble forme le EPD 5.4-Global Provisioning Error Object: GPERR Il a : S-Num = 4 (GPERR), S-Type = 1 (for BER), Length = 8. Cet objet est utilisé pour communiquer des erreurs générales exemple : -availmemlow : la taille de la mémoire valable est petite. -maxmsgsizeexceeded: on a dépassé la taille maximale du message -unknownerror -unknowncopsprobject : l objet COPS-PR indiqué est n est pas connu. 22

23 5.5-PRC Class Provisioning Error Object: CPERR Il a : S-Num = 5 (CPERR), S-Type = 1 (for BER), Length = 8. Il a pour rôle de communiquer de erreurs qui sont en relations avec des PRCs Spécifiques. Exemple de ces erreurs: -prispaceexhausted -attrvalueinvalid : On ne peut plus installer d instances dans cette classe. : la valeur de cet attribut n est pas Valide. -attrvaluesuplimited : la valeur spécifiée pour cet attribut est légale mais n est pas supportée par la Machine. -attrmaxlengthexceeded: la longueur de la valeur de cet attribut dépasse la limite. 5.6-Error PRID Object : ErrorPRID Il a : S-Num = 6 (ErrorPRID), S-Type = 1 (BER), Length = variable. Cet objet est utilisé pour transporter le PRID de l instance qui a causé une erreur D installation. 23

24 CHAPITRE 4 PIB (Policy Information Base) 1-Définition : La PIB est l équivalent de la MIB pour la gestion de QoS. C est un modèle permettant de décrire en ASN.1 les politiques de gestion et leur format d échange entre le PEP et le PDP. La PIB est utilisée par COPS dans le modèle de provisioning (COPS-PR) où les données échangées sont des politiques qui sont soit envoyées par le PEP pour notifier le PDP, soit imposées par le PDP au PEP sans requête de la part de ce dernier. -La représentation logique de la PIB est une structure arborescente où les branches représentent les classes de provisioning (PRC) et les feuilles représentent les instances de provisioning (PRI) comme ci-dessous: PIB PRC PRI PRI PRC PRI PRI PRI Dans la PIB, toute information est représentée sous forme d une table ou PRC (Provisioning Class) qui est identifiée par un identificateur appelé PPRID (Prefix PRID) ayant un ensemble d attributs et dont les entrées (lignes) sont des PRI (Provisioning Instance), qui sont des instances de la PRC, chaque PRI est identifiée par un identificateur unique appelé PRID (Provisioning Instance Identifier). -La représentation physique de la PIB est une table ou les entrées de la table sont les PRC et chaque PRC contient plusieurs PRI : 24

25 PRC 1 Attribut 1 Attribut 2 Attribut 3 PRI 1 PRI 2 PRC 2 Attribut 1 Attribut 2 PRI 1 PRI 2 PRI 3 2-Règles de modification ou d extension d une PIB : 2.1-On peut ajouter une PRC a une PIB ou bien supprimer une : Si on a ajouté une nouvelle PRC a une PIB donc celle-la va contenir de nouvelles instances, donc si le PEP utilise cette nouvelle version de la PIB et le PDP utilise l ancienne version (qui ne contient pas cette nouvelle PRC) donc le PEP n a aucune chance de recevoir des PRI de la part du PDP, concernant cette nouvelle PRC, donc il n y a pas de problème. Si le PDP utilise la nouvelle version de la PIB, et le PDP a toujours l ancienne version donc,il se peut que le PDP envoi des PRI de la nouvelle PRC que le PEP ne connaît pas, donc le PEP répond au PDP par une erreur. Si on a enlevé une PRC de la PIB, donc cette nouvelle PIB va contenir une PRC en moins par rapport à l ancienne PIB. Si le PDP a l ancienne version de PIB et le PEP possède la 25

26 nouvelle, donc le PEP va ignorer les PRI de la PRC enlevée, dans ce cas le PDP ne les envoie pas pour lutter contre les erreurs Un attribut peut être enlevé ou bien supprimé d une PRC : -enlever : Dans COPS-PR les attributs d une PRC sont identifiés par des numéros séquencés. Donc lorsqu on enlève un attribut si le PDP utilise le codage BER, il doit donc envoyer une valeur en ASN.1 pour le type correct, ou une valeur NULL, donc le PEP qui reçoit la valeur NULL va mettre l attribut convenable a sa valeur en défaut, s il n a pas de valeur en défaut il doit envoyer une erreur au PDP. -ajouter : L ajout d un attribut doit être fait après les attributs existants. Si un PEP reçoit une PRI ayant plus d attribut que prévu comme il ignore les attributs en excès donc il envoie un warning au PDP. Alors que s il reçoit Une PRI avec un nombre d attribut inférieur que le nombre prévu donc il assume de mettre les attributs en excès a leur valeur par défaut,et si ces derniers n ont pas de valeur par défaut donc il envoie une erreur pour le PDP. 2.3-Une PRC peut être étendu en définissant une autre PRC la dedans. 3- Les opérations sur une PRI : Une PRI contient une valeur pour chaque attribut défini dans la PRC ou elle se trouve cette PRI comme on a déjà dit à un identificateur qui est le PRID et qui est unique pour le client (qui dans notre cas est le COPS-PR) et pour le contexte existant sur le PEP. Les opérations sont les suivantes : 26

27 1. Install : cette opération crée ou bien met à jour une PRI, elle a besoin de deux Paramètres : a-prid, pour nommer la PRI b-epd (Encoding Provisioning Instance Data), cet objet comme on le verra par la suite permet de donner les valeurs des attributs. 2. Remove : cette opération permet d enlever des une PRI d une PRC, elle demande un seul paramètre qui est le PRID pour enlever une PRI ou bien le PPRID pour enlever une PRC. N.B : Si on essaie d enlever un PRID ou bien un PPRID qui n existe pas cela devra envoyer un warning au PDP. 27

28 CHAPITRE 5 SPPI (Structure of Policy Provisioning Information) La structure de la PIB est définie dans le RFC 3159: SPPI. Cette structure est écrite en ASN1 et elle est basée sur la définition du SMI et de la MIB du protocole SNMP. Dans SPPI, il y a la définition de cinq macros nécessaires à la description d une PIB: - Module-Identity - Object-Identity - Object-Type - Object-Group - Module-Compliance Module-Identity Cette macro est utilisée pour définir un module de la PIB, c est à dire un élément qui regroupe toutes les tables (PRC) d une même catégorie: par exemple, toutes les tables concernant le filtrage se trouvent dans un même module, celles concernant la DiffServ dans un autre. La définition de cette macro est la suivante: MODULE-IDENTITY MACRO ::= TYPE NOTATION ::= SubjectPart -- new "LAST-UPDATED" value(update ExtUTCTime) "ORGANIZATION" Text "CONTACT-INFO" Text "DESCRIPTION" Text RevisionPart VALUE NOTATION ::= value(value OBJECT IDENTIFIER) 28

29 La notion la plus importante de ce module est celle de SubjectPart qui contient les différentes catégories de données décrites dans cette PIB; une catégorie est liée à un Client Type qui est représenté par le même identificateur dans le protocole COPS. Chaque message COPS contient un Client Type dont la valeur permet de définir l instanciation d un ensemble de politiques. Object-Identity Cette macro est utilisé dans les modules de la PIB affin de définir des informations concernant la déclaration d un Object Identifier. La définition de cette macro est la suivante: OBJECT-IDENTITY MACRO ::= TYPE NOTATION ::= "STATUS" Status "DESCRIPTION" Text ReferPart VALUE NOTATION ::= value(value OBJECT IDENTIFIER) Dans cette macro, Status ne peut prendre qu une de ces trois valeurs: current, deprecated et obsolete. ReferPart spécifie une référence (RFC par exemple) Object-Type Cette macro sert à déclarer une table, un attribut ou une entrée. Il est utile de rappeler que tous les attributs définis dans SPPI se trouvent dans une table, la PRC. Chaque PRI ou instance de PRC a donc le même ensemble d attributs. La définition de cette macro est la suivante: OBJECT-TYPE MACRO ::= TYPE NOTATION ::= "SYNTAX" Syntax UnitsPart 29

30 "PIB-ACCESS" Access -- modified PibReferencesPart -- new PibTagPart -- new "STATUS" Status "DESCRIPTION" Text ErrorsPart -- new ReferPart IndexPart -- modified MibIndexPart -- modified UniquePart -- new DefValPart VALUE NOTATION ::= value(value ObjectName) Dans cette macro, la clause Syntax est obligatoirement définie pour toute PRC et chacun de ses attributs. Pour un attribut, Syntax peut être un base type (Integer, Integer32, Octet String, Object Identifier,...), une textual convention ou un bits pseudo type qui est un identificateur suivi d un nombre. Une textual convention peut être définie dans une macro spécifique qui sera décrite ultérieurement; c est une définition d un nouveau type basée sur les base types prédéfinis. Pour une PRC, Syntax est une séquence d attributs (Sequence Of EntryType). La clause Pib-Access est uniquement présente pour la définition d une PRC. Elle définit le type d accès à cette table selon la valeur qu elle prend. Elle peut prendre une de ces quatre valeurs: - install : utilisée pour les PRCs pouvant être installées par un PDP chez un PEP. - notify : utilisée quand le PEP doit notifier le PDP des valeurs des attributs et des instances de cette PRC. - install-notify : utilisée pour les PRCs présentant les deux caractéristiques précédentes. - report-only : utilisée pour les PRCs ne présentant aucune de ces deux caractéristiques mais pouvant être inclues dans les rapports du PEP. La clause PibReferencesPart n est définie que pour un attribut dont la Syntax a pour valeur ReferenceId (qui est une textual convention); elle contient la PRC dont une instance est référencée par cet attribut. La clause PibTagPart n est définie que pour un attribut dont la Syntax a pour valeur TagReferenceId (une autre textual convention); elle est utilisée pour indiquer que cet 30

31 attribut référence une liste d instances d une autre PRC qui ont la même valeur pour un certain attribut. Elle contient cet attribut commun (qui doit avoir TagId comme valeur dans sa Syntax). Comme dans la macro Object-Identity, Status ne peut prendre qu une de ces trois valeurs: current, deprecated et obsolete et ReferPart spécifie une référence. ErrorsPart est une clause qui n est présente que pour les PRCs. Elle contient une liste d entiers qui sont définies dans COPS et qui représentent les différents types d erreurs. IndexPart peut être de trois types: - PIB-INDEX est utilisée pour la définition d une entrée dont le nombre d attributs est inférieur à 127; elle contient un descripteur spécifiant un attribut qui identifie l instance d une PRC; la Syntax de cet attribut doit être InstanceId. - AUGMENTS est utilisé pour la définition d une entrée dont le nombre d attributs dépasse nécessairement 127; cette clause contient le nom de l entrée de base qu elle complète. - EXTENDS est utilisé pour la définition d une entrée dont le nombre d attributs dépasse parfois 127; cette clause contient le nom de l entrée de base qu elle complète. Il faut noter que IndexPart ne peut être que d un de ces types. La clause MibIndexPart n existe que si la clause PIB-INDEX existe. Elle contient un certain nombre d attributs et est utilisée pour la conversion entre la PIB et la MIB. La clause UniquePart est optionnelle; elle contient une liste d attributs de la PRC qui ne peuvent pas avoir la même valeur pour deux instances différentes de la PRC. Cette liste permet d identifier de façon unique une instance de la PRC à partir des valeurs des attributs qu elle contient. DefValPart sert à spécifier la valeur par défaut de l objet défini; elle doit être du type spécifié dans Syntax. Object-Group Il est utile de définir des conformance groups comme étant un ensemble de PRCs qui sont en relation et de leurs attributs. La macro Object-Group sert à définir l ensemble des attributs appartenant à un conformance group et donc des PRCs auxquels ils appartiennent. 31

32 La définition de cette macro est la suivante: OBJECT-GROUP MACRO ::= TYPE NOTATION ::= ObjectsPart "STATUS" Status "DESCRIPTION" Text ReferPart VALUE NOTATION ::= value(value OBJECT IDENTIFIER) Comme précédemment, Status ne peut prendre qu une de ces trois valeurs: current, deprecated et obsolete et Referpart est une référence. La clause ObjectsPart est obligatoire et contient l ensemble des attributs appartenant au conformance group ; ces attributs doivent appartenir au module dans lequel on définit ce conformance group. Il est obligatoire que chaque attribut défini dans un module appartienne à un groupe. Module-Compliance Cette macro permet de définir des contraintes à respecter pour l implémentation d un ensemble de modules de la PIB. Les spécifications du module compliance permettant de créer des modules de façon standard peuvent être définies dans le module ou dans un autre module. La définition de cette macro est la suivante: MODULE-COMPLIANCE MACRO ::= TYPE NOTATION ::= "STATUS" Status "DESCRIPTION" Text ReferPart ModulePart VALUE NOTATION ::= value(value OBJECT IDENTIFIER) Dans cette macro aussi, Status ne peut prendre qu une de ces trois valeurs: current, deprecated et obsolete et Referpart est une référence. 32

33 ModulePart est utilisé pour nommer les différents modules soumis aux contraintes définies dans le Module Compliance. Pour chaque module, on spécifie le nom et deux clauses: MandatoryPart et CompliancePart. La MandatoryPart est constituée d un ensemble de mandatory groups qui sont des groupes dont on doit obligatoirement implémenter les attributs. La CompliancePart permet de définir les conditions qui, si vérifiées, imposent l implémentation des attributs des compliance groups qui y sont définis. Elle permet aussi de définir des contraintes supplémentaires sur un attribut grâce à la clause Object. Une macro supplémentaires a été définies pour implémenter les textual conventions utilisées dans la clause Syntax des macros. Textual-Convention Comme expliqué précédemment, une textual convention est un nouveau type créé à partir d un base type prédéfini. La définition de cette macro est la suivante: TEXTUAL-CONVENTION MACRO ::= TYPE NOTATION ::= DisplayPart "STATUS" Status "DESCRIPTION" Text ReferPart "SYNTAX" Syntax VALUE NOTATION ::= value(value Syntax) La valeur de la clause Syntax dans cette macro est un base type. La clause DisplayPart permet de décrire comment la valeur d une instance ayant pour Syntax cette textual convention doit être affichée. 33

34 PARTIE II 34

35 CHAPITRE 1 ONTOLOGIE & OWL 1-Définitions: 1.1-WEB SÉMANTIQUE: The Semantic Web is an extension of the current Web in which information is given welldefined meaning, better enabling computers and people to work in cooperation 1. Comme son nom l indique, le Web Sémantique permet de donner plus de sémantique ou de sens par rapport aux langages de programmation traditionnels. Il a pour but: - D arriver à un Web intelligent où les informations ne seront pas uniquement stockées dans l ordinateur mais aussi comprises par ce dernier - de transformer la multitude de pages Web en un gigantesque index hiérarchisé Elle permet donc aux outils utilisés par l homme de dépasser le stade d affichage des données, d automatiser les requêtes, d intégrer et de réutiliser les données dans des applications différentes. De plus, les moteurs de recherche qui ne peuvent actuellement répondre qu à deux sortes de questions ( Quelles sont les pages contenant le terme X? et Quelles sont les pages les plus populaires au sujet de Y? ) pourront alors répondre à des questions plus spécifiques sur base de mots-clés fournis ( Trouver l hôpital le plus proche ayant une machine IRM ). Qui dit sémantique, dit vocabulaire; il est donc nécessaire de mettre en place une manière de développer des vocabulaires spécifiques à un domaine: c est le rôle des ontologies. En effet, le Web Sémantique permet d identifier les ressources de manière unique et organisée autour d une ontologie. 1 Tim Berneers-Lee, James Hendler, Ora Lassila, The Semantic Web, Scientific American, May

36 1.2-Une Ontologie : Le terme ontologie vient de la philosophie où il signifie explication systématique de l existence. Dans le domaine de l intelligence artificielle, une ontologie est décrite comme une définition des termes et des relations de base du vocabulaire d un domaine ainsi que des règles qui indiquent comment combiner ces termes et relations pour pouvoir étendre le vocabulaire. En effet, une ontologie définit les termes utilisés pour décrire et représenter un champ d'expertise. Les ontologies associent les concepts de base d'un domaine précis et les relations entre ces concepts de manière compréhensible par les machines. Elles encodent la connaissance d'un domaine particulier ainsi que les connaissances qui recouvrent d'autres domaines, ce qui permet de rendre les connaissances réutilisables. Une ontologie a plusieurs qualités : Elle est explicite parce qu elle définit des concepts, des propriétés, des relations, des fonctions et des restrictions qui la forment. Elle est formelle car elle peut être lue et interprétée par des machines. C est une conceptualisation vu que c est un modèle abstrait et une vue simplifiée des ressources qu elles représente. L'intérêt de disposer d'un langage de description d'ontologies standard est de créer des ontologies pouvant être utilisées par différentes applications. Les ontologies fournissent les interfaces idéales entre les informations et les diverses applications qui souhaitent les utiliser à des fins de traitement. Les ontologies ouvrent la voie à de nombreuses applications: La complétion de requêtes (fournir les autobiographies lorsqu on demande les biographies ) La connexion de services par la mise en correspondance de leurs descriptions (un graphic novel est une sorte de bande dessinée ). La réponse à des requêtes impliquant des pages web distribuées sur le web (Si un vol pour Boston part à 17h et un train arrive à Charles de Gaule à 16h20 alors il est possible de faire Grenoble-Boston dans la journée en partant après 10h). 36

37 Il existe deux types d ontologies qui varient en fonction de leur complexité de représentation : La light ontology qui décrit des liens sémantiques simples du type est une sorte de et son inverse est représenté par ou, plus spécifiquement, est une sous-classe de. La heavy ontology qui permet la représentation de liens sémantiques plus spécifiques grâce à des restrictions et des contraintes comme fait partie de, est localisé dans, est possédé par ou est associé à. 1.3-Le Web Sémantique et les ontologies : Le web sémantique et l'utilisation des ontologies permettent : des possibilités de recherche améliorées une automatisation des tâches possibles bien plus importante une interopérabilité des systèmes. En effet, les ontologies offrent des capacités de recherche très puissantes parce que les recherches et la navigation prennent en compte les liens unissant les éléments d'informations et les contraintes définies sur ces éléments. De plus, chaque élément des documents étant représenté à l'aide d'une ontologie, il devient très facile d'automatiser des tâches définies à partir des données de cet élément. Enfin, les ontologies proposent une modélisation des informations totalement indépendante de l'application dans laquelle se trouvent ces informations. 2-LE CHEMIN VERS OWL 2.1-HTML (Hyper Text Markup Language): HTML est un langage utilisé pour la création de pages Web. Il consiste en des balises prédéfinies (Head, Body,...) permettant de créer la structure et la mise en forme de la page. 37

38 Ces balises contrôlent donc la forme du document mais ne permettent en aucune façon la gestion de son contenu: elles ne sont sémantiques ni pour l homme ni pour la machine. 2.2-XML (extended Markup Language) : XML est considéré comme le standard de transfert des données sur le Web. Il permet à l utilisateur de créer ses propres balises, contrairement à HTML. Il pourra écrire: <élève> <nom> Untel </nom> <prénom> Monsieur </prénom> <téléphone> 01/ </téléphone> <classe> 3ème INFO </classe> </élève> Ce langage permet de structurer les données et de faciliter les recherches: on pourra, par exemple, facilement lister tous les élèves qui sont dans la même classe. Les balises créées sont uniquement compréhensibles par l homme mais non par la machine qui ne pourra pas détecter des erreurs sémantiques comme par exemple: - un nom contenant des chiffres : <nom> 1234 </nom> - une balise <prix> insérée dans la balise <élève>: <élève> <nom> Untel </nom> <prénom> Monsieur </prénom> <prix> 250 </prix> <téléphone> 01/ </téléphone> <classe> 3ème INFO </classe> </élève> De même, étant donné que chaque utilisateur a le droit de créer ses propres balises, deux utilisateurs pourraient créer des balises de même nom mais à connotations différentes causant un problème dans les applications qui utilisent les deux définitions. Ainsi une balise sentence signifiant phrase et une balise sentence pour la sentence d un criminel pourraient prêter à confusion. Pour résoudre ce problème, il y a eu la création des XML Namespaces pour attribuer à chaque élément créé un identificateur unique évitant ainsi les confusions. 38

39 Ces identificateurs permettent à l ordinateur de faire la différence entre un élément et un autre sans, pour autant, qu il puisse les interpréter. D où le rôle d un modèle comme RDF. 2.3-RDF (Resource Description Framework) : RDF est un modèle conceptuel, abstrait et formel qui permet de décrire tout élément simplement et sans ambiguïté selon un mécanisme basé sur des déclarations RDF. Une notion très importante dans RDF est la notion des URIs (URI : Uniform Resource Identifier). Une URI permet d identifier une ressource de manière unique permettant ainsi de maintenir la cohérence. Elle constitue un nom (identificateur) pour une ressource sans nécessairement permettre de la localiser. Un exemple bien connu d une URI est l URL (Uniform Resource Locator) qui permet d identifier et de localiser la ressource. Les URIs sont décentralisées vu l immensité du Web; elles ne sont pas gérées par une organisation unique mais peuvent être créées par n importe quel utilisateur. D où le fait que plusieurs utilisateurs pourront créer des URIs différents représentant la même ressource; c est un compromis à accepter pour progresser dans la Web Sémantique. Ainsi, toute ressource représentée par une URI est considérée comme étant sur le Web. Une déclaration RDF est une phrase composée d un triplet d URIs : un sujet, un verbe et un complément. Ces triplets sont machine processable de sorte que les ordinateurs peuvent les traiter comme s ils comprenaient leurs significations. Cependant, RDF n est pas un langage de programmation : il ne possède pas de syntaxe unique mais il peut être traduit sous plusieurs formes. Ce n est qu un modèle conceptuel qui ne permet donc pas encore de représenter des ressources. RDF est donc un modèle : - R : Resource : toute chose représentée par une URI - D : Description : les propriétés de cette ressource - F : Framework : un modèle à implémenter 39

40 Exemple : <rdf:rdf xmlns:rdf=" xmlns:dc=" xmlns:ws=" > <rdf:description rdf:about=""> <dc:creator rdf:parsetype="resource"> <ws:name>monsieur Untel</ws:name> </dc:creator> <dc:title>web Sémantique</dc:title> </rdf:description> </rdf:rdf> Cet exemple décrit un article qui a pour titre WEB Sémantique et qui est écrit par Monsieur Untel. Le triplet est donc : créateur, titre et nom formant la phrase : Monsieur Untel est le créateur de WEB Sémantique. Le modèle RDF utilise la syntaxe RDF/XML afin de pouvoir transporter les données et de les rendre exploitables par les machines. Cependant, il ne permet pas de vérifier la cohérence des données comme, par exemple, de vérifier que la valeur d un champ date de naissance est bien une date. D où la nécessité d avoir un langage qui permet de donner un sens aux données et de restreindre leur champ d utilisation: une date de naissance ne peut pas être attribuée à un livre. RDF Schema : RDF Schema est un langage simple permettant d implémenter le modèle RDF. Il permet de définir des concepts grâce à trois notions principales : - la ressource (rdfs : Ressource) : classe mère de tout élément - la classe (rdfs : Class) : ensemble de plusieurs objets - la propriété (rdfs : Property) Principales propriétés de RDF Schema RDF Schema permet de créer une hiérarchie de classes et de propriétés comme dans les langages orientés objet grâce à la notion de subclassof et subpropertyof. 40

41 <rdfs :Class rdf :about= Tintin /> <rdfs :subclassof rdf :Resource= BD > De plus, RDF Schema permet d instancier une classe en utilisant rdf:type. RDF Schema permet surtout de définir un range et un domain à une propriété afin de restreindre son champ d utilisation. En effet, rdfs:domain précise la classe à laquelle appartient le sujet du triplet utilisant la propriété et rdfs : range précise la classe à laquelle appartient l objet du triplet utilisant la propriété. Par exemple, la propriété a-pour-auteur doit être associée un livre à un auteur; on définira donc comme domain Livre et comme range Auteur. <rdf: Property rdf :about= a-pour-auteur /> <rdfs:range rdf:resource= #Auteur /> <rdfs:domain rdf:resource= #Livre /> Bien que RDF Schema offre une façon de créer des restrictions sur les propriétés et leur champ d utilisation, il n est pas suffisant dans certains cas; DAML+OIL va l améliorer. 2.4-OWL (Ontology WEB Language) : Introduction: Alors que les premiers langages utilisés pour le développement d outils et d ontologies n ont pas été définis pour être compatibles avec le Web (encore moins avec la Web Sémantique), OWL est un langage d ontologies Web. En effet, OWL, qui est le Web Ontonlogy Language, est un vocabulaire XML basé sur RDF et permettant de définir des ontologies Web structurées. L'existence d'ontologies produites à partir du même standard autorise une intégration plus riche et garantit l'interopérabilité des données au travers des frontières applicatives. 41

42 De plus, OWL facilite l interprétation par la machine des informations du Web et est, de ce fait, utilisé dans les applications destinées à traiter les informations et non à les présenter uniquement à l utilisateur. OWL est un langage qui étend RDF Schema en utilisant des notions qui y ont été définies (resource, class, relation, type, subclassof, range,domain,...) et en permettant, en plus, la création de relations complexes entre différentes classes et la définition de contraintes plus précises sur des classes et des propriétés. OWL est défini en trois sous langages : - OWL Lite : il est utilisé par les utilisateurs voulant définir une hiérarchie et des contraintes simples - OWL DL : il est utilisé par les utilisateurs voulant définir des restrictions plus générales tout en respectant les logiques de description - OWL Full : il est utilisé par les utilisateurs voulant définir des restrictions générales sans aucune contrainte à respecter pour le faire Les spécifications RDF et OWL constituent une partie de le Web Sémantique qui est basée sur les concepts suivants : - un schéma de nommage global grâce aux URIs - une syntaxe standard pour décrire une ressource : RDF - une façon standard de décrire les propriétés de cette ressource : RDF Schema - un moyen standard de décrire les relations entre ressources : OWL Structure des ontologies OWL : Le Web Sémantique est, par définition distribuée ; d où la nécessité de créer des ontologies reliées entre elles et d utiliser OWL pour le faire. OWL permet la création d un monde ouvert ; une classe C1 créée au départ dans une ontologie C1 pourra être étendue après dans d autres ontologies qui en ont besoin. Malheureusement, si cette classe est en contradiction avec une classe existant dans la nouvelle ontologie, c est au concepteur de l ontologie de le remarquer et de trouver une solution; il n y a pas d autre moyen de détecter cette contradiction. 42

43 Les espaces de nommage Afin de pouvoir utiliser les termes d une ontologie, il faut une indication sur les vocabulaires utilisés. Ainsi, dans chaque ontologie, on intègre un ensemble de déclarations d espaces de nommage dans une balise <rdf :RDF>. Ces déclarations permettent d interpréter sans ambiguïté les URIs et de faciliter la lecture du reste de l ontologie. Une ontologie OWL commence donc, en général, par la déclaration des espaces de nommage comme suivant: <rdf :RDF xmlns = xmlns :vin= xmlns :owl = > La première ligne, <xmlns=...>, identifie l espace de nommage implicite de l ontologie vu qu elle ne présente pas de suffixe. La seconde ligne, <xmlns :vin...> identifie l espace de nommage de l ontologie relative au préfixe vin: ; ainsi, tous les éléments ayant le préfixe vin: devraient être interprétés comme se référant à des éléments issus de l espace de nommage précisé ( ). La troisième ligne est une déclaration OWL conventionnelle qui introduit le vocabulaire OWL. Les éléments de base d OWL : Les éléments de base d OWL sont : o les classes : Toute classe en OWL est implicitement une sous-classe de la classe owl :Thing. Pour créer une nouvelle classe, on écrit : <rdf :Class rdf:id= Personne > Pour créer une sous-classe d une classe existante, on écrit : <owl:class rdf:id= Homme > <rdf:subclassof rdf:resource= #Personne > </owl:class> 43

44 o les individus (individuals): Un individu est une instance d une classe. Il est créé grâce à la propriété de RDF rdf:type. Pour instancier une classe (ou créer un individu), on écrit: <owl:thing rdf:about= #M.X > <rdf:type rdf:resource= #Homme > </owl:thing> o les propriétés: elles permettent de décrire les membres d une classe. Elles sont de deux types : ObjectProperty : ce genre de propriété prend ses valeurs d une classe de OWL <owl:objectproperty rdf:id= àbasedepommes > <rdfs:domain rdf:resource= #Tarte > <rdfs:range rdf:resource= #TarteAuxPommes > </owl:objectproperty> DataTypeProperty : ce genre de propriété se voit attribuer un type bien défini : integer, float, date. <owl:datatypeproperty rdf:id= Nom > <rdfs:domain rdf:resource= #Personne > <rdfs:range rdf:resource= &xsd;string > </owl:objectproperty> Comme pour les classes, on peut créer une hiérarchie de propriétés grâce à subpropertyof. <owl:objectproperty rdf:id= Nom > <rdfs:subpropertyof rdf:resource= #Identité > <rdfs:range rdf:resource= #Personne > </owl:objectproperty> Caractéristiques d OWL : Dans la création d ontologies, OWL utilise des notions de RDF Schema (Class, subclassof, Property, SubProperty, domain ) et de DAML+OIL (inverseof, TransitiveProperty, cardinality, maxcardinality, ). 44

45 Cependant, afin de pouvoir faciliter l expression des relations entre les données et donc leur identification, OWL rajoute certaines notions concernant : o L égalité et l inégalité : equivalentclass : utilisé pour dire que deux classes sont équivalentes et ont donc les mêmes instances comme, par exemple, les classes Livre et Bouquin : <owl:class rdf:id="wine"> <owl:equivalentclass rdf:resource="#vin"> </owl:class> equivalentproperty : utilisé pour décrire des propriétés équivalentes ; une sous-propriété de la première est automatiquement une souspropriété de la seconde. SameAs : utilisé pour dire que deux individuals sont les mêmes. DifferentFrom : utilisé pour dire que deux individuals sont nécessairement différents. AllDifferent : utilisé pour dire que tous les individuals sont différents les uns des autres. o Les caractéristiques d une propriété : SymmetricProperty : utilisé pour une propriété qui, reliant un individual x à un autre y, établit automatiquement la même relation entre y et x tout comme la relation d amitié : x est l ami de y implique automatiquement que y est l ami de x. <owl:objectproperty rdf:id="apourami"> <rdf:type rdf:resource="&owl;symmetricproperty" /> <rdfs:domain rdf:resource="#personne" /> <rdfs:range rdf:resource="#personne" /> </owl:objectproperty> FunctionalProperty : utilisé pour préciser que la propriété ne peut avoir que zéro ou une valeur pour un individual. 45

46 InverseFunctionalProperty : pour préciser que l inverse de cette propriété est une FunctionalProperty. o Les restrictions sur les propriétés : allvaluesfrom : cette restriction est attribuée à une propriété dont toutes les valeurs appartiennent à des classes spécifiques. <owl:class rdf:id="bd"> <rdfs:subclassof rdf:resource="#livre" />... <rdfs:subclassof> <owl:restriction> <owl:onproperty rdf:resource="#apourauteur" /> <owl:allvaluesfrom rdf:resource="#auteurdebd" /> </owl:restriction> </rdfs:subclassof>... </owl:class> En effet, un auteur de BD doit obligatoirement être une instance de la classe contenant tous les auteurs de BD. somevaluesfrom : cette restriction est attribuée à une propriété dont certaines valeurs appartiennent à des classes spécifiques. 46

47 CHAPITRE 2 Editeurs d Ontologie 1-Construction d une Ontologie Après avoir compris c est quoi une ontologie et après avoir vu les langages qui ont Servi à construire des ontologies arrivant au langage OWL qui est le plus important Nous allons dans cette partie parler des étapes de la construction d une Ontologie. Les Ontologies ne sont pas construites toutes de la même manière.un nombre important de langages peut être utilisé ex : OWL, KIF,DAM+OIL, parmis tous ces langages,les développeurs choisissent celui le plus riche et le plus expressif en informations et en outils. Les étapes de bases pour la construction d une Ontologie sont simples : 1. Assembler les informations Assembler les ressources d informations appropriées, les étudier pour pouvoir les décrire par la suite dans l environnement choisi pour la création de l ontologie. 2. Organizer l ontologie Il faut essayer de faire la structure conceptuelle du domaine, ou bien dessiner les grandes lignes. C.a.d identifier les principaux concepts des domaines, leurs propriétés principales, les relations entre les concepts, distinguer les instances de chaque concept,.. 3. détailler l ontologie Ajouter des concepts, des relations, des individus comme détails nécessaires pour satisfaire les buts de l ontologie 47

48 4. Verifier le travail Après avoir achevé le travail il est nécessaire de vérifier sa syntaxe, sa logique, et surtout s assurer des résultats obtenus. 5. légalité de l ontologie L étape finale de n importe quel effort est la vérification finale de l ontologie en l exposant à des experts, ensuite on pourra publier le travail avec son environnement de déploiement. 2-Les outils de définition des Ontologies Pour faire un projet d ontologie, la première réaction à faire est de trouver l éditeur d ontologie le plus adéquat pour notre travail. Pour cette raison on a exposé un tableau de comparaison entre quelques éditeurs qu on a trouvé qu ils nous semblent important pour notre travail et à la fin de cette comparaison on choisira un, sur lequel on travaillera. 48

49 Tool The software tool for editing ontologies Apollo Contextia COPORUM OntoBuilder Differential Ontology Editor (DOE) Domain Ontology Management Environment (DOME) Modeling Features/Limitations Classes with slots plus relations; functions; hierarchical views. Basic concepts and relations with datatypes are represented in schemas. Base Language The native or primary language used to encode the ontology OKBC model Express RDFS XML & CGXML CLASSIC & FaCT Web Support & {Use} The representational and logical qualities that can be expressed in the built ontology Support for Webcompliant ontologies (e.g., URIs), and {use of the software over the Web (e.g., browser client)} No, but {server is planned}. Referenced ontologies (URLs); URIs Load ontology by URL ac- {Web cess} Import/Export Formats Other languages the built ontology can be serialized in Graph View CLOS; OCML No, but planned. Entity relation diagrams; XML Schema DAML+OIL; RDF(S) DAML+OIL; RDFS Consistency Checks The extent The degree to to which the built ontology which the syntactic, referen- can be tial and/or created, logical correctness debugged, of the edited ontology can and/or compared be verified di- automatically rectly in graphic form For editing single ontology (using First- Step XG). Browsing of ontology. No, but tree view. OKBC; XML ER diagrams Yes Basic concepts and relations are represented with single inheritance. Representation of concepts and relations extracted from content may be extended with WordNet information. Creates lattice of concepts and lattice of relationships between concepts, plus a set of instances. Concepts cannot be defined intentionally with constraints. Only types of the domains of relationships can be specified. No axiom editor is provided. Concepts, relations and constraints are mapped to ER-like specifications. {Web based repository; Web services in development} Express model (ISO 10303) validation; cross-ontology consistencies RDF consistency via repository. Arity and type inheritance on relation domains; detects cycles in hierarchies. Yes 49

50 Tool The software tool for editing ontologies Enterprise Semantic Platform (ESP) including Knowledge Toolkit Modeling Features/Limitations Base Language The native or primary language used to encode the ontology Graph XML & Web Support & {Use} The representational and logical qualities that can be expressed in the built ontology Support for Webcompliant ontologies (e.g., URIs), and {use of the software over the Web (e.g., browser client)} Description models composed of hierarchical categories and attributes with named relationships. Type system for heterogeneous media content. Instances supported by simple constraints on entities (cardinality, range) and entity properties, as well as inferencing. Automatic assertion and maintenance of instances is possible. URIs; {partial HTML client; HTTP API} Import/Export Formats Other languages the built ontology can be serialized in XML; (RDF(S) is planned) Graph View Consistency Checks The extent The degree to to which the built ontology which the syntactic, referen- can be tial and/or created, logical correctness debugged, of the edited ontology can and/or compared be verified di- automatically rectly in graphic form Connected tree browsing via TouchGraph Yes, includes automatic and user interactive checks; dynamic content management. Integrated Distinguishes between OWL {Web client - KIF; UML; UML diagramtology Top-level on- Ontology properties and relations; (based on control panel} RDB; XML consis- Development allows contexts; default KIF; not DTD tency per Environment reasoning; temporal model related to Guarino & relations; higher-arity relations; W3C We- Welty. meta-properties and bont lan- meta-relations. guage of same name.) JOE Basic concept and relations KIF No ER (LDL++) No No modeling ala ER,support attributes, queries, constraints, searching for a specific node (ER) in the onyology KAON (including Extends RDFS with sym- KAON {Browsing RDFS No Yes, for evolu- OI- metric, transitive and in- (proprietary ontologies tion of ontol- Modeller) verse relations, relation extension via KAON ogy. cardinality, metamodeling, of RDFS) Portal; Web etc. Similar to F-Logic using axiom patterns. services API under devel- Editor currently opment} only supports concept hierarchy. 50

51 Tool The software tool for editing ontologies OntoEdit Ontology Builder Server & Protégé-2000 Modeling Features/Limitations F-Logic axioms on classes and relations; algebraic properties of relations; creation of metadata; limited DAML property constraints and datatypes; no class combinations, equivalent instances. Classes with slots, datatypes and cardinality constraints; node documentation; inclusion. No axioms. Multiple inheritance concept and relation hierarchies (but single class for instance); meta-classes; instances specification support; constraint axioms ala Prolog, F-Logic, OIL and general axiom language (PAL) via plug-ins. Base Language The native or primary language used to encode the ontology F-Logic Partial OKBC model OKBC model Web Support & {Use} The representational and logical qualities that can be expressed in the built ontology Support for Webcompliant ontologies (e.g., URIs), and {use of the software over the Web (e.g., browser client)} Resource URIs Import/Export Formats Other languages the built ontology can be serialized in RDFS; F- Logic; DAML+OIL (limited); RDB Fully qualified RDFS & names; DAML+OIL {HTTP (future) browser and server} Limited RDF(S); XML namespaces; Schema; RDB {can run as schema via applet; access Data Genie through servlets} plug-in; (DAML+OIL backend due 4Q'02 from SRI) Graph View Consistency Checks The extent The degree to to which the built ontology which the syntactic, referen- can be tial and/or created, logical correctness debugged, of the edited ontology can and/or compared be verified di- automatically rectly in graphic form Yes, plug-in No via Yes, via Onto- Broker Limited to term validity and graph cycles. Browsing Plug-ins classes & adding global properties via GraphViz plug-in; nested graph views with editing via Jambalaya plug-in. for & checking constraint axioms: PAL; FaCT. 4.1-Protégé : Ontology Web Editor : Parmis tous les éditeurs on a choisi Protégé pour faire notre Ontologie, Parce que Protégé, est l environnement le plus adéquat pour faire une Ontologie,il supporte toutes les activités et tous les besoins d une Ontologie, comme : classes, sous classes, propriétés, étendre des Ontologies, namesapaces, et surtout il permet de faire des contraintes.ces activités et d autres activités ne sont pas toutes supportés par les autres éditeurs, 51

52 de même protégé offre un TUTORIAL, très détaillé qui facilite le travail de l utilisateur, de plus son interface graphique est simple et facile et offre à l utilisateur la possibilité de tester la validité de son ontologie. De même Protégé : 1-Est un outil qui permet à l utilisateur de : -construire un domaine d Ontologie -adapter les formes de données -entrer des données. 2-Est une plateforme Open Source qui peut être étendue avec d autres options pour introduire des tables, des diagrammes, des composants d animation pour pouvoir accéder à d autres systèmes d applications. Par exemple on peut étendre Protégé par OWL PLUGIN qui permet de faire : - sauvegarder des ontologies OWL et RDF -modifier et visualiser les classes OWL et leurs propriétés - 3-Est une librairie que d autres applications peuvent utiliser pour accéder aux informations de bases. l interface graphique de Protégé est une interface claire et simple, nous l illustrons Par un exemple pris de protégé dans lequel on a fait une Ontologie de «PIZZA» : 52

53 53

54 Chapitre 3 Ajout d un plugin à protégé 1-Introduction Dans ce chapitre nous allons expliquer, comment on a ajouté un plugin à Protégé qui à aider l utilisateur à construire une PIB. sert 2-Principe d une PIB dans Protégé Il est important de savoir que le travail que nous sommes entrain de faire va être ajouté à une plateforme existante appelée ASWA. Comme on a vu la représentation de n importe quelle PIBs suit la structure SPPI qui est bien définie dans les RFCs, mais une étude a été faite et on a conclu un modèle simplifié a suivre pour pouvoir créer n importe quel PIB, ce modèle est détaillé dans le paragraphe suivant. 3-modèle d une PIB -N importe quelle PIB particulière exemple celle de filtrage doit dériver de «PIB», pour que son OID montre qu elle est une PIB. -Au début une PIB commence par un module, le module peut être constitué d un ou de plusieurs Groupes, chaque groupe est constitué d une ou de plusieurs Tables, chaque table est constituée d une seule Entrée dans laquelle on peut créer plusieurs instances (qui seront les politiques), et chaque entrée est constituée d un ou de plusieurs attributs. 54

55 On illustre ceci par le schéma ci-dessous : PIB Module-Identity PibMeta- Classss Module n Groupe 1 Module 1 Groupe n OT-Table Table 1 Table 1 Table n OT-Entry Entry 1 OT-Attributes Attribute 1 Attribute n On remarque sur le schéma ci-dessus, cinq nouvelles notions : 1- Module-Identity 2- PiBMetaclass 3- OT-Table 4- OT-Entry 5- OT-Attributes Ce ne sont que les types des éléments de la PIB. En effet dans protégé une classe par défaut a comme type «owl : Class» et donc chaque sous classe hérite de sa classe mère toutes ses propriétés et elle est aussi de type «owl : Class». 55

56 Exemple : Classe mère -propriété 1-a -propriété 1-b Sous classe -propriété 1-a -propriété 1-b -propriété 2-a Cela nous cause des problèmes car nos cinq éléments sont que des classes qui dérivent l une de l autre donc les propriétés de l une sont hérités par l autre, mais ceci n est pas conforme aux études, car les recherches faites ont précisé que les propriétés de chaque élément (classe) ne sont pas communes exemple : la classe Entry qui est la sous classe de Table n a pas toutes les propriétés de cette dernière. Donc on a un problème à résoudre, pour qu une sous-classe n héritera pas tout de sa classe mère. Heureusement protégé à la solution car il nous donne la chance de crée des «métaclasses», ces métaclasses sont des classes particulières, pour chacune on peut lui créer ses propres champs. Par la suite si on veut crée une classe ayant ces champs on peut la crée de type «la métaclasse convenable» et par la suite n importe quelle sous classe de la classe mère ne verra jamais les champs de la métaclasse, et donc n héritera pas de sa mère ces champs, à la rigueur elle peut hériter les propriétés seulement. Donc dans la classe mère tous ce qui vient d une métaclasse n est pas vu par les sous classes, et tous les autres le sont. Exemple : Metaclasse 1 -champs 1 -champs 2 56

57 Classe mère Type :Metaclasse 1 -propriété 1 -champs 1 -champs 2 Sous Classe Type : Classe -propriété 1 -propriété de sous classe Donc après cet exemple on a bien compris que les cinq notions du schéma sont les métaclasses, et chaque classe ou bien élément de la PIB a comme type une métaclasse exemple : la classe «Entry» a comme type la métaclasse «OT-Entry». Ayant compris le modèle suivi pour la construction d une PIB nous terminons cet paragraphe par un schéma pris de protégé qui montre que dans la PIB de Diffserv, Le module est appelé PibFiltrage, il est de type= ModuleIdentity (indiqué juste en dessous des noms des Widgets), sa métaclasse est : ModuleIdentity. 57

58 4-Le programme Java Le but de ce programme consiste à faciliter la construction de n importe quelle PIB à l utilisateur, et cela en ajoutant une nouvelle «Widget» dans protégé, qui permet à l utilisateur de faire rentrer les noms des classes de sa PIB, et notre programme relie implicitement chaque classe à sa métaclasse (type) convenable. 4-1-Explication du travail Dans cette explication on ne rentrera pas dans les détails de programmation, mais on expliquera seulement les différentes démarches du travail. Démarches du travail : 1-nous avons profité du fait que protégé est Open-Source, et donc on a pu ajouter un plugin à protégé de la façon suivante : a- on crée le programme java de notre Widget ex :PibTabWidget.java b- dans le folder «plugins» de protégé on crée un folder «méta-inf»dans lequel on crée un fichier indiquant le package ou se trouve le fichier «.class» de notre programme, et on valide l apparition du du widget ex : Name: pib.pibtabwidget.class Tab-Widget: True Cela indique donc que notre fichier.class se trouve dans le folder «Pib». En effet protégé cherche dans ce package pour savoir ou est le programme qui va faire fonctionner la nouvelle tab. c- reste à faire une façon pour qu à la compilation le fichier «.class» apparaisse dans le folder «pib». 58

59 2- pour que ce plugin sera visible à l œil, dans protégé, on doit faire : PROJECT ensuite CONFIGURE, on remarque qu une nouvelle tab apparaît, qui est celle qu on a nous même crée «PibTabWidget», on la sélectionne et par la suite notre Widget apparaît 3-Cette Widget a cinq entrées initiales :-Module -Groupe -Table -Entry -Attribute Le travail de l une est similaire au travail des quatre qui restent, on donnera deux exemples : -exemple1 :l entrée «Module» : l utilisateur peut soit choisir un module des modules cités dans le combobox soit crée un nouveau module en tapant son nom ex : «mod1» et en cliquant sur le boutton «ADD», par la suite si on retourne au Widget «owl classes» on remarque que cette classe a été crée et si on clique la dessus on peut vérifier qu elle a été crée de type ModuleIdentity, nous illustrons ceci par les deux schémas suivant : Schéma 1-a : on ajoute «mod 1» 59

60 Schéma 1-b : On vérifie la création de «mod 1» de type «ModuleIdentity» : -exemple 2 :l entrée «Entry» : l utilisateur peut soit choisir une entrée des entrées cités dans le combobox «choose entry» soit crée une nouvelle entrée en tapant son nom ex : «entry1» et il peut aussi choisir le type de cette entrée crée du combobox «choose entry type», ex : «OT_Entry_PibIndex», ensuite en cliquant sur le bouton «ADD» elle va être crée. Notons qu on doit choisir : le module, le groupe et la table, avant de crée notre entrée, sinon on ne peut pas la créer. Dans mon exemple : - Le module est «mod1» - La groupe est «groupe1» - La table est «table1» Et donc après avoir tout crée si on retourne au Widget «owl classes» on peur vérifier que l entrée «entry1» a été bien crée de type «OT_Entry_PibIndex» et elle est une sous classe de «Table 1». Nous illustrons ceci par deux schémas : 60

61 Schéma 2-a : création de l entrée «entry1» de type «OT_Entry_PibIndex»: Schéma 2-b : vérification de la création de l entrée, de son type, et quelle est sous classe de «table1» 4-2-Conclusion Cette Widget qu on a crée «Pib Editor» facilite la création d une PIB, car l utilisateur laisse au programme le travail de choisir le type de chaque classe et sa position. Donc l utilisateur n a qu à choisir les noms. 61

62 Chapitre 4 Implémentation du protocole COPS 1-Introduction : Dans ce chapitre nous allons implémenter le protocole COPS avec tous ses messages, en effet nous avons à notre disposition une plateforme appelée «ASWA», et nous allons ajouter notre travail à cette plateforme. 2-C#.NET : L environnement.net à été crée par Microsoft en 2003, donc il est quand même nouveau, sa version est L environnement.net comporte les produits suivants : -Microsoft Visual Basic.NET -Microsoft Visual C#.NET -Microsoft Visual C++.NET -Microsoft Visual J#.NET -Crystal reports for Visual studio.net -Microsoft Application Center test En ce qui concerne l installation du.net, elle est simple mais avant de l installer il est nécessaire d avoir déjà installé le IIS le PC à partir du CD de notre OS (Windows) par la suite on pourra installer le.net et on s assure que ça va bien marcher. Ce qui nous intéresse dans l environnement.net est le C#.NET puisque ça va nous permettre d implémenter le protocole COPS en utilisant les services web Le C#.NET est très proche du C++, puisque les deux sont orientés objet, il suffit de connaître ce dernier pour pouvoir entamer la programmation en C# sans aucune difficulté. 62

63 Le C#.Net donne à l utilisateur la possibilité de créer une application et un Web Service, donc l utilisateur peut implémenter la communication d un client (Application) avec un serveur, et aussi la communication entre 2 ou plusieurs serveurs, cette possibilité caractéristique de C#.NET à permis la création d ASWA. 3-ASWA : La plateforme ASWA est une plateforme de réseaux actifs basée sur les services web, ASWA a été implémentée sur C#.Net. Les messages routés dans cette plateforme sont des messages SOAP et comme SOAP est basé sur HTTP cette caractéristique a rendu ASWA simple à déployer puisque n importe quel OS supporte HTTP. 4-Explication du programme : 4-1-Explication littérale : Nous avons implémenté le protocole COPS en C#.Net en utilisant des Services Webs et on a ajouté notre travail a ASWA. Comme on a déjà vu le protocole COPS n est autre q un ensemble de messages protocolaires échangés entre le PDP et le PEP, ce qu on a simulé comme messages pour avoir une gestion de politique est le suivant : -Le PEP voulant une configuration envoie au PDP un message «Client OPEN» -Le PDP en recevant ce message il va lui répondre par un message «Client Accept» -le PEP donc en recevant ce message il connaît que ce PDP est devenu Responsable de sa configuration donc il lui envoie un message «configuration Request». -le PDP en recevant ce message il connaît donc que le PEP demande une Configuration, le PDP donc prend une copie de sa PIB et l envoie au PEP Dans un message «sollicited decision» -Lorsque le PEP reçoit donc ce message, il va configurer sa PIB. -De temps a autre le PDP pourra envoyer des «unsollicited decision» au 63

64 PEP pour enlever/installer un décision, ou bien pour enlever/installer toute La PIB. 4-2 Utilisation du programme : 1- On a trois programmes PEP, PDP, initial_interf_pdp. 2- La PIB du PEP et celle du PDP sont des fichiers OWL, qui s appelle newpib.owl, qui se trouve respectivement : C:\Inetpub\wwwroot\PEP\newpib.owl C:\Inetpub\wwwroot\PDP\newpib.owl Donc a chaque fois qu on va vérifier si une politique (instance) se Trouve dans la pib du PEP il faut ouvrir le fichier newpib.owl du PEP Et chercher cette politique. 3-Pour démarrer ASWA il suffit d ouvrir le programme initial_interf_pdp et de lui faire un build (F5), donc on aura l interface graphique suivante : 64

65 1- Pour démarrer la communication entre PEP et PDP c.a.d pour que le PEP se connecte au PDP et pour que le PDP lui envoie une «sollicited Decision» et configurer toute la PIB du PEP, on clique le bouton Run Après avoir cliqué ce bouton, on remarque que la pib du PEP est configurée Exctement comme celle du PDP (newpib.owl(pep)=newpib.owl(pdp)). Et on obtient le message suivant dans le champ notification 2- Envoyer des messages «unsollicited» du PDP vers le PEP : a- Si on veut envoyer toute la PIB du PDP au PEP on clique sur b- Si on veut enlever toute la configuration du PEP on clique sur On peut s assurer que toute la PIB du PEP a été enlevé, en consultant Le fichier newpib.owl du PEP1 si on l ouvre il est vide. c- Si on a une instance dans la PIB du PDP et on veut l ajouter à la PIB du PEP, il suffit d écrire le nom de cette instance, ensuite On choisi ««install», et on clique sur send : 65

66 Dans l exemple ci-dessus, on a choisi d installer l instance (politique) «basecapsentry1» Cette instance existe dans la PIB (newpib.owl) du PDP et après avoir cliquer sur send pour L installer dans la PIB (newpib.owl) du PEP, en ouvrant ce fichier on peut s assurer Qu elle à été installé à la fin du fichier juste avant la ligne «</rdf :RDF>». Pour vous fixer les idées j ai moi-même ouvert ce fichier et je vous ai copié ci-dessous Sa fin pour voir que ce qui est en rouge est l instance copiée et ce qui est en bleue est La Fin du fichier owl. <qosbaseifcapsentry rdf:id="basecapsentrytina"> <VALUE rdf:datatype=" >la valeur </VALUE> <rdfs:comment rdf:datatype=" >je l'ai cree mis meme</rdfs:comment> </qosbaseifcapsentry> </rdf:rdf> <!-- Created with Protege (with OWL Plugin 1.1 beta, Build 110) --> 66

67 b- Si on veut maintenant enlever cette instance donc il suffit de faire la même chose Mais en cliquant cette fois ci sur «remove». Pour s assurer que la politique a été Bien enlevée on ouvre le fichier newpib.owl du PEP et on remarque que la partie Rouge précédente est disparue, donc l instance (la politique) est enlevée. d- Pour observer tous les messages COPS rentrées au PEP il suffit de cliquer sur le link «Message entrant PEP» sur l interface graphique. 5-Conclusion : C est ainsi qu on a bien simulé le protocole COPS avec tous ces détails en utilisant les WEB Services mais il reste encore les messages d erreurs et la fermeture de la connexion, Qui ne sont pas inclus. 67

68 Chapitre 5 OWL Rules Ontology (ORL) 1-Définition de ORL Le langage OWL ajoute des définitions expressives au Web Sémantique, mais le problème est que ce langage a des limitations, en particulier avec la définitions des propriétés, pour résoudre ce problème, OWL a été étendu avec un langage plus expressif pour la description des propriétés, ce langage est appelé ORL (OWL Rules Language). En réalité ORL est un ensemble de règles qui étendent OWL pour pouvoir dépasser toutes ses limitations. 2-Syntaxe ORL : On vient de mentionner dans le paragraphe dessus que ORL est un ensemble de règles, ces règles ont une forme ou une syntaxe bien définie, cette forme est une implication entre un antécédent (body) et un conséquent (Head) : Antecedent (head) consequent (body). Une règle a le sens suivant : «quand les conditions spécifiées dans l antécédent sont vérifiées, alors les conditions spécifiées dans le conséquent le sont aussi.» L antécédent et le conséquent d une règle sont formés d un ensemble d atomes ou d aucun atome.les atomes peuvent avoir les formes C(x),P(x,y),sameAs(x,y) ou Different- From(x,y), où C est une description de OWL DL, P est une propriété OWL, Et x, y sont soit des variables soit des individus OWL, soit des datavalues de OWL. Les atomes multiples dans un antécédent sont traités en conjonction, un antécédent vide est considéré comme étant vérifié (satisfait par n importe quelle interprétation), donc le conséquent doit être aussi satisfait par n importe quel interprétation. 68

69 Les atomes multiples dans un conséquent sont traités séparément, c.a.d il faut qu elles soient toutes satisfaites pour que l antécédent soit satisfait. Un conséquent vide est traité comme étant non vérifié (il n est satisfait quelque soit l interprétation de l antécédent). 3-Exemple: En appliquant la syntaxe qu on vient de définir, on va donner l exemple de la règle qui dit que la combinaison des deux propriétés parent et frère implique la propriété oncle, cette règle peut être écrite de la façon suivante : Parent (?a,?b) +frère (?b,?c) oncle(?a,?c) Si John a Mary comme parent et Mary a Bill comme frère, alors cette règle assume que John a Bill comme oncle. Cet exemple est écrit en langage XML et en suivant la syntaxe des règles déjà définie: <owlx:rule> <owlr:antecedent> <owlr:individualpropertyatom owlr:property= parent > <owlr:variable owlr:name= a /> <owlr:variable owlr:name= b /> </owlr:individualpropertyatom> <owlr:individualpropertyatom owlr:property= brother > <owlr:variable owlr:name= b /> <owlr:variable owlr:name= c /> </owlr:individualpropertyatom> </owlr:antecedent> <owlr:consequent> <owlr:individualpropertyatom owlr:property= uncle > <owlr:variable owlr:name= a /> <owlr:variable owlr:name= c /> 69

70 </owlr:individualpropertyatom> </owlr:consequent> </owlr:rule> 4-Notre environnement: Dans ce paragraphe nous allons récapituler en quelques mots notre environnement pour pouvoir comprendre où? Quand? Et pour quoi? Nous allons utiliser ORL. Notre travail comme nous avons déjà expliqué est d implémenter le protocole COPS en utilisant des SERVICES WEB, pour implémenter le protocole COPS on a besoin d un PDP (Policy decision point) avec sa PIB (Policy Information Base) convenable et un PEP (Policy Enforcement Point) avec sa PIB. En effet le travail du protocole COPS comme on a déjà vu est de faire la gestion des politiques c.a.d. de pouvoir transporter des politiques ou bien des configurations de la PIB du PDP et les installer dans la PIB du PEP pour pouvoir le configurer. Pour cette raison on a programmé sur C#.NET (déjà expliqué), un PDP et un PEP et tous les messages COPS transférés entre ces deux, on a crée aussi la PIB de chacun d eux qui n est qu un fichier OWL, donc nous avons eu ce modèle : Policy 1 Policy 2.. Fichier OWL Policy 1 Policy 2.. Fichier OWL PIB P E P COPS P D P PIB 70

71 5-Quand et comment utiliser ORL? Maintenant ayant une idée générale de tout l environnement, la question qui doit être poser c est «où est ce qu on va utiliser ORL dans notre programme?» La réponse est simple, en effet nous avons vu que les messages de décision sont les messages COPS qui transportent les politiques du PDP au PEP pour configurer la PIB de ce dernier, on rappelle que ces messages peuvent être : 1- sollicités : le PEP envoie un request message au PDP demandant une configuration, ensuite le PDP répond par un decision message. 2- non sollicitées : le PDP envoie a n importe quel instant un decision message pour mettre à jour la configuration du PEP. En effet le ORL va être utiliser seulement avec les messages non sollicitées ex : Supposons que le manager veut installer la politique «P1» dans la PIB du PEP de l instant «T1» à l instant «T2» ensuite l enlever : c est ce qu on appelle une règle. Comment introduire cette règle dans l environnement? a- tout d abord cette règle va être traduite en ORL et stockée dans un fichier où d autres règles peuvent exister. Ce fichier va être vérifié fréquemment pour pouvoir exécuter les règles valides b- quand c est le temps T1,cette règle est validée (b), donc le PDP va être commandé (b1) de forcer le PEP d installer P1, en lui envoyant un message non sollicité, qui dans ce cas va contenir la commande «Install» et la propriété «P1»(b2), c- Lorsque le PEP va recevoir ce message il va installer la politique P1 de sa PIB. 71

72 d-quand c est le temps T2 cette règle est aussi validée (d), donc le PDP est commandé (d1) de forcer le PEP d enlever P1, en lui envoyant u message non sollicitée, qui dans ce cas va contenir la commande «Remove» et la propriété «P1»(d2), e- Lorsque le PEP va recevoir ce message il va enlever la politique «P1» de sa PIB. Maintenant comme nous savons où et quand utiliser ORL dans notre environnement, nous allons représenter les étapes de a e sur trois schémas pour clarifier l idée de plus en plus : Schéma 1 : translation de la règle en ORL T1-T2:install a Manager Rule 1 Rule 2 ORL 72

73 Schéma 2 : à T1 T1 PIB b P2 P1 P E P c b2 Unsolicited decision : Install P1 P D P b1 P1 P2 ORL Règle 1 Règle PIB Schéma 3:à T2 T2 PIB d P2 ORL P E P e d2 Unsolicited decision : Remove P1 P D P d1 P1 P2 Règle 1 Règle PIB 73

74 6-Programme: Après avoir tout compris concernant ORL, maintenant nous allons regarder notre programme et les modifications qu on a faites. 6.1-L interface: En effet nous avons crée une interface présenté dans le schéma 4 en dessous, cette interface permet au manager de démarrer le programme (gestion de politiques=protocole COPS) en cliquant sur le bouton «RUN». Le manager peut aussi crée une règle en choisissant une politique de la liste, et choisissant l intervalle de temps («From»=temps d installer de la politique «Till» =temps d enlever la politique) Ensuite en cliquant sur le bouton «translate» cette règle va être traduite en ORL et stocké dans un fichier (inetpub\wwroot\pdp\rules.owl). Plusieurs règles peuvent être crée et stocké dans ce fichier pour être exécuter chacune A son instant, en effet a l aide d un compteur on vérifie ces règles couramment (chaque une minute) pour exécuter les règles qui sont valides. NB : pour voir les messages rentrant au PEP, il suffit de cliquer sur le link «messages entrant au PEP» qui est dans l interface graphique Si une règle est valide : 1-cette règle est règle est exécutée =le PDP envoie un message non sollicitée au PDP pour enlever (installer) la politique concernée, dont Le nom est mentionné dans la règle. 2-Cette règle va être enlevé du fichier rules.owl, et stocké Dans un fichier historique (inetpub\wwroot\pdp\rules_history.owl) 74

75 Schéma 4: interface 6.2-Translation d une règle en ORL: Une règle contient : 1- le nom de la politique 2- temps d installer la politique (from) 3-temps d enlever la politique (till) Quand ces trois paramètres sont choisis sur l interface, et quand on clique le bouton «translate»cette règle va être traduite ne ORL en suivant la syntaxe suivante : <owlx:rule> <owlr:antecedent> <owlr:datavaluedpropertyatom owlr:property= equal > <owlr:variable owlr:name= pc_clock /> <owlx:datavalue rdf:datatype= &xsd;string> temps d installer </owlx:datavalue> </owlr:datavaluedpropertyatom> </owlr:antecedent> 75

76 <owlr:consequent> <owlr:datavaluedpropertyatom owlr:property= send > <owlr:variable owlr:name= nom de la politique /> <owlx:datavalue rdf:datatype= &xsd;boolean>true</owlx:datavalue> </owlr:datavaluedpropertyatom> </owlr:consequent> </owlx:rule> <owlx:rule> <owlr:antecedent> <owlr:datavaluedpropertyatom owlr:property= equal > <owlr:variable owlr:name= pc_clock /> <owlx:datavalue rdf:datatype= &xsd;string> temps </owlx:datavalue> </owlr:datavaluedpropertyatom> </owlr:antecedent> <owlr:consequent> <owlr:datavaluedpropertyatom owlr:property= remove > <owlr:variable owlr:name= nom de la politique /> <owlx:datavalue rdf:datatype= &xsd;boolean>true</owlx:datavalue> </owlr:datavaluedpropertyatom> </owlr:consequent> </owlx:rule> d enlever D après cette syntaxe on peut remarquer que chaque règle écrite en ORL est divisée en deux parties ou bien deux sous règles : Règle 1 : compare l heure du PC «pc-clock»au «temps d installer», si les Deux sont égales alors la politique «policy name» définie dans cette Règle va être installé dans la PIB du PEP en envoyant le message convenable non sollicité de la part du PDP au PEP Règle 2 : compare l heure du PC «pc-clock»au «temps d enlever», si les Deux sont égales alors la politique «policy name» définie dans cette Règle va être enlevé de la PIB du PEP en envoyant le message convenable non sollicité de la part du PDP au PEP 76

77 6.3-Comment vérifier le bon fonctionnement du programme? En effet lorsqu une règle est exécutée la PIB du PEP doit changer ex : Si on a une règle qui permet d installer la politique «P1» a 12heures et de l enlever à 3heures, donc lorsque c est 12 heures une partie de cette règle est vérifiée qui est l installation, donc si a ce temps j ouvre la PIB du PEP qui n est autre que le fichier «inetpub\wwwroot\pep\newpib.owl» on verra donc la présence de cette politique à la fin du fichier, si on vérifie ce fichier une deuxième fois à trois heures on devra remarquer que cette politique est enlevée. 77

78 Conclusion On résumera dans cette partie tout le travail qu on a préparé pour cette mémoire durant les six mois de travail permanent, pour avoir une idée générale du travail accompli. Comme le protocole COPS est le centre de notre projet on a entamé notre travail par une recherche approfondie de ce protocole et le rôle principal qu il joue dans la gestion des politiques, en effet le protocole COPS permet a une entité appelé PDP (Policy Decision Point) ayant un ensemble de politiques stockées dans la PIB (Policy Information Base) de configurer les PIB s d autres entités appelées PEP (Policy Enforcement Point). Ayant terminé cette étude nous avons commencée par le travail pratique qui a été divisé en trois parties ou programmes : 1-pour rendre la PIB sémantique on a décidé de l écrire en langage OWL pour cela on a eu recourt a un éditeur d ontologie qui est Protege, reste a pouvoir créer une PIB en suivant la structure SPPI définie dans les RFCs pour cette raison on a fait un programme JAVA qui a été utilisé comme plugin dans Protege (éditeur d ontologie) et qui fait tout ce travail. 2-nous avons simulé le protocole COPS avec des services web sur le C#.Net, nous avons sorti par un programme qui permet a l utilisateur d observer tous les messages protocolaires transmis entre un PEP et un PDP pour faire la gestion des politiques. 3-pour rendre le programme flexible on a décidé d introduire des règles qui contrôlent la gestion des politiques, mais comme OWL n a pas cette capacité, on a écrit ces règles en ORL (OWL Rules Language), et on les a introduit dans notre programme. A la fin on a eu un programme complet qui incarne la gestion de politique faite par le protocole COPS. 78

79 Perspectives Ce projet achevé n est autre qu un petit pas du long parcourt de la gestion des politiques et du protocole COPS, plusieurs autres pas peuvent être prévus suite a ce travail, en effet l implémentation du protocole COPS qu on a faite manque les messages d erreurs et les messages de fermeture de connexion, ceux-ci peuvent être réaliser pour être plus conforme à la définition de ce protocole et à la gestion des politiques, de même une autre modification peut être faite concernant les règles ORL, en effet dans notre travail on a pris l exemple d une règle (qui est celle de temps) et on a réaliser tout le travail en tant que translation.. Autour de cette règle pour démontrer que c est faisable, donc pour généraliser on pourra introduire d autres règles qui peuvent être utiles dans la gestion des politiques. Notre projet est ouvert à n importe quelle autre modification que vous désirez faire et qui le rend de plus en plus performant. 79

80 Références 1-COPS : -RFC Structure of Policy Provisioning Information (SPPI), -RFC The COPS (Common Open Policy Service) Protocol, -Framework Policy Information Base, -Differentiated Services Quality of Service Policy Information Base, -COPS Usage for Policy Provisioning (COPS-PR), -COPS, description and message format,cops, Common Open Policy -QoS, Security, and Mobility Management for Fixed and Wireless Networks under Policybased Techniques. Guy Pujolle and Hakima Chaouchi, 2-OWL & Editeurs d ontologie : -Requirements for a Web Ontology Language, W3C Working Draft 07 March 2002, -DOE-The Differential Ontology Editor, 80

81 -JOE-Java Ontology Editor,tutorial, -OilEd, -OilEd, -OWL examples in XML Syntax, -Web Ontology Language, -OWL Web Ontology Language Use Cases and Requirements, - Ontology Building: A Survey of Editing Tools, -OWL Web Ontology Language Parsing OWL in RDF/XML, -Web Ontology Language Guide, -OWL Web Ontology Language Test Cases, -OWL Web Ontology Language Xml Presentation Syntax, -Ontology editor survey results, 81

82 3-Protégé : -Protégé, -Protégé+OWL+Imports, -Protégé tutorial, 4-C#.Net : -Tutorials : C #.Net, Gerard Leblanc,edition Eyrolles. 5-ORL : -A proposal for an OWL Rules Language, Semantics and Abstract Syntax, 82

83 83