STANDARDS ET PROTOCOLES DES SERVICES WEB

STANDARDS ET PROTOCOLES DES SERVICES WEB

Il existe aujourd’hui un certain nombre de plates-formes pour créer des applications. Chacune d’entre elles utilise généralement ses propres protocoles, le plus souvent de type binaire, pour l’intégration de machine à machine. En conséquence, les applications fonctionnant sur des plates-formes différentes n’ont qu’une faible capacité de partage de données. La prise de conscience de ces limites a entraîné un gros effort de standardisation des formats de données et d’échange de données. En effet, les regards se tournent de plus en plus vers un nouveau paradigme informatique : une intégration transparente des services Web qui dépasse les barrières logicielles et matérielles traditionnelles.

Au cœur de cette vision se trouve le concept d’interopérabilité, c’est-à-dire la capacité pour des systèmes disparates de communiquer et de partager des données de façon transparente. C’est l’objectif des services Web. Un service Web est une logique d’application programmable accessible à l’aide des protocoles Internet standard, que l’on peut aussi décrire comme l’implémentation de standards Web pour une communication transparente entre les machines et entre les applications.

Un certain nombre de technologies des services Web, telles que le protocole SOAP (Simple Object Access Protocol), le langage WSDL (Web Service Description Language) et le protocole HTTP (HyperText Transfer Protocol), sont actuellement utilisées pour transférer les messages entre les machines. La complexité de ces messages est très variable, pouvant aller de l’appel de méthode à la soumission d’un bon de commande. Une fonction courante – de niveau plus élevé – d’un service Web consiste à implémenter la communication de type RPC (Remote Procedure Call, appel de procédure à distance permettant à un programme sur un ordinateur d’exécuter un programme sur un autre ordinateur). Ce mémoire présente une introduction pratique aux questions courantes d’interopérabilité, notamment celles relatives à la communication de type RPC utilisant le protocole SOAP.

MIDDLEWARE

En architecture informatique, un middleware (anglicisme) est un logiciel tiers qui crée un réseau d’échange d’informations entre différentes applications informatiques. Le réseau est mis en œuvre par l’utilisation d’une même technique d’échange d’informations dans toutes les applications impliquées à l’aide de composants logiciels.

Définition

Un middleware(en français intergiciel) est un logiciel de connexion qui se compose d’un ensemble de service et/ou de milieu De développement d’applications distribués qui permettent à plusieurs entités (processus, Objet,…etc..) résidents sur un ou plusieurs ordinateurs, d’interagir a travers un réseau d’interconnexion en dépit des différences dans les protocoles de communication, architecture des systèmes locaux, systèmes opérationnels etc… .

Les systèmes distribués 

Définition
Un système distribué est une collection de postes qui sont connectés à l’aide d’un réseau de communication.

Chaque poste exécute des composantes et utilise un intergiciel qui s’occupe d’activer les composantes et de coordonner leurs activités de telle sorte qu’un utilisateur perçoive le système comme un unique système intégré.

L’évolution des middlewares

RPC (Remote Procedure Call) 

Définition
Un appel aux procédures distant, RPC transforme l’interaction client / serveur dans un appel à la procédure, semblable à celle locale, en cachant au programmateur la plus grande partie des mécanismes implémentées qui la composent, comme :
◆L’échange de message
◆La localisation du serveur qui fournit le service
◆Les différentes représentations possibles des données des machines impliquées dans l’interaction .

Ce déguisement arrive en quatre phases :

◆A temps d’écriture du code. Les RPC employés/ fournis devront être déclarée par le programmateur explicitement à travers l’import / export des définitions des interfaces
◆A temps d’exécution. chaque machine sur laquelle il est en exécution un programme client et / ou serveur devra avoir un support à temps d’exécution pour les RPC, RPC run-time support, apte à exécuter quelques opération des RPC comme par exemple la localisation de serveur ou l’enregistrement d’un nouveau service offert par un nouveau serveur
◆A temps de compilation. Pendant la compilation pour chaque appelle à la procédure distante, des lignes de code sont accrochées au programme originaire (stub). Ces lignes permettent des opérations standards sur les données (empaquetage et codage reconnue universellement) et les appelles au RPC run-time support
◆A temps de liaison. Pendant la liaison le programme source est mis en communication avec les RPC run-time support pour obtenir le code exécutable.

