Vous êtes sur la page 1sur 73

Module Développement Web

Mlle BAKAEM Mahdia


m_bakalem@inptic.edu.dz
Introduction aux
Web Services
Introduction _ Entreprise
 La création d'applications dans l'entreprise est très souvent pilotée par des besoins à très
court terme.
 Pas de place pour la prise en compte de l'évolution des besoins fonctionnels au niveau de l'application
 Développement d'une application sous tel délai avec telles fonctionnalités
 Les applications sont :
 Plus spécifiques,
 Complexes -> difficulté de maintenance
 Des silos
 Cependant, les entreprises doivent s’adapter en permanence et être de plus en plus réactives
aux variations des marchés. => Ces opérations ont un impact sur le système d’information.
 Les entreprises ont besoin
 intégrer des ressources distribuées disparates;
 profiter des offres des fournisseurs et répondre aux demandes des clients;
 personnaliser pour des situations spéciales;
 interagir sans avoir à échanger des informations détaillées sur leurs interfaces.
 Les solutions à objets distribués ont eu un succès limité en raison (dans une grande mesure) de leur
nature exclusive.
 L'intégration d'applications d'entreprise, l'adaptation automatisée des processus métier et les
interactions B2B restent difficiles.
Modèles d'objets distribués
 DCOM (Microsoft)
 est un protocole qui permet aux composants logiciels de communiquer directement sur
un réseau de manière fiable, sécurisée et efficace.
 Anciennement appelé OLE, DCOM est conçu pour être utilisé sur plusieurs transports de
réseau, y compris les protocoles Internet tels que HTTP.
 RMI (Sun Microsystems)
 est un mécanisme RPC permettant aux programmeurs Java de créer des applications
distribuées, dans lesquelles les méthodes des objets Java distants peuvent être appelées à
partir d'une autre machine virtuelle, éventuellement sur un autre hôte.
 ne fonctionne pas bien avec d’autres langages. La plate-forme J2EE a intégré RMI avec IIOP.
 CORBA (OMG)
 décrit l'architecture d'une plateforme middleware qui prend en charge la mise en œuvre
d'applications dans des environnements distribués et hétérogènes.
 Il est basé sur des normes, indépendant du vendeur et indépendant du langage.
 Contrairement à d'autres plates-formes de middleware telles que DCOM de Microsoft, CORBA est
une spécification qui ne prescrit aucune technologie spécifique.
 CORBA définit des ponts spécifiques entre le langage de définition IDL4 et différents langages de
programmation.
 Très puissant mais limité cependant par sa manière compliquée d’utiliser la puissance et la
flexibilité d’Internet.
Limites des solutions à objets distribués
 Interopérabilité
 Chaque fournisseur avait implémenté son propre format en ligne
pour la messagerie d'objets distribuée.
 Développement d'applications DCOM strictement liées au système
d'exploitation Windows.
 Développement de RMI lié au langage de programmation Java.
 Pare-feu
 La collaboration entre les entreprises était un problème, car les
systèmes distribués tels que CORBA et DCOM utilisaient des ports
non standard.
 Complexité
 La plupart des technologies mentionnées ci-dessus, telles que RMI,
DCOM et CORBA, impliquent toute une courbe d'apprentissage.
Limites des solutions à objets distribués

Problèmes typiques
• Hétérogénéité
plateformes, langages de
programmation…
• Différentes schémas et
formats de données
Motivation

Un silo de données est un référentiel de données fixes maintenu


sous le contrôle d'un service déterminé de l'entreprise, et qui se
trouve isolé du reste de cette dernière
Pourquoi Web services ?
 Interagir des composants hétérogènes, distants, et
indépendants avec un protocole standard
 Intégrer la dimension d'Internet et la standardisation des
échanges.

 Evolution logique des techniques orientées objet vers


l'e-business
 Les services Web ont évolué à partir de technologies
