Soutenance mémoire
ETAT DE L’ART DES SERVICES WEB
Les services web et les technologies associées sont très présents dans l’informatique d’aujourd’hui. Les services web sont à l’heure actuelle de plus en plus incontournables. La preuve en est que ce sujet est de plus en plus abordé dans les publications scientifiques, les conférences, les magasins techniques mais aussi au sein de brochures commerciales. Nous allons dans la suite essayer de présenter les services Web, mais auparavant, revenons quelques années en arrière pour comprendre d’où ils sont issus.
Historique
L’historique des services Web est bien relaté dans la littérature [1, 4], mais, l’historique que nous présentons ne représente qu’un choix restreint et d’autres théories peuvent s’appliquer. Il faut remonter à la fin des années quatre-vingt-dix, une période où de nombreuses nouvelles technologies font leur apparition, comme par exemple XML (eXtended Markup Language). C’est aussi à cette période que l’on assiste à une véritable explosion du marché du Web où les acteurs économiques annoncent que la majeure partie des consommateurs américains sera bientôt connectée à Internet. L’un des facteurs majeurs, si ce n’est le principal facteur, de l’avènement des services web sur les ordinateurs de tous les jours est la démocratisation des réseaux et d’Internet en particulier. En effet, alors qu’avant 1995-1998, un or dinateur était principalement destiné à fonctionner de façon autonome. Aujourd’hui, un ordinateur sans accès au réseau des réseaux (Internet) se trouve limité au niveau de ses fonctionnalités et de l’accès aux informations. Ce facteur est, de plus, présent au niveau des entreprises, mais également des particuliers, d’où une évolution et un changement totalement radical de l’utilisation de l’ordinateur. Ce changement radical de l’utilisation des ordinateurs va entraîner :
– Un problème de gestion du parc d’ordinateurs hétérogène,
– Une sous utilisation des ressources (ordinateurs de bureau) et une répartition des calculs et des données,
– Un problème d’interopérabilité et de connectivité des utilisateurs, systèmes, applications, périphériques se t rouvant dans le périmètre de l’entreprise, mais aussi chez les constituants externes : partenaires, clients et fournisseurs.
De nombreuses méthodes et technologies ont été utilisées pour résoudre ces problèmes. En effet, grâce à l’avènement des architectures distribuées à base de composants, CORBA, RMI et DCOM, qualifiés d’ORB (Object Request Broker) ont rencontré un certain succès, surtout à l’intérieur d’une entreprise. Mais aucune n’a vraiment réussi à s’imposer et à être adoptée de manière universelle. D’une part, elles nécessitaient généralement un investissement en compétences et un temps de développement important pour connecter une application métier à une application métier. D’autre part, ils n’ont jamais réussi à remplir tous les critères indispensables à u ne large adoption. Ils nécessitent le même runtime de chaque côté et fonctionnent difficilement au travers des pare-feux, entre autres. Object Management Group (OMG) a défini le Common Object Request Broker Architecture (CORBA) qui, avec son protocole Internet-Inter-ORB (IIOP) dispose de plusieurs mises en œuvre commerciales ou gratuites, mais malheureusement elle souffre d’un déploiement limité et est très complexe. CORBA exige de compiler et distribuer des stubs client pour chaque type de clients que vous avez. Ce n’est pas toujours pratique, particulièrement quand vous avez un grand nombre de combinaisons de plates formes et de langages ou quand vous voulez offrir des services à des clients anonymes au travers d’Internet. S a version 3.0 est une spécification de 560 pages! L’OMG a décidé aussi d’intégrer le modèle EJB comme middleware plutôt que de rester neutre par rapport au langage, ce qui pose un problème d’interopérabilité. Le modèle COM distribué (également appelé DCOM, Distributed Component Object Model), le système d’objets distribués de Microsoft, est une interface ActiveX destinée aux applications réseau de composants distribués. Le modèle DCOM offre également une transparence au niveau du réseau et une automatisation des communications, de sorte que les communications peuvent intervenir entre des objets sans qu’un objet connaisse nécessairement l’emplacement de l’autre objet. Les objets peuvent se situer dans des processus différents sur la même machine ou sur des machines distinctes. Le modèle COM distribué permet une interopérabilité transparente entre les applications ActiveX exécutées sur différentes machines, en utilisant un appel de procédure à distance (RPC, Remote Procedure Call) standard. Le mécanisme RPC, appelé Microsoft RPC, a été conçu à partir du s tandard RPC de l’environnement DCE (Distributed Computing Environment) de l’OSF (Open Software Foundation). Le modèle COM distribué permet aux développeurs de l’entreprise de diviser une application en modules de composants qui peuvent tous s’exécuter de façon transparente sur différents ordinateurs. Grâce à cette transparence réseau, ces composants semblent, pour les utilisateurs et les programmeurs, être situés sur une même machine.
La technologie des objets distribués peut également être utilisée pour faire apparaître des réseaux et des ressources d’information globaux comme locaux, facilitant et accélérant pour les utilisateurs l’accès aux informations stratégiques de l’entreprise. Par l’intermédiaire du modèle COM distribué et de l’automatisation à distance, les utilisateurs peuvent situer et exécuter des composants sur des réseaux globaux, sans même être conscients que les informations sont à des milliers de kilomètres. RMI (Remote Method Invocation) est une API Java permettant de manipuler des objets distants (c’est-à-dire un objet instancier sur une autre machine virtuelle, éventuellement sur une autre machine du réseau) de manière transparente pour l’utilisateur, c’est-à-dire de la même façon que si l’objet était sur la machine virtuelle (JVM) de la machine locale. Ainsi un serveur permet à un c lient d’invoquer des méthodes à distance sur un objet qu’il instancie. Deux machines virtuelles sont donc nécessaires (une sur le serveur et une sur le client) et l’ensemble des communications se fait en Java. On dit généralement que RMI est une solution « tout Java », contrairement à la norme CORBA de l’OMG (Object Management Group) permettant de manipuler des objets à distance avec n’importe quel langage. CORBA est toutefois beaucoup plus compliqué à mettre en œuvre, c’est la raison pour laquelle de nombreux développeurs se tournent généralement vers RMI. Ces différentes approches présentent de nombreux inconvénients :
– Les protocoles ne passent généralement pas les firewalls,
– La même technologie doit être déployée de chaque coté pour assurer la communication,
– Elles sont coûteuses car nécessitent l’usage de logiciel middleware spécialisé comme les serveurs d’application,
– Elles sont complexes car le développeur doit avoir une connaissance de l’application à d istance (méthodes, paramètres) avant d’écrire le code pour l’utiliser,
– Elles sont fragiles car si le partenaire fait évoluer son application, le code client peut ne plus fonctionner.
D’autre part, connecter deux entreprises demande à ce que chacune des parties comprenne l’autre. Dans le passé, cet échange était souvent réalisé par téléphone ou échange de fax et si une anomalie apparaissait elle était résolue manuellement. Les applications doivent être maintenant capables de se co nnecter les unes aux autres et les processus automatisés pour supprimer toute intervention humaine et éliminer au maximum les sources d’erreur. Pour réaliser cet échange d’informations entre partenaires, un accord à trois niveaux est quasi obligatoire : Le premier niveau est la couche de transport ou message. Ce niveau est responsable de l’échange de message entre un point A et un point B de manière fiable, sécurisée et transactionnelle. Le deuxième niveau concerne le contenu et le type de messages échangés dont le sens doit être compris par chacune des parties. Le troisième niveau concerne le processus qui définit l’orchestration des échanges entre les différentes parties qui doivent se mettre d’accord sur les séquences et la logique d’échange des messages, la qualité de services et la manière de traiter les erreurs. Il y a alors une nécessité de trouver une solution économique et indépendante des technologies. Cette solution doit se baser sur des protocoles interopérables, neutres vis-à-vis des langages, des systèmes d’exploitation, des bases de données, des outils de développement, du middleware. Ces protocoles doivent aussi être modulaires et évolutifs. Les services Web apparaîtront comme solution conçue pour faciliter les échanges de données, mais aussi l’accès aux applications au sien des entreprises et surtout entre les entreprises.
|
Table des matières
Introduction
CHAPITRE 1 : ETAT DE L’ART DES SERVICES WEB
I. Historique
II. Présentation des services Web
1. Architecture orientée services (SOA)
2. Définition des services Web
3. L’architecture des services Web
4. Inconvénients
Conclusion
CHAPITRE 2 : LA TECHNOLOGIE XML
Introduction
I. Un langage de balisages
II. Les DTD
III. XML Schéma
IV. La séparation du fond de la forme
Conclusion
CHAPITRE 3 : ETAT DE L’ART DE L’ANALYSE DES PERFORMANCES DES SYSTEMES INFORMATIQUES
I. Etat de l’art de l’analyse des performances des systèmes informatiques
1. Approches candidates pour l’analyse des performances
2. Les métriques de performance
3. métriques de performances utilisées dans les systèmes distribues
CHAPITRE 4 : RAPPELS SUR LES PROCESSUS STOCHASTIQUES
I. Variables aléatoires
1. La loi de poisson
2. La loi exponentielle
3. La loi géométrique
4. La loi hypo-exponentielle
5. La loi hyper-exponentielle
II. Chaînes de Markov
1. Les chaînes de Markov à temps continu (CMTC)
2. Les chaînes de Markov à temps discret (CMTD)
3. Processus semi markoviens
4. Agrégation des chaînes de Markov
Conclusion
CHAPITRE 5 : LES FILES D’ATTENTE ET LES RESEAUX DE FILES D’ATTENTE
Introduction
II. La file simple
1. Processus d’arrivée
2. Temps de service
3. Structure et discipline de la file
4. Performance des files d’attente
IV. Les réseaux de file d’attente
1. Les réseaux mono classe ouverts à forme produit
2. Les réseaux mono classe fermés à forme produit
Conclusion
Les services Web dans les systèmes distribués : spécification et études de performances
DEA d’Informatique Youssou KASSE 3
CHAPITRE 6 : IDENTIFICATION DES PROBLEMES DE PERFORMANCE DES SERVICES WEB, LEURS PLANIFICATIONS ET LEURS ETUDES DE PERFORMANCE
I. Problèmes de performance des services Web
1. Perception de la performance
2. Les sources des délais
3. L’infrastructure Web
4. Architectures serveur
5. Les réseaux
II. Planification de la capacité des services Web
1. Capacité adéquate
2. Une méthodologie de planification de capacité pour les services de Web
III. Architecture de teste
IV. Analyse du modèle
1. Paramètres d’entrée du modèle
2. Longueur des files d’attente des différents LAN
3. Temps de réponse du système en fonction de la charge
4. Taux de d’utilisation des LAN
Conclusion
Bibliographie et Webographie
Annexe
