L’implémentation côté serveur

L’implémentation côté serveur

Un service web est le fait de mettre des ressources à disposition (gratuite ou non) sur Internet, via un protocole d’échanges standardisé, pour des programmes écrits dans des langages quelconques. Dans les dernières années, les services web occupent un espace très important dans l’informatique parce qu’ils représentent une solution largement répondue à plusieurs problèmes posés. Notre application est une simple application web service. Le serveur est implémenté en utilisant Tomcat comme serveur web et la bibliothèque Axis2 comme moteur de web service, le serveur fournit un service de conversion de devises. Le côté client et une simple application Java qui comporte deux types de clients : un client utilisateur, à travers lequel les utilisateurs de l’application bénéficient du service de conversion offert par le serveur et un client administrateur, utilisé par l’administrateur de l’application pour effectuer les différentes tâches d’administration tel que la mise à jour du taux de change.

LES MIDDLEWARES

Historique : 

Au début de l’informatique, le dialogue entre machines nécessite une connaissance approfondie des protocoles réseau et parfois même du matériel réseau. La programmation orientée objet a permis le développement des architectures distribuées en fournissant des bibliothèques de haut-niveau pour faire dialoguer des objets répartis sur des machines différentes entre eux, ce qui a considérablement allégé le travail des programmeurs. Les objets distribués sur le réseau communiquent par messages en s’appuyant sur l’une des technologies suivantes :
• Common Object Request Broker Architecture ou CORBA : ce standard de l’Object Management Group permet de faire communiquer des objets écrits dans des langages différents (C++, Java, Smalltalk) et même d’encapsuler des programmes écrits dans des langages procéduraux pour les faire passer pour des objets.
• Remote Method Invocation ou RMI : cette technologie de Sun permet de faire communiquer très simplement des objets java distribués sur le réseau.
• Les services web XML.
• NET Remoting : vous permet de créer facilement des applications largement distribuées, si les composants de l’application sont tous sur un même ordinateur ou répartis à travers le monde entier.
• Windows Communication Foundation (WCF) : est une technologie de développement d’applications basées sur une architecture orientée services (SOA) .

Un autre middleware appelé service web, est apparu au début des années 2000. Il permet l’interconnexion des applications à l’aide des protocoles d’internet.

Ce middleware a été favorisé par le développement et la démocratisation du haut débit, l’expansion du langage de structuration XML et le manque d’interopérabilité. Nous notons que certaines entreprises publiaient déjà de l’information via des sites web, utilisaient la messagerie et faisaient du commerce électronique, mais avec l’avènement des services web l’échange inter et intra entreprise sera plus organisé et plus automatisé. La première société à avoir introduit un concept de services distribués, proche de ce qui existe aujourd’hui, est Hewlett-Packard avec son produit e-Speak, et ce dès 1999. La suite fut une grande course entre les principaux acteurs du marché qui ont progressivement, par soucis d’interopérabilité, adopté les principaux standards des services web que sont SOAP, WSDL et UDDI. On notera que e-Speak possède un modèle de sécurité très solide, reposant sur le standard SPKI (Simple Public Key Infrastructure) de l’IETF.

ÉVOLUTION des middlewares

Dans cette partie, on va donner les différents types de middleware et leurs avantages et inconvénients.
• Remote Procedure Call
• Message Oriented Middleware
• Objets Distribués
• Database Oriented Middleware.
Dans la suite de ce paragraphe, on va étudier en détail les différentes caractéristiques de ces Middlewares, leurs avantages, leurs inconvénients, et on va arriver à trouver la différence entre l’utilisation des ces anciens Middlewares et l’utilisation des nouvelles technologies (à savoir les services web).

Motivations : évolution des middlewares – RPC1 

RPC (Remote Procedure Call) est un protocole réseau permettant de faire des appels de procédures sur un ordinateur distant selon le modèle client serveur. Principe : Le principe de RPC est :
• On différencie le coté appelant (client) du coté appelé (serveur).
• Appelé offre la possibilité à des éléments distants d’appeler une ou plusieurs fonctions chez lui.
• Le coté client appelle localement la fonction sur un élément spéciale qui relayera la demande d’appel de fonction coté serveur.
• Coté serveur, un élément spécial appellera la fonction et renverra le résultat coté client.
• Eléments spéciaux : talons (ou stubs).

Les avantages

Parmi les principaux avantages de RPC, il y a :
• Efficace en cas de nombreux appels.
• Efficace si tout le code et les données ne sont pas visités.
• Résout le problème de l’utilisation des pointeurs (références d’adresses en mémoire).

Les inconvénients

RPC a des inconvénients, on peut citer quelques uns :
• Univers de systèmes homogènes.
• Volume de codes et de données à échanger pages par pages.
• Problèmes de partage selon cohérence de la mémoire répartie.

Motivations: évolution des middlewares – MOM2

Il est fondé sur l’utilisation de messages asynchrones pour faire communiquer les applications Principe :
Les MOM ont deux modes de fonctionnement principaux :
• Point à point: une application produit des messages et une application les consomme. Les messages ne sont lus que par un seul consommateur. Une fois qu’un message est lu, il est retiré de la file d’attente.
• Publish Subscribe (par abonnement) : les applications consommatrices des messages s’abonnent à un topic (sujet, catégorie de messages). Les messages envoyés à ce topic restent dans la file d’attente jusqu’à ce que toutes les applications abonnées aient lu le message.

LES SERVICES WEB

