Conception et Implémentation du prototype

Conception et Implémentation du prototype

Le web évolue très rapidement, il n’est plus maintenant une source statique d’informations, mais un vrai réseau dynamique dans lequel les ressources sont partagées et l’information est produite sur demande. Les organisations commerciales exploitent actuellement de plus en plus le web pour l’adaptation aux marchés à travers les applications B2B (intégration de Business-toBusiness) et les applications B2C (Business-to-Consumer). L’importance des standards dans ce contexte a sans doute accentué le phénomène. Mais il arrive très fréquemment que plusieurs services répondent à un même ensemble de besoins fonctionnels, d’où la nécessité de la naissance du domaine de la sélection de services Web a base de qualité de service.

Les services web 

Ces dernières années, la recherche dans le domaine des services web a été très active. Une grande partie de cette recherche a été consacrée à la composition de services web. L’idée originale de « composition de service » n’est pas vraiment nouvelle dans la conception de logiciel. Elle peut être comparée au concept de bibliothèque exécutable dans beaucoup de langages de programmation. En appliquant cette idée au génie logiciel, il est possible de développer de nouvelles applications en utilisant des composants logiciels préexistants. Ce procédé est désigné par « composition » ou «réutilisation » de composants. Dans la communauté des services web, des efforts importants sont maintenant consacrés à ce problème, qui regroupe la découverte de services web, leur composition et leur exécution.

L’architecture SOA 

L’architecture SOA (Service Oriented Architecture) fournit un ensemble de méthodes pour le développement et l’intégration de systèmes dont les fonctionnalités sont développées sous forme de services interopérables et indépendants. Une infrastructure SOA vise à permettre l’échange d’informations entre applications. Les concepts de SOA se basent sur des concepts plus anciens, en particulier l’informatique distribuée et la programmation modulaire.  Afin de mettre en œuvre une architecture SOA avec succès, il ne suffit pas d’avoir les capacités technologies. Il convient également d’adopter un certain nombre de principes importants au niveau de la conception, du développement et de la gestion. Dans le cadre de SOA, ces principes constituent un frame work qui va permettre aux clients et aux services de collaborer et servir d’orientation pour la conception et le développement de services. Il existe de nombreux principes qui peuvent être appliqués à une SOA, on peut cependant dénoter quatre principes fondamentaux qu’il est nécessaire de respecter qui sont les suivants :

Couplage faible
Le couplage est une métrique indiquant le niveau d’interaction entre deux ou plusieurs composants logiciels. Deux composants sont dits couplés s’ils échangent de l’information. On parle de couplage fort (ou serré) si les composants échangent beaucoup d’information et de couplage faible (ou relaxé) dans le cas contraire. Dans une architecture SOA, le couplage entre les applications clientes et les services doit être faible. Cela signifie qu’il y a une séparation logique qui isole le client du service afin d’éviter une dépendance physique entre les deux. Pour ce faire, le client communique avec le service par échange de messages dans un format standard. Il est ainsi possible de modifier un service, par exemple pour y ajouter des fonctionnalités, sans briser la compatibilité avec les applications clients existantes. En cas de couplage fort, la possibilité d’évolution des services serait très limitée.

Interopérabilité
Tout comme le couplage faible, l’interopérabilité est un critère primordial pour mettre en œuvre une architecture SOA avec succès. L’interopérabilité se définie comme la capacité que possède un produit ou système, dont les interfaces sont intégralement connues, à fonctionner avec d’autres produits ou systèmes existants ou futurs. Il convient de distinguer la compatibilité et l’interopérabilité. En effet, la compatibilité est une notion verticale qui fait qu’un produit peut fonctionner dans un environnement donné en respectant ses caractéristiques. La notion d’interopérabilité est au contraire transversale qui permet à deux produits de communiquer de part une connaissance bilatérale de leur manière de fonctionner. L’interopérabilité est rendue possible par le respect de normes et formats par tout système ou produit. Dans le cas d’une architecture SOA, l’interopérabilité permet à des applications clients de communiquer avec des services programmés dans des langages de programmation différents et s’exécutant sur des plateformes (logicielles ou matérielles) différentes. Similairement au couplage faible, la communication par échange de messages joue ici un rôle très important. En effet, l’application ne connaît pas et n’a pas besoin de connaître le fonctionnement interne d’un service pour pouvoir l’utiliser. Il est simplement nécessaire de définir un format d’échange standard entre le client et le service. Le format XML est largement accepté et pris en charge pour l’encodage des messages. En effet, la plupart des plateformes technologiques sont aptes à générer et à traiter des messages au format XML.

