Soutenance mémoire
L’architecture SOA
L’architecture SOA & Les services web
Les dernières décennies ont été marquées par le développement rapide des systèmes d’information distribués, et tout particulièrement par la diffusion de l’accès à Internet. Cette évolution du monde informatique a entraîné le développement de nouveaux paradigmes d’interaction entre applications tels que la SOA. Cette dernière été mise en avant afin de permettre des interactions entre applications distantes. L’architecture SOA est une méthode de conception basée sur des standards, permettant de créer une infrastructure informatique intégrée capable de répondre rapidement aux nouveaux besoins d’un utilisateur. Elle fournit les principes et directives permettant de transformer un réseau existant de ressources informatiques hétérogènes, distribuées, complexes et rigides en ressources intégrées, simplifiées et particulièrement souples pouvant être modifiées et combinées afin de mieux satisfaire les objectifs de l’utilisateur [Boukhadra 2011]. L’architecture SOA est un modèle abstrait, qui définit un système par un ensemble d’agents logiciels distribués, qui fonctionnent de concert afin de réaliser une fonctionnalité globale préalablement établie. SOA se présente comme un style architectural. Elle 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. L’approche ultime de cette vision consiste, donc, à créer des applications constituées uniquement de services qui interagissent entre eux. Dans ce cas, peu importe où est déployé le service, ce qui importe est que le service remplisse un rôle bien précis [Schreiner 2005].
Définition Technique plus Large :
« L’architecture SOA est un paradigme permettant d’organiser et d’utiliser des savoir faires distribués pouvant être de domaines variés. Cela fournit un moyen uniforme d’offrir, de découvrir, d’interagir et d’utiliser des savoirs faires pour produire le résultat désiré avec des pré-conditions et des buts mesurables. » [Josuttis 2007]. Du point de vue des applications, l’architecture orientée services permet le développement d’une nouvelle génération d’applications dynamiques ou composites. Ces applications permettent aux utilisateurs d’accéder à des informations et à des processus hétérogènes, et de les utiliser de différentes manières, notamment via le Web. Du point de vue de l’infrastructure, l’architecture orientée services permet au service Web de simplifier l’intégration des applications et des systèmes, de recombiner et de réutiliser les fonctionnalités des applications, et d’organiser les différentes phases du processus de développement, dans un cadre cohérent et unifié. En réalité, la philosophie des SOA décompose une application monolithique en une suite de services assurant la modularité dans leurs fonctionnalités [Devaux 2008].
Historique de l’architecture SOA Dans les années 80, l’architecture orientée objet est apparu comme une nouvelle philosophie de développement basée sur des concepts intéressants : encapsulation, héritage, . . . etc. Le problème de l’approche objet est le fait d’offrir juste la réutilisation technique sans aucune vue métier. Cette architecture rend difficile l’intégration d’applications résidentes dans plusieurs plateformes. Enfin, l’architecture objets est fragile, car un service de ce système est offert comme une méthode d’une classe implémentée par un objet [Bieberstein 2008]. Pour pallier les défauts de l’approche objet, l’approche composant est apparue. Le modèle de composants le plus commun dans l’environnement Windows est le COM. Les composants COM dans chacune de ses couches peuvent être réutilisés par d’autres composants et applications. Dans le monde Java, CORBA est le plus utilisé. Il rend possible la distribution des tâches de développement à travers plusieurs programmeurs, et fait que, le système soit plus robuste, scalable, et maintenable [Bieberstein 2008].
Les composants sont des entités logicielles indépendantes. Ils interagissent à l’aide d’une infrastructure qui permet de gérer la communication entre des composants au sein d’un même système ou à travers un réseau, via une décomposition du logique métier en composants distribués. L’architecture de composants distribués a engendré un développement rapide et évolutif d’applications distribuées et complexes. L’écriture des composants pouvant être partagés doit prendre en considération que les différents langages de programmation sont incompatibles. Un composant écrit en C++ peut avoir des anomalies de fonctionnement, s’il est utilisé dans un environnement où le Visual Basic est le langage principal. L’interopérabilité des plateformes n’était plus facile avec les modèles de composants utilisés ces dernières années. Cette interopérabilité s’avère encore plus difficile si le composant à invoquer est situé au-delà d’un pare-feu [Erl 2008].
La mise en oeuvre de ces deux architectures soulève des difficultés dans le cadre d’une infrastructure ouverte telle qu’Internet. En effet, ces architectures, bien qu’utilisant un modèle objet distribué, proposent, chacune, sa propre infrastructure. Ce qui impose une forte liaison (un fort couplage) entre les services offerts par les composants et leurs clients. Ainsi, on ne peut assembler que des objets CORBA (ou COM) entre eux. Le résultat est que les systèmes construits à base de ces architectures sont homogènes. Dans les années 2000, sont apparus les services Web pour pallier à tous ces problèmes, et en ne s’intéressant qu’à la manière d’interagir avec ce service Web sans connaître sa structure ou sa technologie. Une application orientée services Web est simplement l’agrégation de services en une logique simple et en une application unifiée. Cependant, la clé de l’interopérabilité entre les services Web est l’utilisation des protocoles standards, des messages, et des contrats.
En outre, après l’avènement du B2C, où les entreprises mettaient en ligne leurs services pour leurs consommateurs à travers des applications Web, celles-ci souhaitaient accroître leurs productivités à l’aide du paradigme B2B. Le B2B repose sur l’échange de produits, d’informations et de services entre entreprises. Ceci implique l’utilisation de services et la collaboration avec des systèmes proposés par d’autres concepteurs, et par conséquent, une maîtrise de l’hétérogénéité [Papazoglou 2003].
Architecture étendue Une architecture étendue est constituée de plusieurs couches se superposant les unes sur les autres. La pile est constituée de plusieurs couches, chaque couche s’appuyant sur un standard particulier. On retrouve, au-dessus de la couche de transport, les trois couches formant l’infrastructure de base décrite précédemment. Nous apportons une explication de la mise en relief des trois types de couches (Figure I.2) : L’infrastructure de base (Discovery, Discription, Exchange) : Ce sont les fondements techniques établis par l’architecture de référence. Nous distinguons les échanges des messages établis par SOAP (W3C), la description de service par WSDL (W3C) et la recherche de services Web que les organisations souhaitent utiliser via le registre UDDI (OASIS). Couches transversales (Security, Transactions, Administration, QoS) : Ce sont des couches qui rendent viable l’utilisation effective des services Web dans le monde industriel. La couche Business Processus (BusinessProcess) : Cette couche supérieure permet l’intégration de services Web, elle établit la représentation d’un « BusinessProcess » comme un ensemble de service Web. De plus, la description de l’utilisation de différents services composant ce service est disponible par l’intermédiaire de cette couche.
Le langage WSDL Le langage WSDL (W3C), est l’acronyme de « Web Service Description Language »est un langage basé sur XML permettant de décrire et de publier les interfaces et protocoles des services Web d’une manière standard. L’interface d’un service Web décrit en fait tout le fonctionnement d’un service Web, et cache tout le détail de l’implémentation du service Web, donc elle est indispensable pour pouvoir invoquer un service Web par une application cliente, ou un autre service Web permettant une utilisation indépendante de la plateforme utilisée ainsi que du langage utilisé [Scott 2002]. Le langage WSDL présente un format commun pour la description et la publication des interfaces et protocoles relatifs aux services Web. Une description WSDL d’un service Web est faite sur deux niveaux, niveau abstrait et niveau concret. Au niveau abstrait, la description du service Web consiste à définir les éléments de l’interface du service Web tel que : [Chinnici 2004] [Gardien 2002]. Les types de données : « Data types » est l’élément qui définit les types de données utilisées dans les messages échangés par le service Web. Une fois définie, les « Data types », ou type peuvent être référencés dans n’importe quel message. Les messages : L’élément « Message »spécifie les types d’opérations supportées par le service Web, il permet d’incorporer une séquence de messages corrélés sans avoir à spécifier les caractéristiques du flux de données, par exemple, un message Input et un message Output corrélés sont mis en correspondance dans une seule opération de type « Request/Response ».
|
Table des matières
Liste des figures
Résumé
Introduction générale
Chapitre I: L’architecture SOA Les services web
Introduction
I.Définition de l’architecture SOA
I.1 Définition Métier
I.2 Définition Technique
I.3 Définition Technique la plus Large
I.4 Historique de l’architecture SOA
I.5 Caractéristiques de l’architecture SOA
I.5.1 Autonomie
I.5.2 Frontières explicites
I.5.3 La Plateforme
I.5.4 Architecture décentralisée
I.5.5 Les Protocoles
I.5.6 Le Langage de programmation
I.5.7 Les Modèles d’invocation
II.5.8 Le Modèle d’un service
III. Définitions des services Web
III.4 Caractéristiques des services Web
III.5 Avantages des services Web
III.6 Architecture des services Web
III.6.1 Architecture de référence
III.6.2 Architecture étendue
III.7 Les principales technologies standards autour de service Web
III.7.1 Le protocol SOAP
III.7.2 Le langage WSDL
III.7.3 L’annuaire UDDI
Conclusion
CHAPITRE II : Optimisation multi-objectif évolutionnaire
I.Introduction
II.Optimisation multi-objectifs
II.1 Définition
II.2 Vocabulaire et Terminologie
II.2.1 Vecteur de décision
II.2.2 Fonction objectif
II.2.3 Notion de dominance au sens de Pareto
II.2.4 Optimum au sens de Pareto
II.3 Approches de résolution d’un problème multi-objectif
II.3.1 Méthode agrégative
II.3.2 Méthode non agrégative
III. Evolution artificielle
III.1 Principe d’un algorithme génétique standard.
III.1.1 Initialisation de la population
III.1.2 Sélection
III.1.3 Croisement
III.1.4 Mutation
III.1.5 Remplacement
IV.Algorithme génétique élitiste de tri non-dominé (NSGA-II)
IV.1 Classification des individus
IV.2 Distance de crowding
IV.3Opérateur de sélection
IV.4 Etapes du NSGA-II
Conclusion
CHAPITRE III : Conception et Implémentation du prototype
I.Introduction
II.La Qualité de Service
III. Modèles de QoWS existants
IV.QoWS considérées
V.Scénario
VI.Présentation de la base
VII. Conception
VIII. Interface homme machine
Expérimentation
Conclusion
Conclusion Générale et perspectifs
Références Bibliographiques
Annexe
Télécharger le rapport complet