CORBA 

Définition
CORBA ou Common Object Request Broker Architecture est né dans les années 1990 du besoin de faire communiquer ensemble des applications en environnement hétérogène (plusieurs systèmes et plusieurs langages).

CORBA n’est qu’un sous ensemble du projet ODP-RM ou Open Distributed Processing Reference Model vise à mettre en place une norme d’architectures distribuées ouvertes.

L’ OMG (Object Management Group), créé en 1989 et regroupant plus de 750 membres (vendeurs de logiciels, développeurs et utilisateurs), collabore avec l’ODP pour la mise en place d’une norme sur le middleware, et a créé à cet effet la norme CORBA. .

Les composantes

Le bus CORBA fournit les composantes suivantes :

◆ ORB (Object Request Broker) : est le noyau de transport des requêtes aux objets. Il intègre au minimum les protocoles GIOP et IIOP. L’interface au bus fournit les primitives de base comme l’initialisation de l’ORB.
◆ SII (Static Invocation Interface) : est l’interface d’invocations statiques permettant de soumettre des requêtes contrôlées à la compilation des programmes. Cette interface est générée à partir de définitions OMG-IDL.
◆ DII (Dynamic Invocation Interface) : est l’interface d’invocations dynamiques permettant de construire dynamiquement des requêtes vers n’importe quel objet CORBA sans générer/utiliser une interface SII.
◆ IFR (Interface Repository) : est le référentiel des interfaces contenant une représentation des interfaces OMGIDL accessible par les applications durant l’exécution.
◆ SSI (Skelton Static Interface) : est l’interface de squelettes statiques qui permet à l’implantation des objets de recevoir les requêtes leur étant destinées. Cette interface est générée comme l’interface SII.
◆ DSI (Dynamic Skeleton Interface) : est l’interface de squelettes dynamiques qui permet d’intercepter dynamiquement toute requête sans générer une interface SSI. C’est le pendant de DII pour un serveur.
◆ OA (Object Adapter) : est l’adaptateur d’objets qui s’occupe de créer les objets CORBA, de maintenir les associations entre objets CORBA et implantations et de réaliser l’activation automatique si nécessaire.
◆ ImplR (Implementation Repository) : est le référentiel des implantations qui contient l’information nécessaire à l’activation. Ce référentiel est spécifique à chaque produit CORBA.

Le langage OMG-IDL 

Le langage OMG-IDL est la base de la force de CORBA. Il a été créé pour rendre compatible l’utilisation de plusieurs applications écrites dans différents langages de programmation, ceci s’appelle l’interopérabilité. Il cherche à masquer l’hétérogénéité des applications. Pour ceci, il a été défini pour décrire uniquement les interfaces indépendamment du langage d’implantation.

RMI 