Réutilisabilité
Le principe de réutilisabilité permet de réduire les coûts de développement en favorisant la réutilisation de parties de codes qui ont déjà été réalisées. Dans le cas de SOA, l’objectif de la séparation des tâches en services autonomes est en effet de promouvoir leur réutilisation. Ainsi, lorsque les nouveaux clients définissent leurs besoins, il est généralement possible d’utiliser certains services existants pour satisfaire une partie des besoins. Ceci permet un gain de temps considérable et une réduction importante de la taille des applications par évitement de la duplication. Ceci facilite également la maintenance et diminue les chances de bogues dans le programme. Dans une architecture SOA, la granularité du découpage des fonctionnalités en services est également importante. Il faut que celle-ci soit suffisante pour qu’un service soit significatif et utile.

Découverte
La découverte est une étape importante pour permettre la réutilisation des services. Il faut en effet être en mesure de trouver un service afin de savoir qu’il existe et pouvoir en faire usage. Ainsi, même si un service fournit une fonctionnalité importante, il serait très inefficace s’il n’était pas découvrable pour être réutilisé plus tard. Une solution typique pour ce genre de problème consiste à utiliser un annuaire de services. Un annuaire est très similaire à un catalogue ou un inventaire de services. L’annuaire contient des informations publiées concernant les services et fournit typiquement une possibilité de recherche basée sur une fonctionnalité recherchée. Il est alors nécessaire qu’un service pour SOA soit conçu pour être suffisamment descriptif pour qu’il soit facilement localisable et accessible via un mécanisme de découverte. Le développeur peut alors simplement consulter cet annuaire afin de trouver un service adéquat pour réaliser une tâche donnée et l’utiliser dans son code.

Définitions 

Définition 1 : Les services web sont des applications auto descriptives, modulaires et faiblement couplées qui fournissent un modèle simple de programmation et de déploiement d’application, base sur des normes, et s’exécutant a travers l’infrastructure web. Les services web réalisent des fonctions allant des simples requêtes aux processus métier sophistiqués.

Définition 2 : « A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-process able format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. »

Architecture des services Web 

Architecture de base
Le modèle des services Web repose sur une architecture orientée service. Celle-ci fait intervenir trois catégories d’acteurs : les fournisseurs de services (i.e. les entités responsables du service Web), les clients qui servent d’intermédiaires aux utilisateurs de services et les annuaires qui offrent aux fournisseurs la capacité de publier leurs services et aux clients le moyen de localiser leurs besoins en terme de services. La dynamique entre ces trois acteurs inclut donc les opérations de publication, de recherche et de liens (binding) d’opérations. Cette dynamique est normalisée à travers 3 standards : un protocole abstrait de description et de structuration des messages (SOAP), une spécification XML qui permet la publication et localisation des services dans les annuaires UDDI, et un format de description des services Web (WSDL). Un service WSDL est composé d’un ensemble d’opérations élémentaires, chacune décrite par un flux de messages échangés entre le client et le service.

Architecture en couche
La normalisation actuelle autour des Web Services est cependant une organisation complexe qui va bien au-delà de la simple invocation d’une méthode d’un objet distant. Différents travaux ont ainsi démarré pour permettre d’établir une véritable infrastructure distribuée, capable de satisfaire l’ensemble des besoins d’une application distribuée, aussi bien en termes de normalisation des échanges qu’en termes de services transverses. [6] Cette organisation par comités de normalisation peut être schématisée selon le découpage matriciel suivant :
– Cette normalisation des services transverses se fait sur trois axes horizontaux :
– Couche de transport : Définition de la structure des messages utilisés par les applications pour se découvrir et dialoguer entre elles. Cette couche est à l’heure actuelle la seule réellement normalisée et qui ne souffre d’aucune contestation. Elle s’appuie sur le protocole SOAP pour l’échange des messages et sur le langage WSDL pour la définition du contrat de l’interface.- Couche de sémantique : Normalisation des données participant aux échanges selon des critères métier. Les initiatives de définition de la couche de sémantiques des messages sont nombreuses et n’ont pour le moment pas conduit à une quelconque normalisation. Deux types d’organisation sont actuellement ouverts, l’une établie selon les différents corps de métier, l’autre suivant une approche plus globale autour de consortium tel qu’OASIS (initiateur d’ebXML) ou RosettaNet.
– Couche de gestion des processus : Standardisation de la gestion des processus métier qui s’étendent sur plusieurs applications disponibles sur Internet. L’orchestration de transactions B2B (Business to Business) complexes, fondée sur une architecture normalisée des messages est aussi une tentative qui n’avance pas assez rapidement et sur des standards non murs.
– Et trois axes verticaux :
– Service d’annuaire : Standardisation des moyens d’accès à un service à partir d’une requête portant sur le contenu d’un service ou sur un fournisseur. La première proposition d’annuaire UDDI aurait du apporter une solution définitive. Le constat est qu’il n’en est rien et que la trame, trop globale, du projet ne suffit pas à régler cette problématique d’échanges entre applications se connaissant. Une deuxième proposition d’annuaire, WS Inspection, vient concurrencer celle-ci. Moins ambitieuse puisque consistant en une simple exposition, par agrégation, des services d’une application, elle est toutefois plus adaptée à cette seconde problématique.
– Service de sécurité : Normalisation des moyens permettant de couvrir les problématiques d’authentification et de gestion des droits d’accès. La gestion de la sécurité est actuellement le frein le plus important à la mise en place d’architectures distribuées à base de Web Services. Plusieurs organisations sont ouvertes mais aucune n’est réellement acceptée. Il semblerait que la norme XACML (eXtensible Access Control Markup Language) puisse supplanter SAML (Security Assertion Markup Language) et s’imposer à terme comme standard de sécurité.
– Service de transaction : Normalisation des moyens permettant de garantir l’intégrité des transactions longues impliquant plusieurs Web Services. Le problème reste le même que pour la sécurité. Les standards ne sont pas tout à fait établis. La lutte pour l’obtention d’une norme est beaucoup plus ouverte que pour celle de la sécurité, même si BTP (Business Transaction Protocol) semble plus soutenu actuellement.