antérieures ayant le même objectif, telles que RPC, ORPC
(DCOM, CORBA et JAVA RMI).
Pourquoi Web services ?
Les services Web visaient à résoudre trois principaux problèmes :
 Interopérabilité
 Permettant l'interopérabilité des applications existantes
 Promouvoir l'interopérabilité en minimisant les exigences en matière de compréhension
partagée
 Modèle de communication commun de programme à programme
 Les services Web sont indépendants de la plateforme et du langage

 Traversée de pare-feu
 Les services Web utilisent HTTP comme protocole de transport et la plupart des pare-feu
autorisent l'accès via le port 80 (HTTP), ce qui permet une collaboration plus facile et
dynamique.
 permettant l'intégration juste à temps
 Les services sont liés de manière dynamique à l'exécution
 Les systèmes sont auto-configurables, adaptatifs et robustes

 Complexité
 Web Services est un système de service convivial pour les développeurs.
 De nouvelles technologies et de nouveaux langages doivent être appris pour mettre en
œuvre ces services
 Réduire la complexité par encapsulation : les applications peuvent être vues comme un ensemble
de services métiers, structurés et correctement décrits, dialoguant selon un standard international
plutôt qu'un ensemble d'objets et de méthodes entremêlés.
 Tous les composants d'une application sont des services
Qu’est ce qu’un service Web?

 Les services Web forment une technologie émergente permettant à des


applications de dialoguer à distance via internet, et ce,
indépendamment des plates-formes sur lesquelles elles reposent.

 Une « unité logique applicative » accessible en utilisant les protocoles standard


d’Internet
 un programme accessible au moyen d'Internet,
 un logiciel qui interagit avec d'autres au moyen de protocoles universels (http, xml...)

 Un moyen d’accéder à un service par l’intermédiaire du Web.


 La capacité pour deux applications d’échanger des informations via le Web.
Qu’est ce qu’un service Web?
 Il faut créer une liaison entre les applications afin qu’elles puissent
échanger des messages.
 L’établissement de cette liaison est de la responsabilité d’un protocole de
communication.
 Les informations véhiculées doivent être respectées un format
précis de façon à pouvoir être interprétées par les divers
participants
 Décrire le format à respecter par les données à échanger,
 Schémas d’encodage commune pour les requêtes et réponses

 Bien définie une méthode pour trouver le service Web ou le


cataloguer en recherchant la disponibilité de tous les web
services souhaité sur le web.
Caractéristiques de Web services
 Accessible à travers les messages XML standardisés,
 typiquement basés sur HTTP
 Décrire utilisant un standard,
 couvre tous les détails nécessaires pour l’invocation de service
 Interface cache les détailles d’implémentation
 Permet d’être utilisé indépendamment de hardware or software platform sur
les quelles sont ils implémentés.
 Indépendamment de :
 la plate-forme (UNIX, Windows,…)
 leur implémentation (Java, C++, Visual Basic,…)
 l’architecture sous-jacente (.NET, J2EE,…)
 ..
 Les Web services sont réutilisable,
Exemple (1)
 Organisation d’un voyage
 Billet d’avion, hôtel, location de voiture, …
 Déclarations administratives

 Solution 1 :
 Recherche personnelle (Internet, téléphone,…)
 Déclaration administrative manuelle
 Solution 2 :
 Agent de voyage
 Réponse généralement unique
 Déclaration administrative manuelle
 Solution 3 :
 Web Services
 Découverte dynamique de partenaire
Exemple (2)
Exemple (3)

 Les services Web lui permettront de lancer un programme qui lui


réservera à la fois un billet d’avion, une location de voiture et une
chambre d’hôtel

 Pour chaque opération, la demande aura été dirigée vers un site


spécialisé

 L’interlocuteur du client reste l’agence de voyage


Exemple service Web
Exemples
 Google API
 Google E.g. Google Maps API -
http://code.google.com/apis/maps/index.html
 Amazon API
 Amazon S3 storage service, catalogue api