RMI (Remote Method Invocation) est une API java permettant de manipuler des objets distants (un objet instancié sur une autre machine virtuelle (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 de la machine locale. Ainsi un serveur permet à un client d’invoquer des méthodes à distance sur un objet qu’il instancie. Deux machines virtuelles sont donc nécessaire (une sur le client et l’autre sur le serveur) et l’ensemble des communications se fait en java.

DCOM

DCOM (Distributed Component Object Model) le système d’objets distribués de Microsoft. 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. 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 DCOM et de l’Automation à 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.

Le middleware est au cœur de toute solution de traçabilité. Il joue le rôle d’intermédiaire et d’interprète entre la couche métier et la couche matériel de la solution de traçabilité. Ces deux couches sont en effet gérées de manière bien différente : l’une relève du domaine de l’informatique de gestion, utilisant des données « métier », l’autre, de l’informatique industrielle, traitant des données « terrain » en provenance de différents capteurs.

CONCLUSION GENERALE 

En conclusion, il est nécessaire de faire le point sur la technologie des services Web. Les services Web est un terme qui décrit un ensemble de protocoles standards utilisés pour établir un domaine d’intégration des applications.

L’un des facteurs ayant contribué au succès des services Web est sans doute l’utilisation des standards Internet tels que XML et HTTP. En conséquence, tout système capable d’analyser du texte et de communiquer via un protocole de transport Internet standard peut communiquer avec un service Web. XML a engendré l’apparition de nouveaux protocoles tels que SOAP pour l’échange de messages, WSDL pour la description de services et UDDI pour la publication et la découverte de services.

Notre application concerne la réservation d’un biais : tout d’abord le passager va chercher des vols disponibles, ensuite il choisie le vol qui correspond à ses besoins et remplir ses informations (nom, prénom, email,…), il doit préciser le mode de paiement convenable. Si tout passe bien alors votre réservation est valide et maintenant je vous souhaite un bon voyage.

Table des matières

INTRODUCTION GENERALE
CHAPITRE I: MIDDLEWARE
1 INTRODUCTION
2 DEFINITION
3 LES SYSTEMES DISTRIBUES
3.1 DEFINITION
3.2 LE MODELE CLIENT / SERVEUR
3.2.1 Définition
3.3 LES ARCHITECTURES BASEE SUR LE MODELE CLIENT / SERVEUR
3.3.1 L’architecture 1 tiers
3.3.2 L’architecture 2 tiers
3.3.3 L’architecture 3 tiers
3.3.4 L’architecture n-tiers
4 L’EVOLUTION DES MIDDLEWARES
4.1 RPC (REMOTE PROCEDURE CALL)
4.1.1 Définition
4.2 CORBA
4.2.1 Définition
4.2.2 Le bus d’objets répartis (ORB)
4.2.3 Les composantes
4.2.4 Le langage OMG-IDL
4.3 RMI
4.4 DCOM
5 CONCLUSION
CHAPITRE II : LE LANGAGE XML
1 INTRODUCTION
2 QU’EST CE QUE XML ?
3 LA SYNTAXE XML
4 STRUCTURE D’UN DOCUMENT XML
5 ESPACE DE NOMMAGE (SPACENAME)
6 GRAMMAIRE XML
6.1 DTD (DOCUMENT TYPE DEFINITION)
6.1.1 Definition
6.1.2 Déclarer un élément
6.1.3 Déclarer des attributs
6.1.4 Les limites des DTD
6.2 LES SCHEMAS XML
7 MANIPULATION DES DOCUMENTS XML
7.1 L’ANALYSEUR XML
7.2 DOM (DOCUMENT OBJECT MODEL)
7.3 SAX(SIMPLE API FOR XML) :
7.4 COMPARAISON ENTRE DOM ET SAX
8 CONCLUSION
CHAPITRE III: LES SERVICES WEB
1 INTRODUCTION
2 DEFINITION D’UN SERVICE WEB
3 CARACTERISTIQUE D’UN SERVICE WEB
3.1 WEB BASED
3.2 SELF-DESCRIBED, SELF-CONTAINED
3.3 MODULAR
4 ARCHITECTURE DES WEB SERVICES
5 STANDARDS ET PROTOCOLES DES SERVICES WEB
6 LA PILE DE PROTOCOLE DES SERVICES WEB
6.1 LE PROTOCOLE HTTP
6.2 LE PROTOCOLE SOAP (SIMPLE OBJECT ACCESS PROTOCOL)
6.2.1 Structure d’un message SOAP
6.3 WSDL (WEB SERVICES DESCRIPTION LANGUAGE)
6.3.1 STRUCTURE D’UN DOCUMENT WSDL
6.4 UDDI (UNIVERSAL DESCRIPTION, DISCOVERY AND INTEGRATION)
6.4.1 LA STRUCTURE D’UN UDDI
7 CONCLUSION
CHAPITRE IV : LA CONCEPTION ET REALISATION DE L’APPLCATION
1 INTRODUCTION :
1.1 LES DIAGRAMMES EN UML
1.1.1 LES DIAGRAMMES STATIQUES
1.1.2 LES DIAGRAMMES DYNAMIQUES :
1.2 MODELISATION DE L’APPLICATION
1.2.1 DIAGRAMME CAS D’UTILISATION :
1.2.2 DIAGRAMME DES CLASSES :
1.2.3 DIAGRAMME DE SEQUENCE :
2 IMPLEMENTATION
2.1 ÉCLIPSE
2.1.1 Apache Tomcat
2.1.2 Apache Axis
2.1.3 JDK
2.2 MS ACESS
2.3 VISUAL STUDIO (.NET)
3 REALISATION DE L’APPLICATION
3.1 PARTIE SERVICE WEB
3.2 PARTIE CLIENT
CONCLUSION GENERAL

Télécharger le rapport complet