Construire une documentation structurée des dépendances des services
Comité Réseau des Universités
CRI Rennes 1– Bat 12D Campus de Beaulieu – Avenue du Général Leclerc - 35042 Rennes Cedex
Résumé
Par leur nombre, leur complexité et leurs multiples interactions, il n'est pas toujours aisé d'avoir une idée précise de l'ensemble des services opérés dans un système d'information (SI), notamment au sujet des ressources (applicatives, matérielles, réseaux...) sur lesquelles ils reposent. Bien qu'il existe des documentations, elles ne font pas toujours apparaître les relations de dépendance entre les services et les ressources. De plus quand ces documentations existent, le format utilisé ne permet pas toujours de les exploiter avec des applications tierces. Cette carence documentaire peut être handicapante, en cas de panne, en l'absence du responsable du service ou lorsqu'un nouveau collègue rejoint l'équipe.
Dans l'article, nous décrivons en quoi il est utile pour les administrateurs et les responsables de SI de disposer d'une documentation décrivant de façon structurée les services disponibles et les relations de dépendances sur lesquelles ils reposent (nous l'appellerons DSDS : Documentation Structurée des Dépendances et des Services). Ensuite, nous exposerons, en quoi la création d'une ontologie1, avec le logiciel Protégé [1], est adaptée pour construire cette DSDS : pour cela, nous illustrerons notre propos par la présentation du modèle qui a été utilisé pour développer la DSDS du CRU2. Ainsi par l'analyse de graphes, de requêtes ou du parcours de l'ontologie, nous montrerons comment la DSDS peut répondre à différentes questions : comment trouver les contraintes qui pèsent sur telle machine, mesurer l'impact provoqué par l'arrêt de telle application, identifier les services critiques à redonder, lister les applications qui doivent être supervisées...
Mots clefs
Documentation, dépendances des services, architecture, réseau, système d'information, description structurée, administration, supervision, ontologie, graphes, Protégé, logiciel libre, OWL
Une DSDS, se donne pour objectif d'offrir, une visibilité globale de l'ensemble des services disponibles sur un SI et de leur architecture, par la description des ressources et des dépendances sur lesquelles sont construits ces services. On pourra, avec la DSDS, représenter graphiquement les liens qui existent entre : les différents services proposés aux différentes populations d'utilisateurs, les différentes briques logicielles (systèmes, réseaux, intergiciels3) sur lesquelles s'appuient ces services (avec la localisation des fichiers de configuration, les procédures de démarrage, d'arrêt, le monitoring, les modules ajoutés...), les machines physiques qui hébergent ces applications, avec leurs dépendances sur l'électricité, la climatisation, ainsi que les différents administrateurs qui gèrent ces services.
La DSDS est utile pour connaître rapidement l'impact de l'indisponibilité d'une application sur l'ensemble des services qui tournent sur un réseau. Elle permet d'effectuer un premier diagnostic rapide en cas d'incident sur un service, afin d'identifier les conséquences potentielles sur d'autres services et, le cas échéant, prévenir toutes les personnes concernées.
La DSDS est un support de réflexion sur l'architecture des services opérés. Par exemple, dans le cas d'une étude sur l'amélioration de la disponibilité de certains services jugés critiques, elle permet de repérer les points de défaillances (logiciels ou matériels) qui devraient être redondés. Elle peut aussi permettre d'identifier les machines qui font tourner beaucoup d'applicatifs utilisés par différents services distincts et qu'il faut donc être capable de restaurer rapidement en cas de crash inopiné. On pourra s'appuyer sur la DSDS pour déplacer facilement un applicatif d'une machine sur une autre, en prenant aisément en compte toutes les interactions de cet applicatif avec l'ensemble du SI.
La DSDS permet de faciliter les migrations des machines, en offrant une documentation synthétique des éléments qui entrent en compte dans la configuration d'un service (applicatifs, intergiciels, modules...). Elle peut permettre aussi de faciliter la construction d'un serveur sur une nouvelle machine, en fournissant une fiche système des logiciels à installer.
La DSDS permet d'identifier rapidement tous les utilisateurs concernés par une opération de maintenance, et permet, le cas échéant, de générer un courriel ciblé aux utilisateurs concernés.
La DSDS aidera le responsable du SI dans la gestion de l'équipe en connaissant, par exemple, tous les services impactés par le départ d'un administrateur. Réciproquement, l'intégration d'un nouveau collègue pourra être facilitée, en lui fournissant une représentation graphique de l'architecture du SI, ainsi qu'un moteur de recherche lui permettant de naviguer parmi les concepts décrits dans cette base de connaissances.
Il faut donc disposer d'un outil capable de stocker, de représenter
et d'automatiser le traitement de ces connaissances.
L'organisation
des données doit être structurée afin de
permettre leur exploitation de façon automatique. La DSDS
permettra d'effectuer différents post-traitements :
publication des données pour consultation ou manipulation,
création de graphes, recherche de vulnérabilités,
de points individuels de défaillance4,
de procédures d'installation... Il est donc fortement
souhaitable, d'être en mesure de dissocier les données
de leur présentation.
Une attention particulière doit donc être accordée à la production de cette DSDS. Il est important que cet outil soit facile à maintenir : les données produites doivent pouvoir être mises à jour et modifiables rapidement. Nous privilégierons, donc, une interface simple et intuitive afin que chaque administrateur puisse mettre à jour facilement la DSDS, et qu'ainsi elle reflète au mieux la réalité. On pourrait, toutefois, envisager l'automatisation de la mise à jour de ces données, mais il n'est pas garanti que l'on gagne effectivement du temps (le développement devant inclure la gestion de toutes les applications et de leurs implémentations sur toutes les plateformes...). De plus, tous les équipements (climatisation, onduleurs) n'étant pas en mesure de remonter ce type d'information, il faudra de toute façon gérer manuellement certaines mises à jour.
En 1994, Pierre Fernique publiait une thèse de doctorat concernant le problème des dépendances applicatives dans un réseau [2]. Ainsi, pour manipuler les dépendances fonctionnelles, il a utilisé un modèle de données. Cependant, en dehors du prototype ADSAR, développé pour démontrer la faisabilité d'un tel outil d'administration, nous ne connaissons aucune autre implémentation logicielle du modèle proposé.
Par ailleurs, dans le cadre d'une stratégie ITIL5, il existe de nombreuses solutions orientées CMDB6 qui fournissent un modèle structuré pour gérer les catégories de CI7 et les différentes relations entre ces CI.
Voyons maintenant comment Protégé va nous permettre de développer une ontologie, pour peupler et mettre à jour la DSDS de notre SI.
Voici une présentation rapide de ce qu'est une ontologie, le lecteur intéressé trouvera des références à la fin de l'article pour approfondir le sujet.
« Une spécification d'un vocabulaire de représentation pour un domaine partagé du discours – des définitions de classes, des relations et d'autres objets – est appelée une ontologie ». [3]
Une ontologie en informatique est un ensemble structuré de
savoirs dans un domaine de connaissance particulier. [4]. On parle
aussi de bases de connaissances.
L'organisation structurée
de ces savoirs permettra une exploitation automatisée des
données qui la compose.
« Pour l'objectif de ce guide une ontologie est une description formelle et explicite des concepts dans un domaine du discours (des classes (parfois appelées concepts)), des propriétés de chaque concept décrivant diverses caractéristiques et attributs du concept (slot (parfois appelés rôles ou propriétés)), et des restrictions sur les slots (facettes (parfois appelées restrictions de rôle)). Une ontologie associée à un ensemble d'instances individuelles des classes constitue une base de connaissances ». [5]
Développer une ontologie des services et des dépendances
nécessitera de décrire des classes (Service,
Application, Serveur, Routeur, Administrateur...), des propriétés
attachées à ces classes, qui permettront de définir
des liens entre les classes (DependFortementDeLApplication,
EstInstalleSur, UtiliseFaiblementLeService...) et de
caractériser ces propriétés (cardinalité,
transitivité...).
L'ontologie ajoutée aux
différentes instanciations des classes constituera la base de
connaissances des services et des dépendances de notre SI.
Dès lors nous pourrons procéder à différents
post-traitements sur ces données (affichage, requêtes,
classifications, graphes...).
En outre, la création d'une ontologie et la publication libre des classes et attributs constitutifs de l'ontologie permettra sa réutilisation, par la communauté. Chacun pourra ensuite décliner les instances de ses classes propres en fonction de son contexte. De nouvelles classes et propriétés pourront être intégrées au modèle générique et publiées librement.
Protégé est conçu pour éditer des ontologies et un cadriciel8 de base de connaissances. Il permet d'utiliser OWL9, qui est le langage informatique utilisé pour modéliser des ontologies. OWL est conçu comme une extension de RDF10, et est destiné à la description de classes et de types de propriétés.
Protégé permet un fonctionnement en mode client/serveur (avec gestion des accès concurrents) et propose de nombreux formats d'exportation (HTML, XML, OWL, RDFS11...). Il intègre de nombreux greffons facilitant le post-traitement des données (ex: ontoviz pour la génération de graphes au format .dot [6], ou queries moteur de recherche permettant de construire facilement des requêtes, et de sauvegarder les plus pertinentes). Chacun pourra contribuer au projet en construisant un nouveau greffon12 pour l'intégrer au cadriciel.
Protégé offre une API13 Java, qui est optimisée pour l'implémentation d'interfaces utilisateurs graphiques. Elle fournit des classes et des méthodes pour manipuler des fichiers OWL, requêter des modèles de données OWL... Chacun pourra donc construire une servlet java qui permettra d'exploiter les données.
La plateforme Protégé offre 3 approches pour développer une ontologie :
l'éditeur Protégé-OWL permet de construire des ontologies pour le web sémantique14,
l'éditeur Protégé-Frames permet de construire et peupler des ontologies basées sur les cadres15,
l'équipe de développement de Protégé, travaille également sur l'édition d'ontologies à travers une interface web (WebProtégé 0.5 est encore en version Alpha)16.
Pour notre DSDS, nous avons choisi de construire une ontologie à partir de Protégé-Frames. Nous pourrons cependant exporter notre ontologie au format OWL en cas de besoin.
Protégé est un
logiciel libre développé,
depuis 10 ans, par l'école de médecine de
l'Université de Stanford [1], qui compte plus de 126000
utilisateurs enregistrés.
Basé sur les technologies
Java, il fonctionne sur tous les systèmes : nous avons
utilisé la version 3.4.117
sortie en juin 2009, dans un environnement Linux. Le projet Protégé
est vivant et évolue beaucoup : la version 4.0.118,
qui supporte maintenant OWL 2 [9], a été stabilisée
en août 2009 puis patchée fin octobre 2009.
Protégé nous est apparu très ergonomique. Son interface « WYSIWYG19 », est intuitive et simplifie énormément la saisie. La création d'une classe crée automatiquement le formulaire adéquat. La mise en forme des formulaires se fait par simples glisser/déposer. Toute modification d'une classe (renommage, déplacement dans l'arborescence...) est répercutée dans toute l'ontologie, et prise en compte automatiquement par tous les objets existants.
Dans cette partie nous décrirons les différentes étapes que nous avons suivies pour construire notre ontologie des services et des dépendances au CRU.
La construction et le peuplement de l'ontologie est un travail itératif. La mise en place doit être consensuelle entre les utilisateurs car la DSDS a vocation à être maintenue par toute l'équipe sur une longue durée. Chacun sera amené à renseigner la partie de l'ontologie dont il a la responsabilité. Le modèle doit donc être accepté par tous. Toutefois, la souplesse de Protégé permet une mise à jour automatique du modèle dès l'ajout ou la modification d'informations (classes, propriétés, instances) : en effet, dès que l'on déplace un objet, il hérite automatiquement des nouvelles propriétés parentes.
Tout d'abord, il s'agit de recenser de façon exhaustive l'ensemble des services opérés par le SI. Le terme de « service » désigne ici un bien immatériel fourni à des utilisateurs : par exemple le service Universalistes [10] opéré par le CRU fournit des listes de diffusion et des serveurs de listes de diffusion à la communauté Recherche Enseignement Supérieur.
Chaque service pourra, par la suite, être défini par : les applications et/ou intergiciels qu'il faut mettre en œuvre pour rendre le service, les populations d'utilisateurs concernées par le service, les administrateurs du service...
Pour notre exemple, nous décrirons le service de listes de diffusion Universalistes [10] que l'on a décomposé en 5 objectifs fonctionnels différents (Réception, Diffusion, Intranet, Archives, Accès Web) (voir figure 1).
Figure 1 - Le graphe du service Universalistes décomposé en 5 objectifs fonctionnels
Nous nous attacherons également à décrire toutes les ressources sur lesquelles s'appuient les services. Elles peuvent prendre plusieurs formes : machines physiques (serveurs, commutateurs, réseau électrique), applications, intergiciels...
Dans notre ontologie, une application représente un processus ou un ensemble de processus, qui forment une unité logique indépendante. On retrouvera dans les applications : des logiciels, des packages Linux, des développements maisons, des intergiciels ou des protocoles (SMTP-IN...).
Les applications seront décrites en 2 étapes. En
premier lieu, nous avons créé une classe abstraite
Application, il s'agit d'un niveau de description général
intégrant une notion d'héritage. Une classe abstraite
ne pourra pas être instanciée, mais devra comporter
d'autres classes (une classe par application).
Toute instance
hérite des propriétés de la classe qui
l'instancie, elle-même héritant des propriétés
de la classe supérieure.
Figure 2 - Un extrait du graphe de l'instance apache_listes
Pour notre exemple la classe Application contiendra la sous-classe Apache qui contiendra l'instance apache_listes (instance d'apache tournant sur la machine listes). Apache_listes héritera donc des propriétés spécifiques de Apache (description des virtualhosts, des modules nécessaires) ainsi que des propriétés générales de toutes les Applications (nom de la machine qui l'héberge, nom des administrateurs, mode de monitoring, dépendances applicatives...) (voir Figure 2).Décrire les relations de dépendances
La définition des relations de dépendances se fait
dans l'onglet Slots de l'éditeur Protégé.
Ces Slots (voir
figure 3) sont des propriétés attachées aux
classes. Ces propriétés sont typées (chaîne,
booléen...) mais on peut également leur attribuer une
valeur de type Instance
(un objet que l'on aura instancié). Elles s'appliquent
seulement aux classes que l'on aura explicitement définies
dans la directive Domain.
On peut cependant leur fixer des valeurs par défaut, ou
appliquer un patron20
aux instances des classes déjà existantes. Il est
conseillé de régler la cardinalité (propriété
obligatoire ou non, unique ou non...), pour faciliter la saisie et
éviter certaines erreurs.
Figure 3 - Utilisation des Slots dans Protégé pour construire les relations de dépendances
Les relations de dépendances permettront d'établir des liens entre les services proposés et les utilisateurs ou administrateurs de ces services, mais aussi entre les applications fournissant les services et les machines hébergeant ces applications. D'autres relations de dépendances lieront les applications entre-elles.
Nous avons choisi
de faire apparaître différents niveaux de dépendances,
afin de distinguer les contraintes fortes, nécessitant un
niveau de disponibilité plus élevé, des
contraintes requérant une plus faible disponibilité.
Pour
notre cas, nous avons donc créé ces 2 Slots
afin de décrire les dépendances entre les applications
et les services :
_NecessiteFortementLApplication :
indique que cette application est indispensable pour faire
fonctionner le service
correctement,
_NecessiteFaiblementLApplication : indique
que l'indisponibilité, ou pour le moins l'indisponibilité
temporaire, de cette application, n'empêche pas le service de
fonctionner. Cette propriété de classe, sera aussi
utilisée pour indiquer qu'un service peut fonctionner en mode
dégradé.
Les relations de dépendances seront les arcs qui permettront de relier les différents nœuds de notre ontologie lors de la construction des graphes (voir figure 4).
Figure 4 - Visualisation des relations de dépendances par les graphes
Une fois le travail de peuplement de l'ontologie effectué - notons au passage que, comme pour toute documentation, cette tâche n'est jamais terminée et nécessite une constante mise à jour - nous allons pouvoir utiliser notre ontologie pour tenter de répondre à certaines problématiques de notre SI. C'est ce qui va guider la construction de notre ontologie, pour modéliser notre SI : on doit garder à l'esprit l'objectif que l'on souhaite atteindre et savoir où l'on s'arrête dans la description des objets que l'on va créer.
Protégé-Frames est livré avec de nombreux greffons intégrés, qui permettront d'exploiter rapidement les données. Certains greffons sont limités et, en attendant de nouvelles contributions au projet Protégé, nécessiteront parfois une manipulation en dehors de l'outil.
Le parcours de l'ontologie avec l'outil Protégé
est très intuitif, il permet de passer aisément d'une
instance à une autre instance, par double-clic. De plus, le
greffon Forms, livré
avec Protégé
permet d'organiser très facilement les différents
formulaires de saisies de nos instances. Nous rappelons que chaque
formulaire correspond à une propriété de
classe, définie dans l'onglet Slots
de Protégé.
Nous
pourrons dès lors créer un modèle de mise en
forme pour une classe, que l'on pourra appliquer à toutes les
classes.
La navigation dans les instances de Protégé, permettra de trouver facilement les contraintes (liées à ses dépendances) qui pèsent sur l'application apache_listes. On trouvera notamment, quelles sont les applications ou les services qui l'utilisent fortement...
Nous utiliserons le greffon Queries de Protégé, qui permet l'utilisation d'outils WYSIWYG pour faciliter l'écriture et la sauvegarde des requêtes.
Par exemple : pour rechercher la liste des applications qui ne sont pas sous surveillance (dans notre cas la propriété EstMonitorePar sera renseignée avec la valeur Rien), nous utiliserons la requête de la figure 5.
|
(name "SearchTab_Query")
|
Figure 5 - Code généré par Protégé lors de la création de la requête
La construction de requêtes élaborées nécessite de créer des sous-requêtes, pour utiliser les résultats intermédiaires. Ainsi pour connaître les utilisateurs impactés par l'arrêt de mysqld sur la machine listes, nous construirons les 5 requêtes suivantes :
Chercher l'application appelée mysql installée sur serveur_listes, (pour réutiliser cette requête à d'autres fins on pourra modifier les variables application et serveur).
Lister les applications qui en dépendent (résultat requête n°1).
Lister les sous-services (objectifs fonctionnels) qui les utilisent (résultat requête n°2).
Lister les services qui s'appuient dessus (résultat requête n°3).
Lister les utilisateurs qui sont impactés par ces services (résultat requête n°4).
Une autre façon d'exploiter les données est la création de graphes. Le graphe sera apprécié pour offrir une vision schématique de l'architecture étudiée, et ainsi favoriser la réflexion, sur les différents éléments du graphe.
Protégé intègre le greffon ontoviz (qui s'appuie sur le logiciel graphviz) permettant de créer des graphes au format .dot. (voir les figures 1, 2, 4 et 6). Toutefois ce greffon est assez limité, il n'exploite pas toute la richesse du langage DOT. La manipulation des fichiers .dot devra être effectuée en dehors de Protégé (à la main ou à l'aide de scripts PERL) pour réorganiser les nœuds du graphe, mettre de la couleur, afficher des liens de dépendances en pointillé s'ils ne sont pas critiques, modifier la forme des nœuds selon leur type. Nous avons, par exemple, choisi de créer des sous-graphes pour toutes les applications installées sur un même serveur.
À la lecture du graphe de la figure 6, on constate que les 5
objectifs fonctionnels du service Universalistes sont dépendants
de l'application mysql. C'est donc un élément à
monitorer scrupuleusement.
Avec un objectif de rationalisation
des services, si en étudiant toute la DSDS, on constate
différentes instances de mysql sur différents
serveurs, on peut imaginer de déplacer mysql de la
machine listes, vers un autre serveur dédié aux
bases de données. On pourrait alors redonder ce service et
augmenter la disponibilité de tous les mysql du SI,
ainsi mutualisés.
La lecture du graphique nous renseigne
aussi sur le fait que dokuwiki n'est pas lié à
la diffusion des messages. On peut donc mettre à jour
l'application sans arrêter l'envoi des messages. La modération
serait néanmoins amputée.
Pour finir, on peut
visualiser toutes les briques (sympa.pl, mysql,
bulk.pl, sendmail, résolveur dns,
serveur dns, SMTP-IN et SMTP-OUT) dont il va
falloir envisager la redondance, si l'on veut améliorer la
disponibilité de la diffusion et de la réception du
service Universalistes.
Notons que le moteur de wikis dokuwiki, permet d'intégrer facilement des graphes au format DOT, en installant le greffon graphviz21.
Il faut faire attention à la lecture du graphe ci-dessous : il ne représente pas les flux. Ainsi l'application sendmail est dépendante de 2 serveurs SMTP : 1 en entrée et 1 en sortie, c'est pourquoi l'orientation des flèches part de sendmail vers SMTP-IN alors que le flux de messagerie est à lire dans l'autre sens.
Figure 6 - Graphe simplifié du service Universalistes généré dans Protégé avec le plugin ontoviz
Documenter un SI n'est pas une chose aisée. Même quand la documentation existe, il n'est pas toujours facile de retrouver une information existante de façon intuitive ou logique. La représentation du SI par une ontologie, permet de naviguer facilement entre les objets qui composent notre SI, voire d'insérer des URLs pour renvoyer l'utilisateur vers les autres documentations existantes (wiki ou autres), pour approfondir le sujet. Toutefois la documentation n'est pas le seul objectif visé par la DSDS, sinon elle n'aurait qu'une portée limitée. Il s'agit de disposer d'une véritable cartographie du SI, de décrire le SI par ses relations de dépendances, afin notamment de favoriser les échanges autour de l'architecture des services, d'identifier les applications sur lesquelles s'appuient les services jugés critiques.
Le fonctionnement de Protégé semble très adapté à un SI qui, par définition, est en constante évolution. L'outil permet à l'utilisateur de créer son propre modèle de représentation du SI tel qu'il l'entend, sans avoir à se plier à un logiciel fermé dont la conception oriente l'approche que l'on a du SI.
La DSDS, que nous avons présentée, peut être étendue à d'autres objets de notre SI. À notre avis, tout le SI peut-être modélisé, il faut cependant garder notre problématique à l'esprit (comme augmenter la disponibilité de certains services par exemple). Néanmoins, on peut par exemple représenter les fonctions et modules d'un seul programme complexe développé par le SI, ou cartographier l'infrastructure réseau du site.
Stanford Center for Biomedical Informatics Research, http://protege.stanford.edu
Pierre Fernique, Un Modèle pour l'Administration des Dépendances entre Services Applicatifs des Réseaux Informatiques Hétérogènes, Thèse de Doctorat de l'Université Louis Pasteur , Strasbourg, 1994
Thomas R. Gruber, A Translation Approach to Portable Ontology Specifications. Knowledge Acquisition, 5(2) : 199-220, April 1993.
Xavier Lacot, Introduction à OWL, un langage XML d'ontologies Web, École Nationale Supérieure des Télécommunications, Paris, Juin 2005
Natalya F. Noy and Deborah L. McGuinness, Ontology Development 101 : A Guide to Creating Your First Ontology. Stanford Knowledge Systems Laboratory Technical Report KSL-01-05 and Stanford Medical Informatics Technical Report SMI-2001-0880, March 2001.
Emden Gansner and Eleftherios Koutsofios and Stephen North, Drawing graphs with dot, January 26, 2006, http://www.graphviz.org/pdf/dotguide.pdf
Deborah L. McGuinness, Knowledge Systems Laboratory, Stanford University, Franck van Harmelen, Vrije Universiteit, Amsterdam, W3C Recommandation 10 February 2004, http://www.w3.org/TR/owl-features/
W3C, Semantic Web Activity, http://www.w3.org/2001/sw/, 2 November 2001
W3C, OWL 2 Web Ontology Language, http://www.w3.org/TR/owl-overview/, 27 October 2009
Comité Réseau des Universités, Serveur de listes de diffusion du CRU, https://listes.cru.fr
Axel Reymonet, Jérôme Thomas, Nathalie Aussenac-Gilles, Modélisation de Ressources Termino-Ontologiques en OWL. Dans les actes de la conférence Journées Francophones d'Ingénierie des Connaissances, pages 179-190, Grenoble juillet 2007
Jean Charlet, l’Ingénierie des Connaissances : développements, résultats et perspectives pour la gestion des connaissances médicales. Mémoire d’habilitation à diriger des recherches en Informatique de l’université de Pierre et Marie Curie, Décembre 2002
1 ontologie : ensemble structuré des termes et concepts représentant le sens d'un champ d'informations. L'ontologie constitue en soi un modèle de données représentatif d'un ensemble de concepts dans un domaine ainsi que les relations entre ces concepts.
2 CRU : Comité Réseau des Universités
3 Intergiciel (middleware en anglais) : logiciel servant d'intermédiaire de communication entre plusieurs applications, généralement complexes ou distribuées sur un réseau informatique
4 SPOF : Single Point Of Failure
5 Information Technology Infrastructure Library : c'est un ensemble d'ouvrages recensant les bonnes pratiques, édictées par l'office public britannique du commerce, pour la gestion des services informatiques
6 Configuration Management DataBase : donne une vue complète des composants de l’infrastructure informatique et des services qu'ils rendent
7 Configuration Item : tout composant qui doit être administré dans le but de fournir un service informatique
8 cadriciel (framework en anglais) : ensemble de bibliothèques, d'outils et de conventions permettant le développement d'applications.
9 OWL : Web Ontology Language. OWL, standard du W3C depuis 2004, est un dialecte XML d'échange et de représentation des données. [7]
10 RDF : Ressource Description Framework. Il s'agit d'un modèle de graphe destiné à décrire de façon formelle les ressources web et leurs métadonnées, de façon à permettre le traitement automatique de telles descriptions.
11 RDFS (RDF Schéma) publié en 2004 par le W3C pour structurer des ressources RDF ou fournir des éléments de base à la création d'ontologies
12 http://protege.stanford.edu/download/plugins.html
13 API : Interface de Programmation Applicative
14 Web sémantique : Ensemble de technologies visant à rendre le contenu du web accessible et utilisable par les programmes et agents logiciels grâce à un système de métadonnées formelles. [8]
15 Cadre (frame en anglais)
16 http://protegewiki.stanford.edu/index.php/WebProtege
17 http://protege.stanford.edu/download/download.html
18 http://protegewiki.stanford.edu/index.php/Protege4Features
19 WYSIWYG : What You See Is What You Get (ce que vous voyez est ce que vous obtenez)
20 template
21 http://www.dokuwiki.org/plugin:graphviz