http://docs.amazonwebservices.com/AmazonS3/latest/API/
 Flickr http://www.flickr.com/services/api/
 Microsoft Live
 E-bay http://developer.ebay.com/developercenter/soap/
 …
Exemple
Architecture Oriented Services
SOA
Architecture Orientée Services
 Les services Web sont basés sur le modèle architecture
orientée services SOA (WSOA, Web Services Oriented
Architecture.).
 Les services Web sont la réalisation (ou l’instance) la plus
importante d’une architecture SOA.
 SOA est une architecture logicielle s'appuyant sur un
ensemble de services simples. Permettant à des
applications de communiquer sans préoccupation des
technologies d’implantations utilisées de part et d’autre.
 SOA permet aux entreprises de tirer partie des
investissements existants en leur permettant de réutiliser
des applications existantes, en leur offrant une
interopérabilité entre applications et technologies
hétérogènes.
 Repose sur la réorganisation des applications en
ensembles fonctionnels appelés services.
L’objectif d’une architecture SOA
 Décomposer une fonctionnalité en un ensemble de
services et de décrire leurs interactions.
 Ces services peuvent être utilisés par des processus
métier (i.e. services Web composés) ou par des clients
dans différentes applications.
 Un service résout un problème donné
 Les services peuvent être combinés pour résoudre des problèmes plus en plus
complexes
 Au sens SOA, un service est un programme autonome, réutilisable, indépendant
des langages de programmation et qui peut s’exécuter sur n’importe quelle
plateforme.
Les acteurs

 Le Fournisseur : Celui qui fournit le service Web


Le fournisseur de service créé le service Web, puis publie son interface ainsi que
les informations d'accès au service, dans un annuaire de services Web.

 L’annuaire : celui qui détient les informations du service Web.


L'annuaire de service rend disponible l'interface du service ainsi que ses
informations d'accès, pour n'importe quel demandeur potentiel de service.

 Le client : celui qui utilise, invoque le service Web


Le consommateur de service accède à l'annuaire de service pour effectuer une
recherche afin de trouver les services désirés. Ensuite, il se lie au fournisseur
pour invoquer le service.
Les Couches
Le fonctionnement des services web repose sur un modèle en couches, dont les trois couches
fondamentales sont les suivantes :
 Description d’un service
 Objectif est la description des interfaces (paramètres des fonctions, types de données) des
services web.
 Décrire les paramètres d'entrée du service, le format et le type des données retournées.
 Publication et Découverte d’un service
 La publication (advertising) consiste à publier dans un registre les services disponibles aux
utilisateurs.
 La découverte (discovery) des services recouvre la possibilité de rechercher un service
parmi ceux qui ont été publiés décrivant le nom de la société, l'objectif de chaque service,
etc..
 Invocation d’un service
 Représentant la connexion et l'interaction du client avec le service.
 Visant à décrire la structure des messages échangés par les applications.
Fonctionnement
Catégories des services Web

 Les services Web REST (RESTful),


exposent entièrement ces fonctionnalités comme un ensemble
de ressources (URI) identifiables et accessibles par la syntaxe
et la sémantique du protocole HTTP,

 Les services Web SOAP (appelés aussi WS-*),


exposent ces mêmes fonctionnalités sous la forme de services
exécutables à distance.
Spécification de Web services
W3C Conceptual Web services stack
Processes

Base Technologies: XML, DTD, Schema

Base Technologies: XML, DTD, Schema


Discovery, Aggregation, Choreography, …

MANAGEMENT
Descriptions
SECURITY

Web services
Messages Description
(WSDL)
SOAP Extension
Reliability, Correlation, Transaction, …

SOAP
Communications
HTTP, SMTP, FTP, …
IBM Conceptual Web services
stack
Spécification de Web services
Standards de l’architecture

Les standards sont un élément clé d’une SOA, ils assurent


l’interopérabilité

SOAP WSDL UDDI BPEL