Conclusion Générale 

Ce projet de fin d’étude présente le fruit de notre travail, il nous a permis de connaitre beaucoup de choses qui ont amélioré nos connaissances. A travers ce travail nous a essayés d’atteindre les besoins de sélection des services web. Nous avons présenté aussi une application qui utilise l’algorithme à base de sélection clonale pour instancier une composition qui satisfait les besoins de l’utilisateur. La composition concrète recherchée doit maximiser un ensemble de critères de Qos (Quality of service) positifs et minimiser un ensemble de critères négatifs, en plus elle doit satisfaire un groupe de contraintes globales. En ce qui concerne les perspectives de notre travail nous prévoyons les points suivants :
• L’utilisation de l’aiNet (Artificial Immune Network) pour le problème de sélection
• L’utilisation de la programmation par contrainte (et en particulier l’algorithme Branch and Bound).
• L’utilisation des aiNet et clonalg dans une version multi-objectifs.

Table des matières

INTRODUCTION GENERALE 
I. Contexte
II. Problématique
III. Contribution
IV. Plan du mémoire
Chapitre I: Les services web 
I. Introduction
II. L’architecture SOA
1. Couplage faible
2. Interopérabilité
3. Réutilisabilité
4. Découverte
III. Définitions
IV. Architecture des services Web
1. Architecture de base
2. Architecture en couche
V. Cycle de vie
VI. Les principales technologies de développement de service Web
1. XML (eXtensible Markup Language)
2. Le protocole SOAP (Simple Object Access Protocol)
2.1. Définition
2.2. Structure d’un message SOAP
2.3. Fonctionnement
2.4. Types de message SOAP
3. La technologie WSDL (Web Service Description Language)
3.1. Définition
3.2. Structure d’un document WSDL
4. UDDI – Universal Description Discovery and Integration
4.1. Définition
4.2. La recherche d’un service Web
4.3. La publication d’un service Web
VII. Les avantages et les inconvénients des services Web
1. Avantages
2. Inconvénients
VIII. Conclusion
Chapitre II : Sélection des services web
I. Introduction
II. Exemple de motivation : (la création d’une entreprise)
III. Critères de Qos (Quality of service)
IV. La fonction objectif (score ou fitness)
V. Optimisation combinatoire
1. Définition
2. Approches d’optimisation combinatoire (approches de sélection)
VI. Conclusion
Chapitre III: Les Systèmes Immunitaires 
I. Introduction
II. Le système immunitaire naturel (SIN)
1. L’immunité innée (naturelle non spécifique ou naïve)
2. L’immunité acquise (spécifique)
3. Caractéristique du système immunitaire
4. Éléments du système immunitaire
4.1. Les organes du système immunitaire
4.2. Les cellules du système immunitaire
5. Théorie de la sélection clonal
III. Le système immunitaire artificiel (SIA)
1. Définitions
2. La sélection clonale
3. La sélection négative
4. Les réseaux immunitaires (ou idiotypiques)
5. Domaines d’application des SIAs
5.1. Robotique
5.2. Optimisation
5.3. Sécurité des ordinateurs
IV. Conclusion
Chapitre IV: Conception et Implémentation du prototype
I. Introduction
II. Description de la base
1. Description de la base
2. Description de la requête
III. Conception
1. Diagramme de cas d’utilisation
2. Diagramme de séquence
3. Diagramme de classe
IV. Interface Humain/Machine (IHM)
1. Fenêtre principale
V. Expérimentation
VI. Conclusion
Conclusion Générale

Télécharger le rapport complet