UNIVERSITE LIBANAISE UNIVERSITE SAINT

Transcription

UNIVERSITE LIBANAISE
UNIVERSITE SAINT-JOSEPH
(Faculté de Génie)
(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é
Mohamad Zoaeter
Wajdi Najem
Imad Mougharbel
Nicolas Rouhana
Mahmoud Doughan
Maroun Chamoun
Président
Membre
Membre
Membre
Membre
Membre
Membre
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
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
On peut définir l’architecture globale de la politique sous COPS en reprenant ces cinq éléments :
Editeur de politique
Répertoire de politiques
Edition
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
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
PARTIE I
6
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
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
P
E
P
Network Manager
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
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
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
COPS-SLS
PDP
PEP
COPS-SLS
PEP
Policy
Repository
10
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
•
•
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
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
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
-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
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
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
3-Les messages de COPS-PR entre PEP et PDP :
Client Open
Client Accept
Request
Decision
PIB
PIB
Usollicited Decision
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
<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
-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.
<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’.
<Report-State> : : = <CommonHeader> <Client Handle> <Report-Type>
-Client-Close : Ce message est utilise pour la fermeture de la connexion.
20
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
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
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
:
On ne peut plus installer d’instances
dans cette classe.
-attrValueInvalid
:
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.
la longueur de la valeur de cet attribut
dépasse la limite.
-attrMaxLengthExceeded:
…
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
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
PRC 1
Attribut 1
Attribut 2
Attribut 1
Attribut 2
Attribut 3
PRI 1
PRI 2
PRC 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
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.
2.2- 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
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
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
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.
OBJECT-IDENTITY MACRO ::=
TYPE NOTATION ::=
"STATUS" Status
"DESCRIPTION" Text
ReferPart
VALUE NOTATION ::=
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.
OBJECT-TYPE MACRO ::=
TYPE NOTATION ::=
"SYNTAX" Syntax
UnitsPart
29
"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
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
OBJECT-GROUP MACRO ::=
TYPE NOTATION ::=
ObjectsPart
"STATUS" Status
"DESCRIPTION" Text
ReferPart
VALUE NOTATION ::=
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.
MODULE-COMPLIANCE MACRO ::=
TYPE NOTATION ::=
"STATUS" Status
"DESCRIPTION" Text
ReferPart
ModulePart
VALUE NOTATION ::=
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
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.
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
PARTIE II
34
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 2001
35
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
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
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/234567 </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/234567 </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
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
Exemple :
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:ws="http://xmlns.com/0.1/websem/" >
<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
<rdfs :Class rdf :about=“http://…Tintin”/>
<rdfs :subClassOf rdf :Resource=“http://…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=“http://…a-pour-auteur”/>
<rdfs:range rdf:resource=“http://…#Auteur”/>
<rdfs:domain rdf:resource=“http://…#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) :
2.4.1-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
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
2.4.2-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
•
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 = “http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#”
xmlns :vin=“http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#”
xmlns :owl = “ http://www.w3.org/2002/07/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é
( http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine# ).
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
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”>
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”>
…
•
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
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" />

FunctionalProperty : utilisé pour préciser que la propriété ne peut
avoir que zéro ou une valeur pour un “individual”.
45

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
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
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
Tool
Modeling Features/Limitations
The software The representational and
tool for edit- logical qualities that can be
ing ontologies expressed in the built ontology
Apollo
Contextia
COPORUM
OntoBuilder
Differential
Ontology
Editor (DOE)
Domain Ontology Management Environment
(DOME)
Base Language
Web SupImport/Export
port & {Use}
Formats
The native
or primary
language
used
to
encode the
ontology
Support for
Webcompliant
ontologies
(e.g., URIs),
and {use of
the software
over the Web
(e.g., browser
client)}
Other
languages the built
ontology can
be serialized in
No,
but
{server
is
planned}.
Referenced
ontologies
(URLs);
URIs
CLOS; OCML
Classes with slots plus OKBC
relations; functions; hier- model
archical views.
Basic concepts and rela- Express
tions with datatypes are
represented in schemas.
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.
RDFS
Graph
View
Consistency
Checks
The extent
to which the
built ontology can be
created,
debugged,
edited
and/or compared
directly
in
graphic
form
No,
but
planned.
The degree to
which the syntactic, referential
and/or
logical correctness of the
ontology can
be
verified
automatically
Entity relation For editing
diagrams;
single onXML Schema
tology (using
FirstStep XG).
{Web based DAML+OIL;
Browsing of
repository;
RDF(S)
ontology.
Web services
in development}
Express model
(ISO
10303)
validation;
cross-ontology
consistencies
RDF
consistency via repository.
Yes
XML
& Load ontolo- DAML+OIL;
CGXML
gy by URL
RDFS
No, but tree Arity and type
view.
inheritance on
relation
domains; detects
cycles in hierarchies.
CLASSIC
& FaCT
ER
grams
{Web
cess}
ac- OKBC; XML
dia- Yes
49
Tool
Enterprise
Semantic
Platform
(ESP) including Knowledge Toolkit
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.
Distinguishes
between
properties and relations;
allows contexts; default
reasoning; temporal model
relations; higher-arity relations; meta-properties and
meta-relations.
Base Language
port & {Use}
Formats
The native
or primary
language
used
to
encode the
ontology
Support for
Webcompliant
ontologies
(e.g., URIs),
and {use of
the software
over the Web
(e.g., browser
client)}
Graph
XML
The extent
to which the
created,
debugged,
edited
and/or compared
directly
in
graphic
form
& URIs; {par- XML; (RDF(S) Connected
tial HTML is planned)
tree browsclient; HTTP
ing
via
API}
TouchGraph
OWL
{Web client (based on control paKIF;
not nel}
related to
W3C WebOnt language
of
same
name.)
Basic concept and rela- KIF
No
JOE
tions modeling ala ER
,support attributes, queries,
constraints, searching for a
specific node (ER) in the
onyology
{Browsing
KAON (in- Extends RDFS with sym- KAON
cluding OI- metric, transitive and in- (proprietary ontologies
verse relations, relation extension
via KAON
Modeller)
cardinality,
meta- of RDFS)
Portal; Web
modeling, etc. Similar to
services API
F-Logic using axiom patunder develterns. Editor currently
opment}
only supports concept
hierarchy.
Integrated
Ontology
Development
Environment
Graph
View
Other
languages the built
ontology can
be serialized in
KIF;
RDB;
DTD
UML; UML
XML grams
Consistency
Checks
The degree to
and/or
ontology can
be
verified
automatically
Yes, includes
automatic and
user interactive
checks;
dynamic content
management.
dia- Top-level ontology consistency
per
Guarino
&
Welty.
ER (LDL++)
No
No
RDFS
No
Yes, for evolution of ontology.
50
Tool
Base Language
port & {Use}
Formats
The native
or primary
language
used
to
encode the
ontology
Support for
Webcompliant
ontologies
(e.g., URIs),
and {use of
the software
over the Web
(e.g., browser
client)}
Other
languages the built
ontology can
be serialized in
The degree to
and/or
ontology can
be
verified
automatically
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,
Ontology
Builder
& datatypes and cardinality
constraints; node docuServer
mentation; inclusion. No
axioms.
Protégé-2000 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.
F-Logic
Resource
URIs
RDFS;
Logic;
DAML+OIL
(limited); RDB
Yes, via OntoBroker
Partial
OKBC
model
Fully qualified names;
{HTTP
browser and
server}
Limited
namespaces;
{can run as
applet; access
through servlets}
RDFS
& No
DAML+OIL
(future)
Limited to term
validity
and
graph cycles.
RDF(S); XML
Schema; RDB
schema
via
Data
Genie
plug-in;
(DAML+OIL
backend
due
4Q'02
from
SRI)
Plug-ins
for
adding
&
checking constraint axioms:
PAL; FaCT.
OntoEdit
OKBC
model
Graph
View
The extent
to which the
created,
debugged,
edited
and/or compared
directly
in
graphic
form
F- Yes,
via
plug-in
Browsing
classes &
global properties
via
GraphViz
plug-in;
nested
graph views
with editing
via Jambalaya plug-in.
Consistency
Checks
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
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
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
On illustre ceci par le schéma ci-dessous :
PIB
Module-Identity
Module n
PibMetaClassss
OT-Table
Groupe 1
Table 1
OT-Entry
OT-Attributes
Module 1
Groupe n
Table 1
Table n
Entry 1
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
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
Classe mère
Type :Metaclasse 1
-propriété 1
-champs 1
-champs 2
-propriété 1
Sous Classe
Type : Classe
-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 desModuleIdentity .
sous des noms des Widgets), sa métaclasse est :
57
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
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
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
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
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 7.1.3088.
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
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
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
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
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="http://www.w3.org/2001/XMLSchema#string"
>la valeur </VALUE>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>je l'ai cree mis meme</rdfs:comment>
</qosBaseIfCapsEntry>
</rdf:RDF>

OWL
Plugin
1.1
beta,
Build
110)
66
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
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 DifferentFrom(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
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:antecedent>
<owlr:consequent>
<owlr:individualPropertyAtom owlr:property=“uncle”>
<owlr:Variable owlr:name= “a”/>
<owlr:Variable owlr:name= “c”/>
69
</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
…..
Policy 1
Policy 2
…..
Fichier OWL
Fichier OWL
PIB
P
E
P
COPS
P
D
P
PIB
70
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
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
Manager
a
Rule 1
Rule 2
ORL
72
Schéma 2 : à T1
T1
b
PIB
P2
P1
ORL
c
Règle
1
Règle
b1
b2
P
E
P
P
D
P
Unsolicited decision :
Install P1
P1
P2
PIB
Schéma 3:à T2
T2
d
PIB
P2
ORL
e
Règle
1
Règle
d1
P
E
P
d2
Unsolicited decision :
Remove P1
P
D
P
P1
P2
PIB
73
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
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
<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: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: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: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
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
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
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
Références
1-COPS :
-RFC 3159 - Structure of
http://www.faqs.org/rfcs/rfc2748.html
Policy
-RFC 2748 - The COPS (Common
http://www.faqs.org/ftp/rfc/rfc3159.txt
Provisioning
Open
Policy
Information
Service)
(SPPI),
Protocol,
-Framework Policy Information Base,
http://www.armware.dk/RFC/rfc/rfc3318.html
-Differentiated Services Quality of Service Policy Information Base,
-COPS Usage for Policy Provisioning (COPS-PR),
-COPS, description and message format,COPS, Common
http://www.networksorcery.com/enp/protocol/cops.htm#Description
Open
Policy
-QoS, Security, and Mobility Management for Fixed and Wireless Networks under Policybased Techniques. Guy Pujolle and Hakima Chaouchi ,
http://www.ifip.tu-graz.ac.at/TC6/events/WCC/WCC2002/papers/Chaouchi.pdf
2-OWL & Editeurs d’ontologie :
-Requirements for a Web Ontology Language, W3C Working Draft 07 March 2002,
http://www.w3.org/TR/2002/WD-webont-req-20020307/
-DOE-The Differential Ontology Editor,
http://opales.ina.fr/public/
80
-JOE-Java Ontology Editor,tutorial,
http://www.cse.sc.edu/research/cit/demos/java/joe/
-OilEd,
http://citeseer.ist.psu.edu/update/452035
-OilEd,
http://oiled.man.ac.uk/
-OWL examples in XML Syntax,
http://www.w3.org/TR/owl-xmlsyntax/apd-example.html
-Web Ontology Language,
http://www.w3.org/TR/2004/REC-owl-features-20040210/
-OWL Web Ontology Language Use Cases and Requirements,
http://www.w3.org/TR/webont-req/
- Ontology Building: A Survey of Editing Tools,
http://www.xml.com/pub/a/2002/11/06/ontologies.html
-OWL Web Ontology Language Parsing OWL in RDF/XML,
http://www.w3.org/TR/2004/NOTE-owl-parsing-20040121/
-Web Ontology Language Guide,
http://www.w3.org/TR/2004/REC-owl-guide-20040210/
-OWL Web Ontology Language Test Cases,
http://www.w3.org/TR/2004/REC-owl-test-20040210/
-OWL Web Ontology Language Xml Presentation Syntax,
http://www.w3.org/TR/2003/NOTE-owl-xmlsyntax-20030611/
-Ontology editor survey results,
http://www.xml.com/2002/11/06/Ontology_Editor_Survey.html
81
3-Protégé :
-Protégé,
http://protege.stanford.edu/
-Protégé+OWL+Imports,
http://erizo.ucdavis.edu/~dmk/notes/Protege+OWL+Imports.html
-Protégé tutorial,
http://www.co-ode.org/resources/tutorials/ProtegeOWLTutorial.pdf
4-C#.Net :
-Tutorials :
http://www.csharphelp.com/archives2/archive402.html?printable=yes
http://www.hitmill.com/programming/dotNET/csharp.html
http://www.csharpcorner.com/Tutorials/CSTutorial1AN.asp#All%20About%20Microsoft.%20NET
http://www.codeguru.com/
http://www.abstractvb.com/code.asp?A=1006
-C #.Net , Gerard Leblanc ,edition Eyrolles.
5-ORL :
-A proposal for an OWL Rules Language, Semantics and Abstract Syntax,
http://www.cs.man.ac.uk/~horrocks/DAML/Rules/WD-OWL-rules-20031004/
82
83