W3C W3C Microsoft, IBM, HP Oasis
Simple Object Web Services Universal Description Business Process
Access Protocol Description Language Discovery and Integration Execution Language
Transporte Décrit le contrat Spec pour Décrit les
Repository/Registry processus métier

Les trois piliers des Services Web

L’ensemble des ces technologies se retrouvent dans l’abréviation WS-*.


Standards de l’architecture
 XML – eXtensible Markup Language
 est un langage utilisé pour décrire les messages échangés entre
applications.
 permet une représentation textuelle des données.
 Dans les services Web, c’est plus particulièrement XML-
schema qui est mis en œuvre et qui permet la description des
structures de données en XML.
 HTTP
 est un protocole largement utilisé et mis en œuvre pour le
transport des formulaires de pages HTML.
 Dans le cadre des services Web, il a en charge le transport des
messages échangés.
Principales technologies
Le protocole de communication SOAP

 SOAP : Simple Object Access Protocol


 C’est un protocole basé sur XML
 Il définit les mécanismes d'échanges d'information entre les clients et les
fournisseurs de service Web.
 Les messages SOAP sont susceptibles d'être transportés en HTTP, SMTP, FTP...
 Objectif = formater les requêtes et les réponses échangées entre client et
Service Web pour le transport (notamment sur HTTP)
 Définit principalement
 Un modèle de structure pour les requêtes et les réponses (messages)
 Enveloppe : obligatoire, définit un message SOAP
 Header : optionnel, informations non applicatives (sécurité) ou destinées aux
intermédiaires
 Body : décrit la requête ou la réponse
 Un modèle de traitement des messages
Structure d’un message SOAP
Le message SOAP Complet
SOAP Message Entête standard HTTP
HTTP Headers et entête SOAP HTTP
SOAP Envelope Enveloppe
SOAP Header Entête
Headers Entête individuelle
Corps qui contient les
SOAP Body appels de méthodes SOAP
Method Call & Data
SOAP Fault

37
Exemple : Message SOAP
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding">

<soap:Header>
<!-- en-tête -->
</soap:Header>
<soap:Body>
<!-- corps -->
</soap:Body>
</soap:Envelope>
Transport des messages SOAP avec HTTP
Message SOAP encapsulé dans une
requête HTTP permet au destinataire (le
serveur HTTP) de savoir
POST /Leaderprice HTTP/1.1 qu’il reçoit une requête
Host: www.leaderpriceserver.com SOAP
Content-Type: text/xml; charset= " ISO-8859-1"
Content-Length: nnnn
SoapAction: " www.leaderprice.com/prices"

HTTP
<?xml version="1.0" encoding="utf-8"?>
<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope/"
env:encodingStyle=" http://www.w3.org/2002/06/soap-encoding/"/> Message
SOAP

<env:Body>
<m:GetPrice xmlns:m="www.leaderprice.com/prices">
<m:Item>Apples</m:Item>
</m:GetPrice>
</env:Body>

</env:Envelope>
Message SOAP encapsulé dans une
Réponse HTTP
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=" ISO-8859-1"
Content-Length: nnnn

<?xml version="1.0" encoding="utf-8"?>


<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope/"
env:encodingStyle=" http://www.w3.org/2002/06/soap-encoding/"/>

<env:Body>
<m:GetPriceResponse xmlns:m="www.leaderprice.com/prices">
<Price>1.90</Price>
</m:GetPriceResponse>
</env:Body>

</env:Envelope>

41
Message SOAP encapsulé dans une
Réponse (erreur) HTTP
HTTP/1.1 500 Internal Server Error
Content-Type: application/soap+xml; charset=" ISO-8859-1"
Content-Length: nnnn

<?xml version="1.0" encoding="utf-8"?>


<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope/"
env:encodingStyle=" http://www.w3.org/2002/06/soap-encoding/"/>

<soap:Body>
<soap:Fault>
<faultcode> soap:VersionMismatch </faultcode>
<faultstring> Version Mismatch </faultstring>
</soap:Fault>
</soap:Body>

