Soutenance mémoire
Introduction générale
Dans les standards du web, une ressource est toute entité pouvant être identifiée par un URI (Uniform Resource Identifier) ou par un IRI (Internationalized Resource Identifier).Comme exemples de ressources web, nous pouvons citer des documents électroniques, des images, du son, des bogues, des wikis, des services, etc. A partir de cette définition, générale et ouverte, le web s’est transformé en un espace de partage et d’échange d’information où chacun est capable de faire part de l’information dont il dispose, sans se soucier ni des normes ni des contraintes de conformité à un modèle ou à un format préalablement défini.Parallèlement à l’apparition du web au début des années 90, le monde a subi une informatisation à large échelle. Tous ces changements, et bien d’autres, ont fait du web une plateforme, à très large échelle, de production, de stockage, de partage et de traitement de l’information et à son corollaire, à savoir la connaissance.
Du point de vue applicatif, nous assistons à une croissance continue des logiciels en termes de taille et de complexité. Cette croissance est due, essentiellement, à une évolution des besoins des utilisateurs qui prennent des formes très diverses et expriment des contraintes relativement complexes. Pour faire face à cette dynamique, plusieurs approches ont vu le jour pour améliorer la productivité et l’efficacité des logiciels, comme par exemple les architectures orientées services ou SOA (Service Oriented Architecture) qui s’est accompagnée d’une augmentation exponentielle du nombre de services et de leurs fournisseurs [66].Face à cette explosion, la gestion des services représente un véritable challenge pour les informaticiens (comment identifier les services, sous quel format et où les stocker, comment les rechercher, comment les exécuter à distance, etc.). L’un des plus grands défis est le problème de la recherche de services répondant à des besoins applicatifs exprimés par des utilisateurs. Ainsi, trouver le « bon » service à invoquer, répondant à une requête d’un utilisateur, suppose avoir découvert un ensemble de services potentiels. Puis, à partir de cet ensemble, il s’agit de sélectionner le service le « plus pertinent » pour le proposer à l’utilisateur.
Plusieurs facteurs peuvent venir compliquer cette recherche, comme par exemple:
• Le choix du format de description du besoin: c’est le premier problème qui se pose lors d’une automatisation de la recherche et de la sélection.
• L’absence d’un registre public unifié des services sur le web: la méconnaissance éventuelle de certains registres disponibles fait que la découverte devient difficile voire même impossible.
• Le grand nombre possible de services renvoyés, suite à une requête, complique la tâche de sélection pour un utilisateur. Cette tâche est rendue encore plus complexe par l’utilisation de deux catégories de critères de sélection d’un service : ses aspects fonctionnels (ce que fait le service) et non fonctionnels (comment il le fait).
• L’absence de méthodes de recherche qui pourraient aider l’utilisateur dans l’opération de choix de services qui répondent, au mieux, à ses besoins.
Intérêt des services web
Les services web fournissent un lien entre applications. Ils sont normalisés car ils utilisent les standards XML et HTTP pour transférer des données et sont compatibles avec de nombreux autres environnements de développement. Ils sont donc indépendants des plateformes. Ainsi, des applications utilisant des technologies différentes peuvent envoyer et recevoir des données au travers de protocoles compréhensibles par tout le monde. C’est dans ce contexte qu’un intérêt très particulier a été attribué à la conception des services Web puisqu’ils permettent aux entreprises d’offrir des applications accessibles à distance par d’autres entreprises.Ils sont un concept clé de l’approche Architectures Orientées Services ou SOA (ServiceOriented Architecture). Ils fournissent diverses fonctionnalités qui peuvent être accessibles via le réseau. Dans la vision SOA, le développement de systèmes logiciels peut être effectué rapidement et à faible coût. Les services Web représentent donc la façon la plus efficace de partager des méthodes et des fonctionnalités. De plus, ils réduisent le temps de réalisation en permettant de tirer directement parti de services existants.
Architecture d’un service web
L’architecture des services Web repose sur un mécanisme de transport d’une demande de service entre un client et un serveur, tous les deux connectés au réseau . Dans cette architecture, le client peut être soit un navigateur Web (la demande de service résulte alors directement d’une intervention humaine), soit une application (la demande de service est alors automatisée).Le bus de requêtes est fondé sur TCP/IP et sur HTTP (mais aussi sur SMTP ou POP), ce qui permet son utilisation sur Internet en vue de l’intégration d’applications au sein du réseau interne de l’entreprise ou de la « publication » d’applications préexistantes sur le Web à destination des entreprises partenaires. Comme HTTP ne transmet que du texte, tous les échanges entre services Web (requêtes et résultats de requêtes) circulent également au format texte, sous forme de documents codés en XML (les requêtes, leurs résultats et les erreurs éventuelles résultant de leur invocation).
Standard des services web
La technologie des services web considère les services comme des entités principales et fondamentales. La manière dont ces services sont décrits est décisive pour la réalisation et l’automatisation des différentes taches relatives à ces services telles que la description, la découverte, l’invocation et la composition être considérés quand nous abordons la technologie des services web: les propriétés fonctionnelles et les propriétés non fonctionnelles.
a) Les propriétés fonctionnelles décrivent ce que fait exactement un service (définition des fonctionnalités d’un service) et comment ces fonctionnalités sont accomplies.
b) Les propriétés nonpropriétés fonctionnelles lors de l’ fonctionnelles, les PNFs n’ont pas fait l’objet d’une grande attention auprès de la communauté de recherche dans le domaine des services web. La description des PNFs joue un rôle important dans l’automatisation des différentes taches du service spécialement dans la description, la découverte, l’invocation et la composition des services. Il est simple d’imaginer un scénario où des services résultant de la requête de l’utilisateur peuvent pos fonctionnalités sont alors sélectionnés sur la base de quelques PNFs comm prix ou la performance.
Le manque d’un réel support (langage, méthodologie PNFs est dû principalement au fait que
• Les PNFs sont souvent trop abstraites et sont présentées d’une manière informelle;
• Les PNFs sont souven
• La modélisation des PNFs .
Les PNFs tournent autour de plusieurs concepts [46] telles que la qualité de service (QoS), critère très souvent décisif dans le choix d’un service approprié, la sécurité, la confiance (trust), service free, etc. bLe concept des services Web s’articule autour des trois acronymes suivants :
• SOAP (Simple Object Access Protocol) qui est un protocole d’échange interapplication indépendant de toute plate-forme. Il permet la normalisation des échanges de données. Il repose sur deux standards le langage XML et le protocole de communication HTTP. Mais, il n’exclut pas l’utilisation d’autres protocoles de transport tels que SMTP et POP.
• WSDL donne, à travers une grammaire XML, la description des services Web en précisant les méthodes pouvant être invoquées, leur signature, les protocoles, les serveurs, les ports utilisés, les opérations pouvant être effectuées, les formats des messages d’entrée et de sortie, et les exceptions pouvant être renvoyées.
• UDDI (Universal Description, Discovery and Integration) normalise une solution d’annuaire distribué de Services Web, permettant à la fois la publication et l’exploration. UDDI se comporte lui-même comme un Service Web dont les méthodes sont appelées via le protocole SOAP.
Navigation
Ce mode de recherche exploite la structure hiérarchique des treillis. Il consiste à explorer librement les concepts en s’appuyant sur la visualisation des treillis par des diagrammes de Hasse.Cette forme d’interaction tire profit d’une caractéristique importante de la cognition humaine : “il est plus facile de reconnaître quelque chose d’intéressant que de le décrire”.Le diagramme de Hasse est utilisé comme structure de base pour la recherche. Il offre une interface de navigation permettant de suivre les liens de spécialisation/généralisation entre concepts pour spécialiser ou élargir graduellement l’espace de recherche. Dans le cas général, le scenario de recherche peut être présenté comme suit : partant du concept le plus général du treillis qui représente la classe de tous les documents avec un ensemble de termes communs souvent vide, on effectue une spécialisation graduelle en suivant les liens descendants dans le treillis. Chaque pas dans le treillis est équivalent à l’ajout d’un nombre minimal de nouveaux termes qui spécifient la description des documents à trouver.
Ceci entraîne la restriction de l’espace de recherche à un sous ensemble de documents. Cette opération est répétée jusqu’à l’identification du sous ensemble minimal de documents recherchés. Dans d’autres cas, partant d’une description très précise de documents, on peut relâcher progressivement cette description en suivant le lien ascendant du treillis. Chaque étape correspond à la suppression d’un ensemble minimal de termes ce qui entraîne l’augmentation du nombre de documents qui satisfont la description allégée.De manière générale, on peut effectuer une navigation libre dans le treillis en suivant les liens descendants et/ou ascendants en fonction du besoin en précision lors du passage d’un concept à l’autre dans le treillis.
AFC et recherche d’information
La principale motivation qui a conduit à l’utilisation des treillis de concepts dans la recherche d’information (RI) vient du fait que la classification a permis de combiner la recherche par requête et la recherche par navigation [48]. Les concepts formels organisés en un treillis sont vus comme des classes de documents pertinents pour un ensemble de contraintes données.La RI fut alors explicitement mentionnée comme étant l’une des applications possibles des treillis de concepts [51].Plus tard, fut proposée une approche pour la RI utilisant les treillis de concepts dont celle proposée dans [49], [50]. La relation de subsomption (relation d’ordre partiel entre les concepts du treillis) entre les concepts permet le passage d’un concept à un autre plus général ou plus spécifique offrant ainsi la possibilité de naviguer dans la hiérarchie considérée [51].L’utilisation des treillis de concepts dans les systèmes de recherche d’information spécialisés favorise un meilleur rappel et une meilleure précision. En effet, le domaine de recherche (corpus) est souvent plus restreint, ce qui permet d’une part de réduire les problèmes de passage à l’échelle notamment pour l’aspect navigation et d’autre part d’améliorer les performances du processus de recherche du fait de la non nécessité d’indexation automatique et de l’assise formelle de la FCA [19].
La recherche d’information a été l’une des premières applications phare de treillis de concepts dans la découverte de ressources. Les premiers travaux [33] ont étudié la possibilité d’utiliser les treillis de concepts comme support pour la recherche documentaire. Des collections de documents sont alors représentées sous la forme de contextes formels. Les objets du contexte sont des documents et les attributs sont les termes d’indexation de ces documents. Chaque concept du treillis correspondant est vu comme un couple formé par une requête, dont les mots clés sont les termes contenus dans l’intension du concept, et l’ensemble de documents pertinents pour cette requête sont les documents contenus dans l’extension du concept. Le critère de pertinence dans ce cas est celui considéré dans le cas de la recherche booléenne (conjonctive) à savoir la vérification de tous les critères spécifiés dans la requête. Ceci justifie l’interprétation donnée aux concepts du treillis puisque les objets dans l’extension d’un concept partagent tous les attributs dans son intension.
Le calcul de la réponse à une requête donnée revient à identifier, dans le treillis, le concept dont l’intension est identique à la requête. Les liens de spécialisation/généralisation entre les concepts permettent d’effectuer une recherche progressive dans le treillis. Cette façon de procéder suppose que la requête existe déjà dans le treillis. Pour assurer cette condition, des algorithmes de construction incrémentale de treillis de concepts sont utilisés pour l’insertion des requêtes dans un treillis déjà construit. De cette manière, un premier mode de recherche par treillis a été défini : la recherche par interrogation. La structure hiérarchique des treillis de concepts permet la définition d’un deuxième mode de recherche : la recherche par navigation.
|
Table des matières
Chapitre 1 : Services web
1.1 Introduction
1.2 Définitions
1.3 Intérêt des services web
1.4 Architecture d’un service web
1.5 Standard des services web
1.5.1 Protocole SOAP
1.5.2 Langage de description WSDL
1.5.3 Annuaire des services UDDI
1.6 Recherche de services Web
1.6.1 Recherche dans un annuaire UDDI
1.6.2 Recherche de l’interface du composant à contacter
1.6.3 Invocation du service
1.6.4 Synthèse des approches de recherche
1.7 Conclusion
Chapitre 2 : Analyse des concepts formels
2.1 Introduction
2.2 Contexte formel
2.3 Concept formel
2.4 Treillis
2.4.1 Définition
2.4.2 Treillis de Galois
2.5 Représentation graphique
2.6 Algorithmes de construction de treillis de concepts
2.6.1 Algorithmes batch
2.6.2 Algorithmes incrémentaux
2.6.3 Algorithmes d’assemblage
2.7 AFC et recherche d’information
2.7.1 Interrogation
2.7.2 Navigation
2.7.3 Combinaison des deux modes
2.8 AFC et découverte du Web
2.9 Conclusion
Chapitre 3 : Recherche de services web
3.1 Introduction
3.2 Approche proposée
3.2.1 Définition d’un treillis minimal
3.2.2 Structuration de l’annuaire
3.3 Recherche et sélection de services
3.3.1 Définitions
3.3.2 Recherche de services
3.3.3 Correction et complétude
3.3.4. Complexité de l’Algorithme de recherche
3.4 Sélection de services
3.5 Étude expérimentale
3.5.1. Première série de tests
3.5.2. Deuxième série de tests
3.5.3. Troisième série de tests
3.6 Conclusion
Chapitre 4 : Construction du treillis minimal et sa gestion
4.1 Introduction
4.2 Construction du treillis minimal
4.2.1 Principe de l’algorithme
4.2.2 Construction du treillis minimal
4.2.3 Etude de la complexité
4.3 Suppression de service
4.3.1 Principe
4.3.2 Étude de la complexité
4.4 Ajout et suppression d’opérations
4.4.1 Principe
4.5 Etude expérimentale
4.5.1 Première série de tests
4.5.2 Deuxième série de tests
4.5.3 Troisième série de tests
4.6 Conclusion
Conclusion et perspectives
Bibliographie
Télécharger le rapport complet