Au sens large, les services web sont des systèmes logiciels, permettant l’interopérabilité entre plusieurs systèmes logiciels (agents) sur un réseau informatique. Plus spécifiquement, lorsque nous utilisons comme base les normes du W3C, l’interface du système est définie par un langage lisible par un ordinateur (WSDL). D’autres système logiciels vont communiquer avec le service Web selon sa description enutilisant le  langage SOAP, généralement en utilisant XML pour sérialiser les messages et HTTP comme protocole réseau. Les Web Services rendent disponibles à plus grande échelle les intergiciels (middleware) traditionnels.

Le concept des web services

Le concept des Web Services s’articule actuellement autour des trois acronymes suivants:
• WSDL : Web Services Definition Language pour la description des Services Web.
• SOAP : Simple Object Access Protocol pour les appels de services à distance par échange de messages XML.
• UDDI : Universal Description, Discovery and Integration, pour le référencement des services

l’intérêt des services web

Les Services Web comportent de nombreux avantages, ils sont utilisables à distance via n’importe quel type de plate-forme, ils peuvent servir au développement d’applications distribuées et sont accessibles depuis n’importe quel type de clients. Les services web appartiennent à des applications capables de collaborer entre elles de manière transparente pour l’utilisateur.

Architecture des Web Services

Jusqu’ici, l’accès via Internet à une ressource applicative ou à une base de données s’effectuait par l’envoi d’une requête s’appuyant sur des langages de script (PHP, JSP,…). Il s’agissait donc d’un dialogue entre une couche de présentation reposant sur HTML (protocole http) et des applications installées sur un serveur distant. Avec les Web Services, un dialogue est désormais instauré entre applications qui peuvent être installées sur des machines distantes, et ceci grâce à des standards XML. En effet, afin de dialoguer via Internet, ces applications doivent « parler » le même langage, langage basé sur le XML. L’architecture de référence des services web se base sur les trois concepts suivants :
• Le fournisseur de service : c’est le propriétaire du service.
• Le client ( ou le consommateur de service ) : c’est un demandeur de service. D’un point de vue technique, il est constitué par l’application qui va rechercher et invoquer un service.
• L’annuaire des services : c’est un registre de descriptions de services offrant des facilités de publication de services à l’intention des fournisseurs ainsi que des facilités de recherche de services à l’intention des clients. Les interactions de base qui existent entre ces trois éléments sont les opérations de publication, de recherche, d’invocation et de lien (bind).

Conclusion générale 

Le travail présenté dans ce mémoire tourne autour des applications service web, l’objectif était de donner une vue générale sur les technologies suivantes : Apache Tomcat et Axis2, en introduisant quelques concepts et notions théoriques relatives à ces dernières. Quelques notions pratiques sont acquises à travers le développement d’une simple application incluant deux parties (client et serveur), dont le client est un administrateur fait la mise à jour de données de taux de change et la conversion de devises ou bien un simple client fait juste la conversion de devises. Le serveur répond aux requêtes de client.

Table des matières

Introduction générale 
Chapitre I: Les middlewares 
I. Introduction
I.1. Historique
II. Evolution des middlewares
II.1. Motivations : évolution des middlewares – RPC
II.1.1.Les avantages
II.1.2. Les inconvénients
II.2. Motivations: évolution des middlewares -MOM
II .2.1. Les avantages
II.2.2. Les inconvénients
II.3. Motivations: évolution des middlewares-CORBA
II.3.1. Les avantages II.3.2. Les inconvénients
II.4. Motivations: évolution des middlewares – RMI
II.4.1. Les avantages
II.4.2. Les inconvénients
II II.5 Motivations: évolution des middlewares – COM/DCOM
II.5.1. Les avantages
II.5.2. Les inconvénients
II.6.Motivations: évolution des middlewares – Composants
II.6.1 Intérêt des composants …
II.7. Motivations : positionnement des services web
II.7.1 Les besoins des entreprises
II.8 Intérêt des services web
III. Conclusion
Chapitre II : Les services web
I. Introduction
II. Définition
III. Le concept des web services
IV. l’intérêt des services web
V. Architecture des Web Services
VI. Les applications des Services web
VII. Protocoles
VII.1. SOAP – Simple Object Access Protocol
VII.1.1. Structure d’un message SOAP
a. Le HTTP Header
b. L’enveloppe SOAP
c. Le header SOAP
d. Le Body SOAP
VII.1.2- SOAP RPC
a. Préambule
b. Requêtes / réponses SOAP
c. La Gestion des erreurs
d. Pattern d’utilisation
VII.2. WSDL – Web Service Description Language
VII.2.1. Structure d’un document WSDL
VII.3. UDDI – Universal Description Discovery and Integration
VII.3.1. Principe
VII.3.2. La recherche d’un Web Service
VII.3.3. La publication d’un Web Service
VIII. Avantages et inconvénients
VIII.1.Avantages
VIII.2.Inconvénients
IX. Conclusion
Chapitre III : La conception et l’implémentation
I. Introduction
II. La Conception de l’application
II.1 Diagramme de cas d’utilisation
II.1.1 la description textuelle
1. Les différents utilisateurs
2. Les fonctionnalités du système
II.2. Les diagrammes de séquence
II.3. le Diagramme de classes
II.4. le Diagramme de déploiement
III. L’implémentation
III.1. Les différents outils utilisés
III.1.1.NetBeans 6.8
III.1.2.Apache Tomcat
III.1.3.Axis2
III.2. l’implémentation côté serveur
III.2.1 le déploiement des services
III.3 l’implémentation côté client
IV. Conclusion
Conclusion générale

Télécharger le rapport complet