</env:Envelope>

42
Principales technologies
Le langage de description WSDL
 WSDL : Web Service Description Language
 C’est un langage reposant sur XML dont on se sert pour décrire les services
Web.
 Grammaire dérivée d’XML
 Il est indispensable à UDDI pour permettre aux clients de trouver les méthodes
leur permettant d'invoquer les services web.
 Objectif = décrire l'interface publique d'un Web Service (contrat de
service)
 Interface d’un Web Service avec WSDL
 Web Service = ensemble de ports de connexions mettant à disposition des
opérations qui reçoivent et envoient des messages
 Deux types d’informations
 Fonctionnelles : interface du service (signature des méthodes)
 Techniques : URL, protocole
Que décrit-on ?

 Quelles sont les méthodes disponibles publiquement ?

 Quels sont les types de données utilisés dans les


requêtes et les réponses ?

 Quels sont les protocoles de transport à utiliser ?

 Où est localisé le service ?


Structure WSDL
Document.WSDL

<?xml version="1.0" encoding="utf-8"?>


<definitions>
<types>!--abstract data types</types>
<message>!--message structure</message>
<portType>!--Web Service Interface</portType>
<binding>!--how the service is accessed</binding>
<service>!--who provides the service</service>
</definitions>

48
Principales technologies
L’annuaire des services UDDI

 UDDI : Unversal Discovery Description and Integration


 Standard porté par un consortium d’industriels
 Version 3 en 2005

 Objectif = publication et découverte de Web Services sur
un réseau

 Définit :
 UDDI Business Registry (UBR) = annuaire pour permettre
d'automatiser les communications entre prestataires, clients, etc.
(orienté « business »)
 Méthodes de publications (basées sur SOAP)
 Méthodes de consultation (basées sur SOAP)
Structure des données UDDI

 Qui : Le nom de l’entreprise, les contacts ...

 Quoi : Les classes, les noms des services

 Où : Les adresses d’accès aux services

 Comment : Les informations concernant les


interfaces, les propriétés
Structure UDDI
L’annuaire UDDI est composé de
 Pages blanches (businessEntity)
 Contient des informations sur l’entreprise comme le nom de la
société, l’adresse.
 identité du fournisseur de service.
 Pages jaunes (businessService)
 Contient la description des services web, au format WSDL, déployés
par l’entreprise.
 des critères de catégorisation des services.
 Pages vertes (bindingTemplates)
 Contient les informations techniques détaillées sur les services
fournis (processus métier, description de service…)
 les modes d’exploitation des services
Structure UDDI

54
UDDI, registres
UDDI distingue trois types de registres
Pages Vertes
Pages Jaunes
Pages Blanches i
i Informations
i Catégorisation des techniques sur les
différents services, Services proposés par
Informations sur les basée sur l’utilisation une entreprise
contacts, adresses, de taxinomies particulière
téléphones, etc. standards
Op
Op Connecter
Op Rechercher
Publier Comment une
Comment on peut application va pouvoir
Comment enregistrer trouver un service se connecter et
un nouveau service Web particulier interagir avec un
dans le registre Service Web
Composition des services Web
 La composition de services est un des enjeux principaux
du SOA.
 le couplage faible entre les services,
 l’indépendance par rapport aux aspects technologiques
 et la mise à l’échelle
 Un service Web est composé lorsque son invocation
engendre des interactions avec d’autres services Web.
 Il peut être lui-même composé avec d’autres services existants,
afin de réaliser une tâche plus complexe, ou même de simplifier
le travail lors du développement en utilisant des services déjà
développés.
 Il existe deux stratégies générales pour composer ces
services Web : la chorégraphie et l’orchestration.
Composition des services Web
 - La chorégraphie
 Le flux de travail fournira une chorégraphie pour une interaction
automatique entre les services Web.
 définit la collaboration et les échanges de messages point à point
entre plusieurs partenaires et plusieurs services Web
 propose une vision globale des interactions,
 - L’orchestration,
 définit l’enchaînement des services selon un scénario prédéfini,
 propose une vision centralisée décrivant la manière par laquelle
les services peuvent agir entre eux.
 Actuellement, plusieurs langages ont été proposés pour
composer les services tels que le BPEL, WS-CDL, WSCI,
XLANG,WSFL.
Web Services Composition
 Orchestration: a description of how a
collection of web services work together to
produce an application [ WS]
 Business tasks (operations, exceptions, delays)
 Control flow (ordering, optional, conditionals) [ WS]
 Data
 Composition also enables abstraction
 A flow can be exposed as a complex web service
Sécurité
Il existe quatre exigences de sécurité de base:
 La confidentialité (Confidentiality )
est la propriété que les informations ne sont pas rendues disponibles ou
divulguées à des personnes, entités ou processus non autorisés et garantit que le
contenu du message n'est pas divulgué à des personnes non autorisées.
 L'autorisation (Authorization)
est l'octroi de l'autorité, ce qui inclut l'octroi d'un accès basé sur des droits
d'accès et garantit que l'expéditeur est autorisé à envoyer un message.
 L'intégrité des données (Data integrity )
est la propriété que les données n'ont pas été altérées ou détruites de manière
indétectable de manière non autorisée ou par des utilisateurs non autorisés,
assurant ainsi que le message n'a pas été modifié accidentellement ou
délibérément en transit.
 La preuve d'origine (Proof of origin )
est une preuve identifiant l'expéditeur d'un message ou de données. Il affirme
que le message a été transmis par un expéditeur correctement identifié et qu'il
ne s'agit pas d'une retransmission d'un message transmis précédemment. Cette
exigence implique l'intégrité des données
Gestion
 Dans ce cas, la gestion signifie qu'une application de gestion
peut découvrir
 l'existence,
 la disponibilité
 et l’état de l'infrastructure de services Web, des services Web et des
registres de services.
 Il doit être possible de gérer des services Web à tous les
niveaux de la pile conceptuels de services Web.
 Les interfaces de gestion doivent fonctionner au niveau du
service et non au niveau relativement bas de l'infrastructure.
 Rapport de base sur la disponibilité de l'infrastructure de services
Web
 Informations sur les performances, la disponibilité et les événements
des services Web
Qualité de service
 Au niveau de la messagerie XML
 Messagerie fiable: capacité d'une infrastructure à transmettre un
message une fois, et une seule fois, à la cible visée ou à fournir un
événement défini, éventuellement à la source, si la livraison ne peut
pas être effectuée
 Au niveau de description du service
 Durée maximale après que le demandeur s'attend à ce que le
fournisseur réponde
 Au niveau de composition de service ou niveau de flux de
service
 Temps d'exécution prévu, valeurs de délai d'attente,…

Les problèmes de qualité de service et les solutions pour les


services Web émergent encore
Scenario complet

au Client
caractéristiques
Implémentation service Web
Coté fournisseur
Coté client
Développement de Web services
 Le développement et le déploiement de services Web ne
nécessitent pas une technologie particulière dans la plate-
forme sous-jacente
 Un éditeur de texte commun peut être utilisé pour
développer des services Web
 Il existe plusieurs outils de développement permettant de
développer facilement des services Web.
 Microsoft Visual Studio .NET
 Sun ONE Studio
 IBM WebSphere Studio ou Eclipse IDE avec WSDK
 …
Web services with Microsoft .NET
 You have to
 Access to Internet Information Services (IIS)
 In a local or remote machine
 A server for web applications/services
 The service repository of one or more service providers
 Create a Web service project in Microsoft Visual Studio
.NET
 A Web service is composed by classes
 Usage of keyword WebMethod for the public methods invocable from
the Internet
Web services in Microsoft Visual Studio
.NET
Merci

Vous aimerez peut-être aussi