SlideShare une entreprise Scribd logo
1
Architectures réparties
Présenté par : EL HACHIMI CHOUAIB
Cours Web service et sémantique: Pr. J. EL KAFI.
Définitions
Dans le cadre des architectures réparties, on distingue :
• Les architectures centralisées (type client-serveur)
• Les architectures distribuées (Peer to Peer)
La différence fondamentale entre ces deux type d’architecture se situe dans
la distribution des rôles entre les nœuds du réseau :
• On parle d’architecture centralisée car les nœuds jouant le rôle de serveur
centralisent une grande partie de l’information et des communications (ex.
n clients pour 1 serveur) et sont distincts des nœuds clients.
• A contrario, dans les architectures distribuées, tous les nœuds du réseau
partagent théoriquement les mêmes rôles : ils sont simultanément clients
et serveurs et disposent de tout ou partie de l’information répartie.
Architectures centralisées
Définition
• Le client-serveur est un type d’architecture qui effectue une distinction stricte
entre les rôles de client d’une part et de serveur d’autre part.
• On peut l'interpréter d’un point de vue matériel (des machines clientes et
des machines serveurs) ou logiciel (entités clientes et entités serveurs d’une
même application).
• Les interprétations matérielles et logicielles sont souvent liées: une
application client-serveur est communément répartie sur plusieurs machines
connectées par un réseau.
• Mode de fonctionnement général :
1. Point de vue client: un client effectue une requête pour un service précis
sur un serveur donné et reçoit une réponse.
2. Point de vue serveur: un serveur reçoit une demande de service, la traite,
et renvoie la réponse au client.
Caractéristiques générales client
• Il est actif (ou maître).
• Il envoie des requêtes au(x) serveur(s).
• Il attend (pas forcement) et reçoit les réponses du/des serveur(s).
• Il ne peut être connecté qu’à un petit nombre de serveurs en même temps.
• Il interagit généralement directement avec un utilisateur final en utilisant une
IHM.
Caractéristiques générales serveur
• Il est passif (ou esclave).
• Il est à l'écoute, prêt à répondre aux requêtes envoyées par plusieurs
clients.
• Dès qu'une requête lui parvient, il la traite et envoie une réponse.
• Il accepte normalement un nombre important de connections de la part des
clients.
• Il n'interagit pas directement avec les utilisateurs finaux.
Exemples
• La consultation de pages web fonctionne sur une architecture client/
serveur. Un internaute connecté au réseau via son ordinateur et un navigateur
Web est le client, le serveur est constitué par le ou les ordinateurs contenant
les applications qui délivrent les pages demandées. Dans ce cas, c'est le
protocole de communication HTTP qui est utilisé.
• Les emails sont envoyés et reçus par des clients et gérés par un serveur de
messagerie. Les protocoles utilisés sont le SMTP, et le POP ou l'IMAP.
• La gestion d'une base de données centralisée sur un serveur peut se faire
à partir de plusieurs postes clients qui permettent de visualiser et saisir des
données.
• Le système X Window (*nix) fonctionne sur une architecture client/serveur.
En général le client tourne sur la même machine que le serveur, mais peut être
aussi bien lancé sur un autre ordinateur faisant partie du réseau.
Exemples: le web
• A ne pas confondre avec “internet”, le web est un de ses services constitutifs
et historique dans le but est d’afficher de l’information sous forme de pages navigables
par des hyperliens.
• Le web repose sur un protocole client/serveur: HTTP
• Client : le navigateur (Firefox, Explorer, Opéra, Safari,...) va émettre une
requête
• Serveur : le serveur Web (Apache, IIS,...) répond en fournissant le
document demandé ou un message d’erreur si le document n’existe pas
Couches fonctionnelles
Toute application client-serveur est composée de 3 couches fonctionnelles:
Couches fonctionnelles
• Présentation : correspondant à l'affichage, la restitution sur le poste de
travail, le dialogue avec l'utilisateur (= interface utilisateur, IHM …).
• Traitements métiers : correspondant à la mise en œuvre de l'ensemble
des règles de gestion et de la logique applicative.
• Persistance de données: correspondant aux données qui sont destinées
à être conservées sur la durée, voire de manière définitive.
 C’est la répartition de ces couches entre les rôles de clients et serveurs qui
permet de distinguer entre les différents types d’architectures client-serveur.
Combinaisons
Couche Présentation
• Elle correspond à la partie de l'application visible et interactive avec les
utilisateurs. On parle d'Interface Homme Machine.
• On conçoit facilement que cette interface peut prendre de multiples facettes
sans changer la finalité de l'application. Dans le cas d'un système de
distributeurs de billets, l'automate peut être différent d'une banque à l'autre,
mais les fonctionnalités offertes sont similaires et les services identiques
(fournir des billets, donner un extrait de compte, etc.).
• La couche présentation relaie les requêtes de l'utilisateur à destination de la
couche métier, et en retour lui présente les informations renvoyées par les
traitements de cette couche. Il s'agit donc ici d'un assemblage de services
métiers et applicatifs offerts par la couche inférieure.
Couche Traitements métiers
• Elle correspond à la partie fonctionnelle de l'application, celle qui implémente
la logique, et qui décrit les opérations que l'application opère sur les
données en fonction des requêtes des utilisateurs, effectuées au travers de la
couche présentation.
• Les différentes règles de gestion et de contrôle du système sont mises en
œuvre dans cette couche.
• La couche métier offre des services applicatifs et métiers à la couche
présentation. Pour fournir ces services, elle s'appuie, sur les données du
système, accessibles au travers des services de la couche inférieure. En
retour, elle renvoie à la couche présentation les résultats qu'elle a calculés.
Couche Persistance de données
Elle consiste en la partie gérant l'accès aux sources de données du système.
Ces données peuvent être propres au système, ou gérées par un autre
système. La couche métier n'a pas à s'adapter à ces deux cas, ils sont
transparents pour elle, et elle accède aux données de manière uniforme.
• Données propres au système: ces données sont pérennes, car destinées
à durer dans le temps, de manière plus ou moins longue, voire définitive.
Elles peuvent être stockées indifféremment dans de simples fichiers texte,
XML, ou encore dans une base de données.
• Données gérées par un autre système: elles ne sont pas stockées par
le système considéré, il s'appuie sur la capacité d'un autre système à
fournir ces informations.
 Par exemple, une application de pilotage de l'entreprise peut ne pas
sauvegarder des données comptables de haut niveau dont elle a besoin,
mais les demander à une application de comptabilité indépendante et préexistante.
2-tiers
• C’est le type d’architecture client-serveur le plus basique :
• La couche présentation est située sur le client
• La couche donnée est située sur le serveur (par ex. une base de données
relationnelles SQL, Oracle,...)
• La couche traitement peut être située sur le client (au sein même de l’IHM),
le serveur (par ex. des procédures stockées sur la base de données), ou
partagée entre les deux rôles.
• Il y a une relation directe entre les clients et les serveurs de données.
• (+) simple à mettre en œuvre
• (-) peu flexible et supporte difficilement la montée en charge
• (-) souvent des solutions propriétaires, économiquement très couteux
2-tiers
3-tiers
• L’architecture 3-tiers est une extension du modèle client-serveur qui introduit
un rôle spécifique pour la couche de traitements métiers.
• Il y a donc décomposition d’un même service sur 2 types de serveurs:
• Un type de serveur dédié à la gestion des traitements métiers.
• Un type de serveur dédié à la gestion des données persistantes.
• (+) plus évolutif que le 2-tiers
• (+) meilleure répartition des charges de travail coté serveur
• (+) économiquement moins cher, surtout lors de la montée en charge
• (-) administration et mise en œuvre plus compliquée que le 2-tiers
3-tiers
n-tiers
• Généralisation de l’architecture 3-tiers
• La couche serveur peut être divisée en autant de sous-rôles que voulus
• Sensiblement les mêmes avantages et inconvénients que la couche 3-tiers.
n-tiers
Architectures distribuées
Définitions
• Dans les architectures distribuées les nœuds du réseau sont en relation
d’égal à égal.
• Les caractéristique habituelles de ces architectures sont les suivantes :
• Pas de connaissance globale du réseau.
• Pas de coordination globale des nœuds.
• Chaque nœud ne connaît que les nœuds constituant son voisinage.
• Toutes les données sont accessibles à partir de n’importe quel nœud.
• Les nœuds sont très volatiles (ils peuvent disparaître ou apparaître à tout
moment).
Architectures distribuées
• Les technologies Peer-to-Peer (P2P, ou Pair-à-Pair) constituent le pendant
technologique des architectures distribuées.
• La parfaite homogénéité des rôles vue précédemment correspond rarement à
la réalité des réseau P2P déployés de part le monde. De ce fait, on procède à
leur classification en différentes grandes familles .
Architectures distribuées
• P2P “pur” (par ex. Gnutella) :
• Respecte les caractéristiques précédentes :
• Les pairs sont égaux et fusionnent les rôles de client et de serveur.
• P2P hybride (par ex. Napster) :
• Données distribuées mais index centralisé :
• On dispose d’un serveur central qui conserve des informations sur les
pairs et peut répondre à des requêtes sur cette information (il joue
souvent le rôle d’un annuaire de clients et de fichiers).
• Les pairs sont responsables de l’hébergement des ressources
partagées mais doivent indiquer leur disponibilité au serveur central.
• Il n’y a pas de serveur central pour gérer le réseau.
• Il n’y a pas de routeur central.
Architectures distribuées
• P2P Structuré (Chord, P-Grid, CAN, …) :
• Index distribué et stocké par DHT (Distributed Hash Tables).
• P2P Hiérarchique (Super-Peer, Kazaa,…) :
• Couplage entre les architectures Client-Serveur et le P2P.
• P2P Sémantique (SON, Routing Indices, …) :
• P2P Pur avec routage enrichit de critères sémantiques.
Avantages - Inconvénients
• Avantages :
• Tous les pairs fournissent des ressources (bande passante, stockage,
puissance de calcul,...). On obtient ainsi des architectures qui
Supportent beaucoup mieux la montée en charge (“scalability”) que les
architectures centralisées.
• La distribution augmente la robustesse du réseau dans le cas d’une panne
par la réplication des données sur plusieurs pairs. Et, dans le cas d’un P2P
pur, il n’y pas de point central de vulnérabilité (l’annuaire).
• Inconvénients :
• Mauvaise réputation du “P2P”, invariablement associé au téléchargement
musical → faible adoption par l’industrie.
• Les architectures distribuées amènent leur lot de problématiques
spécifiques (concurrence entre les pairs, fragmentation des données, ...).
• Elles ne permettent pas un contrôle avancé des échanges d’information
entre les pairs (inconvénient ou avantage ?).
Les Services Web
Dans une agence de voyage, un produit « voyage » est en réalité une combinaison de
plusieurs produits :
• Gestion de réservation des billets de transport
• Gestion de réservation des hôtels
• Gestion de réservation des voitures de location
• ...
L'élaboration d'un produit « voyage » est bien le résultat d'informations récupérées
auprès de différents fournisseurs :
• Compagnies aériennes
• Chaînes hôtelières
• Loueurs de véhicules
• ...
Définitions
Définitions
 Sur le schéma précédent, l'application consultée par le client met en œuvre des
applications réparties pour satisfaire sa demande.
Dans cette mise en œuvre applicative, on parle:
• De transformation, lorsqu'il s'agit d'adapter le dialogue en fonction du profil
utilisateur.
• D'agrégation, lorsqu'il s'agit de faire appel à des applications proposées par des
partenaires ou fournisseurs
 Que ce soit de l'agrégation ou de la transformation d'informations˛ les applications
réalisant ces tâches de façon complètement automatique et opaque s'appellent
des « services web ».
Définition
 Une application web communicante résulte alors d'un assemblage de services web.
 Certains sont internes et d'autres externes et fournis par divers partenaires et
fournisseurs.
 Les deux extrémités de cet assemblage sont :
• Le tout interne : entièrement composé de services internes˛ on parle alors
d'intégration d'applications d'entreprise.
• Le tout externe : entièrement composé de services externes, on parle alors de
portail d'entreprises.
Les Services Web, c'est quoi ?
 C'est la possibilité d'invoquer une fonction distante. En l'occurrence, sur un serveur
web distant puisque le protocole de base est HTTP .
 On dispose d'une infrastructure souple basée sur XML pour les systèmes distribués
hétérogènes.
Les Services Web, c'est quoi ?
 Ils sont accessibles via le web par des protocoles bien connus
 Ils sont décrits à partir de XML
 Ils interagissent via XML
 Ils sont localisables à partir de registres
 Ils sont entièrement transversaux aux plates-formes et très faiblement couplés
Les Services Web, c'est quoi ?
 Ils introduisent un nouveau modèle de développement basé sur ce que l'on appelle les
architectures orientées services (très pratique pour B2B)
 Une architecture orientée services se focalise sur une décomposition plus abstraite
dans la résolution des problèmes. On parle de résolution dirigée par les services.
 Un service résout un problème donné
 Les services peuvent être combinés pour résoudre des problèmes de plus en plus
complexes .
Les Services Web, c'est quoi ?
Les tâches associées à la manipulation des services web sont :
 Interroger un annuaire : qui fournit des choses dont on ne connaît pas forcément
la nature, le rôle ou le contenu .
• Nature exacte du service fourni
• Qualité/coût/etc.
 Interagir avec le service du fournisseur choisi pour :
• Connaître les modalités d'interaction
• Introduire le service dans ma chaîne de traitements
 Eventuellement composer des services
 Eventuellement publier mes propres services
 Négocier avec les fournisseurs potentiels de ces choses pour connaître :
Les Services Web, c'est quoi ?
 L'avantage essentiel des services web concerne le fait que le client consommateur n'a
pas besoin de connaître l'identité du fournisseur du service.
 Le client doit simplement exprimer son besoin.
 Face à un besoin, plusieurs fournisseurs de services peuvent exister
 Chacun ayant des caractéristiques de coût, de performance, de fiabilité, etc.
 Le client choisit le fournisseur (i.e. le service) correspondant le mieux à ses besoins.
Les Services Web, pourquoi ?
 Lorsque l'on a besoin d'interopérabilité dans des environnements applicatifs distribués
 Les services peuvent communiquer entre eux, et cela depuis des environnements
applicatifs distants
 Lorsque l'on veut accéder aux applications à travers les pare-feu
 Les services web sont définis et accédés avec XML sur des protocoles standards
comme HTTP et SMTP. Ils peuvent alors être invoqués à travers un pare-feu.
 Lorsque l'on veut profiter de différents environnements et langages de
développement
 Par une description et une invocation XML, les services web sont très flexibles et
indépendants des langages et des systèmes.
Les usages
 Les services web pour représenter des applications sophistiquées bien délimitées et
sans forte interactivité.
 Par exemple, une application qui donne les conditions du temps peut être idéalement
représentée par un service.
 Les services web sont adaptés pour l'assemblage de composants faiblement couplés.
 Ils sont définis de façon indépendante, mais peuvent interagir.
 Les services web sont adaptés à la représentation d'application orientées messages.
 Les mécanismes d'invocation asynchrone des applications orientées messages sont en
font de bonnes candidates aux services web.
Les acteurs (rôles)
Les principaux acteurs dans la technologie des services web sont :
 Le client : celui qui utilise, invoque le service web
 Le fournisseur : celui qui fournit le service web
 L'annuaire : celui qui détient les informations du service web
Les acteurs (rôles)
 Le client et le fournisseur sont les éléments principaux dans l'architecture des services
web
 Un fournisseur est représenté par un serveur d'application (J2EE par exemple)
 Le fournisseur détient un ou plusieurs services qui sont représentés par des EJBs ou
des servlets et qui sont enveloppés d'une couche « service »
 Le fournisseur peut être le client d'un autre fournisseur (interopérabilité)
 Une fois le service définit, il peut être déclaré dans un annuaire, on parle alors de
publication du service afin de le rendre accessible aux clients.
Scénario complet
Etape 1 : définition, description du service
• On doit décrire d'un point de vue informatique ce que fait le service, la solution
qu'il propose, ...
• La définition est faite en WSDL au sein du fournisseur de services (i.e. le serveur
d'applications)
Etape 2 : publication du service
• Une fois le service définit et décrit en termes de mise en œuvre, il peut être
déclaré dans un annuaire, on parle alors de publication du service afin de le
rendre accessible aux clients.
• Comme on le verra, la publication sera effectué au sein d'un annuaire dédié
UDDI.
Etape 3 : recherche du service
• Le client se connecte, sur un annuaire (UDDI) pour effectuer une recherche de
service.
Scénario complet
Etape 4 : enregistrement au service web
• Une fois le service trouvé par le client˛ ce dernier doit s'enregistrer auprès du
fournisseur associé au service.
• Cet enregistrement indique au fournisseur l'intention du client d'utiliser le service
suivant les conditions décrites dans la publication.
Etape 5 : mise en œuvre du service
• Le client peut invoquer le service suivant les conditions inscrites au sein de
l'annuaire lors de la publication du service web (étape 2)
Etape 6 : composition
• C'est la possibilité de combiner plusieurs services. En fait, un service peut devenir
le client d'un autre service.
Scénario complet
Scénario complet
Conclusion et Initiation
L'architecture des Web Services repose essentiellement sur les technologies suivantes :
• XML (Extensible Markup Language).
• SOAP (Simple Object Access Protocol ) Protocole pour la communication entre les
Services Web.
• WSDL (Web Service Description Language) Langage de description de l'interface
du Web.
• UDDI (Universal Description˛ Discovery and Integration) Annuaire pour le
référencement du Web Service.
Et qui sont les sujets des présentation suivantes.
Merci de votre
attention?
45

Contenu connexe

Tendances

Support JEE Servlet Jsp MVC M.Youssfi
Support JEE Servlet Jsp MVC M.YoussfiSupport JEE Servlet Jsp MVC M.Youssfi
Support JEE Servlet Jsp MVC M.Youssfi
ENSET, Université Hassan II Casablanca
 
Appalications JEE avec Servlet/JSP
Appalications JEE avec Servlet/JSPAppalications JEE avec Servlet/JSP
Appalications JEE avec Servlet/JSP
Youness Boukouchi
 
BigData_TP3 : Spark
BigData_TP3 : SparkBigData_TP3 : Spark
BigData_TP3 : Spark
Lilia Sfaxi
 
Sécurité des Applications Web avec Json Web Token (JWT)
Sécurité des Applications Web avec Json Web Token (JWT)Sécurité des Applications Web avec Json Web Token (JWT)
Sécurité des Applications Web avec Json Web Token (JWT)
ENSET, Université Hassan II Casablanca
 
diagramme de séquence UML
diagramme de séquence UMLdiagramme de séquence UML
diagramme de séquence UML
Amir Souissi
 
Support de cours angular
Support de cours angularSupport de cours angular
Support de cours angular
ENSET, Université Hassan II Casablanca
 
Développement d'un site web de E-Commerce avec PHP (Première Partie)
Développement d'un site web de E-Commerce avec PHP (Première Partie)Développement d'un site web de E-Commerce avec PHP (Première Partie)
Développement d'un site web de E-Commerce avec PHP (Première Partie)
ENSET, Université Hassan II Casablanca
 
BigData_Chp2: Hadoop & Map-Reduce
BigData_Chp2: Hadoop & Map-ReduceBigData_Chp2: Hadoop & Map-Reduce
BigData_Chp2: Hadoop & Map-Reduce
Lilia Sfaxi
 
Tp2 - WS avec JAXRS
Tp2 - WS avec JAXRSTp2 - WS avec JAXRS
Tp2 - WS avec JAXRS
Lilia Sfaxi
 
eServices-Tp1: Web Services
eServices-Tp1: Web ServiceseServices-Tp1: Web Services
eServices-Tp1: Web Services
Lilia Sfaxi
 
Chp1- Introduction aux Technologies Web et SOA
Chp1- Introduction aux Technologies Web et SOAChp1- Introduction aux Technologies Web et SOA
Chp1- Introduction aux Technologies Web et SOA
Lilia Sfaxi
 
Exercices uml-corrige
Exercices uml-corrigeExercices uml-corrige
Exercices uml-corrige
AmineMouhout1
 
Support de cours EJB 3 version complète Par Mr Youssfi, ENSET, Université Ha...
Support de cours EJB 3 version complète Par Mr  Youssfi, ENSET, Université Ha...Support de cours EJB 3 version complète Par Mr  Youssfi, ENSET, Université Ha...
Support de cours EJB 3 version complète Par Mr Youssfi, ENSET, Université Ha...
ENSET, Université Hassan II Casablanca
 
Chp1 - Introduction aux méthodologies de Conception
Chp1 - Introduction aux méthodologies de ConceptionChp1 - Introduction aux méthodologies de Conception
Chp1 - Introduction aux méthodologies de Conception
Lilia Sfaxi
 
Services web soap-el-habib-nfaoui
Services web soap-el-habib-nfaouiServices web soap-el-habib-nfaoui
Services web soap-el-habib-nfaoui
El Habib NFAOUI
 
Architecture orientée service (SOA)
Architecture orientée service (SOA)Architecture orientée service (SOA)
Architecture orientée service (SOA)
Klee Group
 
Support de cours Spring M.youssfi
Support de cours Spring  M.youssfiSupport de cours Spring  M.youssfi
Support de cours Spring M.youssfi
ENSET, Université Hassan II Casablanca
 
Tp3 - Application SOA avec BPEL
Tp3 - Application SOA avec BPELTp3 - Application SOA avec BPEL
Tp3 - Application SOA avec BPEL
Lilia Sfaxi
 
Mise en oeuvre des Frameworks de Machines et Deep Learning pour les Applicati...
Mise en oeuvre des Frameworks de Machines et Deep Learning pour les Applicati...Mise en oeuvre des Frameworks de Machines et Deep Learning pour les Applicati...
Mise en oeuvre des Frameworks de Machines et Deep Learning pour les Applicati...
ENSET, Université Hassan II Casablanca
 
Conception d’une plateforme web d’e-Commerce au sein d’une entreprise commerc...
Conception d’une plateforme web d’e-Commerce au sein d’une entreprise commerc...Conception d’une plateforme web d’e-Commerce au sein d’une entreprise commerc...
Conception d’une plateforme web d’e-Commerce au sein d’une entreprise commerc...
Symphorien Niyonzima
 

Tendances (20)

Support JEE Servlet Jsp MVC M.Youssfi
Support JEE Servlet Jsp MVC M.YoussfiSupport JEE Servlet Jsp MVC M.Youssfi
Support JEE Servlet Jsp MVC M.Youssfi
 
Appalications JEE avec Servlet/JSP
Appalications JEE avec Servlet/JSPAppalications JEE avec Servlet/JSP
Appalications JEE avec Servlet/JSP
 
BigData_TP3 : Spark
BigData_TP3 : SparkBigData_TP3 : Spark
BigData_TP3 : Spark
 
Sécurité des Applications Web avec Json Web Token (JWT)
Sécurité des Applications Web avec Json Web Token (JWT)Sécurité des Applications Web avec Json Web Token (JWT)
Sécurité des Applications Web avec Json Web Token (JWT)
 
diagramme de séquence UML
diagramme de séquence UMLdiagramme de séquence UML
diagramme de séquence UML
 
Support de cours angular
Support de cours angularSupport de cours angular
Support de cours angular
 
Développement d'un site web de E-Commerce avec PHP (Première Partie)
Développement d'un site web de E-Commerce avec PHP (Première Partie)Développement d'un site web de E-Commerce avec PHP (Première Partie)
Développement d'un site web de E-Commerce avec PHP (Première Partie)
 
BigData_Chp2: Hadoop & Map-Reduce
BigData_Chp2: Hadoop & Map-ReduceBigData_Chp2: Hadoop & Map-Reduce
BigData_Chp2: Hadoop & Map-Reduce
 
Tp2 - WS avec JAXRS
Tp2 - WS avec JAXRSTp2 - WS avec JAXRS
Tp2 - WS avec JAXRS
 
eServices-Tp1: Web Services
eServices-Tp1: Web ServiceseServices-Tp1: Web Services
eServices-Tp1: Web Services
 
Chp1- Introduction aux Technologies Web et SOA
Chp1- Introduction aux Technologies Web et SOAChp1- Introduction aux Technologies Web et SOA
Chp1- Introduction aux Technologies Web et SOA
 
Exercices uml-corrige
Exercices uml-corrigeExercices uml-corrige
Exercices uml-corrige
 
Support de cours EJB 3 version complète Par Mr Youssfi, ENSET, Université Ha...
Support de cours EJB 3 version complète Par Mr  Youssfi, ENSET, Université Ha...Support de cours EJB 3 version complète Par Mr  Youssfi, ENSET, Université Ha...
Support de cours EJB 3 version complète Par Mr Youssfi, ENSET, Université Ha...
 
Chp1 - Introduction aux méthodologies de Conception
Chp1 - Introduction aux méthodologies de ConceptionChp1 - Introduction aux méthodologies de Conception
Chp1 - Introduction aux méthodologies de Conception
 
Services web soap-el-habib-nfaoui
Services web soap-el-habib-nfaouiServices web soap-el-habib-nfaoui
Services web soap-el-habib-nfaoui
 
Architecture orientée service (SOA)
Architecture orientée service (SOA)Architecture orientée service (SOA)
Architecture orientée service (SOA)
 
Support de cours Spring M.youssfi
Support de cours Spring  M.youssfiSupport de cours Spring  M.youssfi
Support de cours Spring M.youssfi
 
Tp3 - Application SOA avec BPEL
Tp3 - Application SOA avec BPELTp3 - Application SOA avec BPEL
Tp3 - Application SOA avec BPEL
 
Mise en oeuvre des Frameworks de Machines et Deep Learning pour les Applicati...
Mise en oeuvre des Frameworks de Machines et Deep Learning pour les Applicati...Mise en oeuvre des Frameworks de Machines et Deep Learning pour les Applicati...
Mise en oeuvre des Frameworks de Machines et Deep Learning pour les Applicati...
 
Conception d’une plateforme web d’e-Commerce au sein d’une entreprise commerc...
Conception d’une plateforme web d’e-Commerce au sein d’une entreprise commerc...Conception d’une plateforme web d’e-Commerce au sein d’une entreprise commerc...
Conception d’une plateforme web d’e-Commerce au sein d’une entreprise commerc...
 

Similaire à Architecture réparties et les services web

SOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhv
SOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhvSOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhv
SOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhv
amine17157
 
resume-theorique-m107-2203-6246f60d6b994.pdf
resume-theorique-m107-2203-6246f60d6b994.pdfresume-theorique-m107-2203-6246f60d6b994.pdf
resume-theorique-m107-2203-6246f60d6b994.pdf
FootballLovers9
 
Cours 2 les architectures reparties
Cours 2 les architectures repartiesCours 2 les architectures reparties
Cours 2 les architectures reparties
Mariem ZAOUALI
 
Les architectures client serveur
Les architectures client serveurLes architectures client serveur
Les architectures client serveur
Ameni Ouertani
 
1 - chapitre 1 chapitre 2 SOA.pdf
1 - chapitre 1 chapitre 2 SOA.pdf1 - chapitre 1 chapitre 2 SOA.pdf
1 - chapitre 1 chapitre 2 SOA.pdf
haythem bouzouraa
 
La plateforme JEE
La plateforme JEELa plateforme JEE
La plateforme JEE
Sabri Bouchlema
 
Général réseau typologie et architecture
Général réseau typologie et architecture Général réseau typologie et architecture
Général réseau typologie et architecture
Manuel Cédric EBODE MBALLA
 
Chap1 clientsrvr
Chap1 clientsrvrChap1 clientsrvr
Chap1 clientsrvr
Rachid Lajouad
 
Déploiement d’applications
Déploiement d’applicationsDéploiement d’applications
Déploiement d’applications
Mohammed Jaafar
 
Cours 1 les principes de base
Cours 1 les principes de baseCours 1 les principes de base
Cours 1 les principes de base
Mariem ZAOUALI
 
Java Entreprise Edition
Java Entreprise EditionJava Entreprise Edition
Java Entreprise Edition
Sabri Bouchlema
 
eServices-Chp4: ESB
eServices-Chp4: ESBeServices-Chp4: ESB
eServices-Chp4: ESB
Lilia Sfaxi
 
Architectures et application hybrides selon vos termes et à votre propre rythme
Architectures et application hybrides selon vos termes et à votre propre rythmeArchitectures et application hybrides selon vos termes et à votre propre rythme
Architectures et application hybrides selon vos termes et à votre propre rythme
Microsoft
 
Introduction à Cloud Foundry et au PaaS
Introduction à Cloud Foundry et au PaaSIntroduction à Cloud Foundry et au PaaS
Introduction à Cloud Foundry et au PaaS
Gerard Konan
 
Les vrais enjeux de l'IA.pdf
Les vrais enjeux de l'IA.pdfLes vrais enjeux de l'IA.pdf
Les vrais enjeux de l'IA.pdf
BabacarDIOP48
 
Cours architecture
Cours architectureCours architecture
Cours architecture
Abdelaziz Elbaze
 
srep_cours_01.pdf
srep_cours_01.pdfsrep_cours_01.pdf
srep_cours_01.pdf
SamirAwad14
 
2 20 presentations_generales_des_web_services
2 20 presentations_generales_des_web_services2 20 presentations_generales_des_web_services
2 20 presentations_generales_des_web_services
Camus LANMADOUCELO
 
Projet reseau-de-kherfallah-ipm-2010-2011
Projet reseau-de-kherfallah-ipm-2010-2011Projet reseau-de-kherfallah-ipm-2010-2011
Projet reseau-de-kherfallah-ipm-2010-2011
Boubaker KHERFALLAH
 
intro-tech-web-lp3-jan-21-slides-1-a-9.pdf
intro-tech-web-lp3-jan-21-slides-1-a-9.pdfintro-tech-web-lp3-jan-21-slides-1-a-9.pdf
intro-tech-web-lp3-jan-21-slides-1-a-9.pdf
CoumbaLaobNdiaye1
 

Similaire à Architecture réparties et les services web (20)

SOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhv
SOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhvSOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhv
SOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhv
 
resume-theorique-m107-2203-6246f60d6b994.pdf
resume-theorique-m107-2203-6246f60d6b994.pdfresume-theorique-m107-2203-6246f60d6b994.pdf
resume-theorique-m107-2203-6246f60d6b994.pdf
 
Cours 2 les architectures reparties
Cours 2 les architectures repartiesCours 2 les architectures reparties
Cours 2 les architectures reparties
 
Les architectures client serveur
Les architectures client serveurLes architectures client serveur
Les architectures client serveur
 
1 - chapitre 1 chapitre 2 SOA.pdf
1 - chapitre 1 chapitre 2 SOA.pdf1 - chapitre 1 chapitre 2 SOA.pdf
1 - chapitre 1 chapitre 2 SOA.pdf
 
La plateforme JEE
La plateforme JEELa plateforme JEE
La plateforme JEE
 
Général réseau typologie et architecture
Général réseau typologie et architecture Général réseau typologie et architecture
Général réseau typologie et architecture
 
Chap1 clientsrvr
Chap1 clientsrvrChap1 clientsrvr
Chap1 clientsrvr
 
Déploiement d’applications
Déploiement d’applicationsDéploiement d’applications
Déploiement d’applications
 
Cours 1 les principes de base
Cours 1 les principes de baseCours 1 les principes de base
Cours 1 les principes de base
 
Java Entreprise Edition
Java Entreprise EditionJava Entreprise Edition
Java Entreprise Edition
 
eServices-Chp4: ESB
eServices-Chp4: ESBeServices-Chp4: ESB
eServices-Chp4: ESB
 
Architectures et application hybrides selon vos termes et à votre propre rythme
Architectures et application hybrides selon vos termes et à votre propre rythmeArchitectures et application hybrides selon vos termes et à votre propre rythme
Architectures et application hybrides selon vos termes et à votre propre rythme
 
Introduction à Cloud Foundry et au PaaS
Introduction à Cloud Foundry et au PaaSIntroduction à Cloud Foundry et au PaaS
Introduction à Cloud Foundry et au PaaS
 
Les vrais enjeux de l'IA.pdf
Les vrais enjeux de l'IA.pdfLes vrais enjeux de l'IA.pdf
Les vrais enjeux de l'IA.pdf
 
Cours architecture
Cours architectureCours architecture
Cours architecture
 
srep_cours_01.pdf
srep_cours_01.pdfsrep_cours_01.pdf
srep_cours_01.pdf
 
2 20 presentations_generales_des_web_services
2 20 presentations_generales_des_web_services2 20 presentations_generales_des_web_services
2 20 presentations_generales_des_web_services
 
Projet reseau-de-kherfallah-ipm-2010-2011
Projet reseau-de-kherfallah-ipm-2010-2011Projet reseau-de-kherfallah-ipm-2010-2011
Projet reseau-de-kherfallah-ipm-2010-2011
 
intro-tech-web-lp3-jan-21-slides-1-a-9.pdf
intro-tech-web-lp3-jan-21-slides-1-a-9.pdfintro-tech-web-lp3-jan-21-slides-1-a-9.pdf
intro-tech-web-lp3-jan-21-slides-1-a-9.pdf
 

Dernier

Webinaire BL 28_06_02_Consommation Energie.pdf
Webinaire BL 28_06_02_Consommation Energie.pdfWebinaire BL 28_06_02_Consommation Energie.pdf
Webinaire BL 28_06_02_Consommation Energie.pdf
Institut de l'Elevage - Idele
 
Présentation Mémoire Cybersecurity .pptx
Présentation Mémoire Cybersecurity .pptxPrésentation Mémoire Cybersecurity .pptx
Présentation Mémoire Cybersecurity .pptx
KODJO10
 
Webinaire BL 28_06_03_Transmissibilité.pdf
Webinaire BL 28_06_03_Transmissibilité.pdfWebinaire BL 28_06_03_Transmissibilité.pdf
Webinaire BL 28_06_03_Transmissibilité.pdf
Institut de l'Elevage - Idele
 
Webinaire BL 28_06_01_robots de traite.pdf
Webinaire BL 28_06_01_robots de traite.pdfWebinaire BL 28_06_01_robots de traite.pdf
Webinaire BL 28_06_01_robots de traite.pdf
Institut de l'Elevage - Idele
 
Shimla Girls call Service 000XX00000 Provide Best And Top Girl Service And No...
Shimla Girls call Service 000XX00000 Provide Best And Top Girl Service And No...Shimla Girls call Service 000XX00000 Provide Best And Top Girl Service And No...
Shimla Girls call Service 000XX00000 Provide Best And Top Girl Service And No...
manalishivani8
 
cours-sur-les-stations-de-pompageen génie civil.pdf
cours-sur-les-stations-de-pompageen génie civil.pdfcours-sur-les-stations-de-pompageen génie civil.pdf
cours-sur-les-stations-de-pompageen génie civil.pdf
afigloria194
 

Dernier (6)

Webinaire BL 28_06_02_Consommation Energie.pdf
Webinaire BL 28_06_02_Consommation Energie.pdfWebinaire BL 28_06_02_Consommation Energie.pdf
Webinaire BL 28_06_02_Consommation Energie.pdf
 
Présentation Mémoire Cybersecurity .pptx
Présentation Mémoire Cybersecurity .pptxPrésentation Mémoire Cybersecurity .pptx
Présentation Mémoire Cybersecurity .pptx
 
Webinaire BL 28_06_03_Transmissibilité.pdf
Webinaire BL 28_06_03_Transmissibilité.pdfWebinaire BL 28_06_03_Transmissibilité.pdf
Webinaire BL 28_06_03_Transmissibilité.pdf
 
Webinaire BL 28_06_01_robots de traite.pdf
Webinaire BL 28_06_01_robots de traite.pdfWebinaire BL 28_06_01_robots de traite.pdf
Webinaire BL 28_06_01_robots de traite.pdf
 
Shimla Girls call Service 000XX00000 Provide Best And Top Girl Service And No...
Shimla Girls call Service 000XX00000 Provide Best And Top Girl Service And No...Shimla Girls call Service 000XX00000 Provide Best And Top Girl Service And No...
Shimla Girls call Service 000XX00000 Provide Best And Top Girl Service And No...
 
cours-sur-les-stations-de-pompageen génie civil.pdf
cours-sur-les-stations-de-pompageen génie civil.pdfcours-sur-les-stations-de-pompageen génie civil.pdf
cours-sur-les-stations-de-pompageen génie civil.pdf
 

Architecture réparties et les services web

  • 1. 1 Architectures réparties Présenté par : EL HACHIMI CHOUAIB Cours Web service et sémantique: Pr. J. EL KAFI.
  • 2. Définitions Dans le cadre des architectures réparties, on distingue : • Les architectures centralisées (type client-serveur) • Les architectures distribuées (Peer to Peer) La différence fondamentale entre ces deux type d’architecture se situe dans la distribution des rôles entre les nœuds du réseau : • On parle d’architecture centralisée car les nœuds jouant le rôle de serveur centralisent une grande partie de l’information et des communications (ex. n clients pour 1 serveur) et sont distincts des nœuds clients. • A contrario, dans les architectures distribuées, tous les nœuds du réseau partagent théoriquement les mêmes rôles : ils sont simultanément clients et serveurs et disposent de tout ou partie de l’information répartie.
  • 4. Définition • Le client-serveur est un type d’architecture qui effectue une distinction stricte entre les rôles de client d’une part et de serveur d’autre part. • On peut l'interpréter d’un point de vue matériel (des machines clientes et des machines serveurs) ou logiciel (entités clientes et entités serveurs d’une même application). • Les interprétations matérielles et logicielles sont souvent liées: une application client-serveur est communément répartie sur plusieurs machines connectées par un réseau. • Mode de fonctionnement général : 1. Point de vue client: un client effectue une requête pour un service précis sur un serveur donné et reçoit une réponse. 2. Point de vue serveur: un serveur reçoit une demande de service, la traite, et renvoie la réponse au client.
  • 5. Caractéristiques générales client • Il est actif (ou maître). • Il envoie des requêtes au(x) serveur(s). • Il attend (pas forcement) et reçoit les réponses du/des serveur(s). • Il ne peut être connecté qu’à un petit nombre de serveurs en même temps. • Il interagit généralement directement avec un utilisateur final en utilisant une IHM.
  • 6. Caractéristiques générales serveur • Il est passif (ou esclave). • Il est à l'écoute, prêt à répondre aux requêtes envoyées par plusieurs clients. • Dès qu'une requête lui parvient, il la traite et envoie une réponse. • Il accepte normalement un nombre important de connections de la part des clients. • Il n'interagit pas directement avec les utilisateurs finaux.
  • 7. Exemples • La consultation de pages web fonctionne sur une architecture client/ serveur. Un internaute connecté au réseau via son ordinateur et un navigateur Web est le client, le serveur est constitué par le ou les ordinateurs contenant les applications qui délivrent les pages demandées. Dans ce cas, c'est le protocole de communication HTTP qui est utilisé. • Les emails sont envoyés et reçus par des clients et gérés par un serveur de messagerie. Les protocoles utilisés sont le SMTP, et le POP ou l'IMAP. • La gestion d'une base de données centralisée sur un serveur peut se faire à partir de plusieurs postes clients qui permettent de visualiser et saisir des données. • Le système X Window (*nix) fonctionne sur une architecture client/serveur. En général le client tourne sur la même machine que le serveur, mais peut être aussi bien lancé sur un autre ordinateur faisant partie du réseau.
  • 8. Exemples: le web • A ne pas confondre avec “internet”, le web est un de ses services constitutifs et historique dans le but est d’afficher de l’information sous forme de pages navigables par des hyperliens. • Le web repose sur un protocole client/serveur: HTTP • Client : le navigateur (Firefox, Explorer, Opéra, Safari,...) va émettre une requête • Serveur : le serveur Web (Apache, IIS,...) répond en fournissant le document demandé ou un message d’erreur si le document n’existe pas
  • 9. Couches fonctionnelles Toute application client-serveur est composée de 3 couches fonctionnelles:
  • 10. Couches fonctionnelles • Présentation : correspondant à l'affichage, la restitution sur le poste de travail, le dialogue avec l'utilisateur (= interface utilisateur, IHM …). • Traitements métiers : correspondant à la mise en œuvre de l'ensemble des règles de gestion et de la logique applicative. • Persistance de données: correspondant aux données qui sont destinées à être conservées sur la durée, voire de manière définitive.  C’est la répartition de ces couches entre les rôles de clients et serveurs qui permet de distinguer entre les différents types d’architectures client-serveur.
  • 12. Couche Présentation • Elle correspond à la partie de l'application visible et interactive avec les utilisateurs. On parle d'Interface Homme Machine. • On conçoit facilement que cette interface peut prendre de multiples facettes sans changer la finalité de l'application. Dans le cas d'un système de distributeurs de billets, l'automate peut être différent d'une banque à l'autre, mais les fonctionnalités offertes sont similaires et les services identiques (fournir des billets, donner un extrait de compte, etc.). • La couche présentation relaie les requêtes de l'utilisateur à destination de la couche métier, et en retour lui présente les informations renvoyées par les traitements de cette couche. Il s'agit donc ici d'un assemblage de services métiers et applicatifs offerts par la couche inférieure.
  • 13. Couche Traitements métiers • Elle correspond à la partie fonctionnelle de l'application, celle qui implémente la logique, et qui décrit les opérations que l'application opère sur les données en fonction des requêtes des utilisateurs, effectuées au travers de la couche présentation. • Les différentes règles de gestion et de contrôle du système sont mises en œuvre dans cette couche. • La couche métier offre des services applicatifs et métiers à la couche présentation. Pour fournir ces services, elle s'appuie, sur les données du système, accessibles au travers des services de la couche inférieure. En retour, elle renvoie à la couche présentation les résultats qu'elle a calculés.
  • 14. Couche Persistance de données Elle consiste en la partie gérant l'accès aux sources de données du système. Ces données peuvent être propres au système, ou gérées par un autre système. La couche métier n'a pas à s'adapter à ces deux cas, ils sont transparents pour elle, et elle accède aux données de manière uniforme. • Données propres au système: ces données sont pérennes, car destinées à durer dans le temps, de manière plus ou moins longue, voire définitive. Elles peuvent être stockées indifféremment dans de simples fichiers texte, XML, ou encore dans une base de données. • Données gérées par un autre système: elles ne sont pas stockées par le système considéré, il s'appuie sur la capacité d'un autre système à fournir ces informations.  Par exemple, une application de pilotage de l'entreprise peut ne pas sauvegarder des données comptables de haut niveau dont elle a besoin, mais les demander à une application de comptabilité indépendante et préexistante.
  • 15. 2-tiers • C’est le type d’architecture client-serveur le plus basique : • La couche présentation est située sur le client • La couche donnée est située sur le serveur (par ex. une base de données relationnelles SQL, Oracle,...) • La couche traitement peut être située sur le client (au sein même de l’IHM), le serveur (par ex. des procédures stockées sur la base de données), ou partagée entre les deux rôles. • Il y a une relation directe entre les clients et les serveurs de données. • (+) simple à mettre en œuvre • (-) peu flexible et supporte difficilement la montée en charge • (-) souvent des solutions propriétaires, économiquement très couteux
  • 17. 3-tiers • L’architecture 3-tiers est une extension du modèle client-serveur qui introduit un rôle spécifique pour la couche de traitements métiers. • Il y a donc décomposition d’un même service sur 2 types de serveurs: • Un type de serveur dédié à la gestion des traitements métiers. • Un type de serveur dédié à la gestion des données persistantes. • (+) plus évolutif que le 2-tiers • (+) meilleure répartition des charges de travail coté serveur • (+) économiquement moins cher, surtout lors de la montée en charge • (-) administration et mise en œuvre plus compliquée que le 2-tiers
  • 19. n-tiers • Généralisation de l’architecture 3-tiers • La couche serveur peut être divisée en autant de sous-rôles que voulus • Sensiblement les mêmes avantages et inconvénients que la couche 3-tiers.
  • 22. Définitions • Dans les architectures distribuées les nœuds du réseau sont en relation d’égal à égal. • Les caractéristique habituelles de ces architectures sont les suivantes : • Pas de connaissance globale du réseau. • Pas de coordination globale des nœuds. • Chaque nœud ne connaît que les nœuds constituant son voisinage. • Toutes les données sont accessibles à partir de n’importe quel nœud. • Les nœuds sont très volatiles (ils peuvent disparaître ou apparaître à tout moment).
  • 23. Architectures distribuées • Les technologies Peer-to-Peer (P2P, ou Pair-à-Pair) constituent le pendant technologique des architectures distribuées. • La parfaite homogénéité des rôles vue précédemment correspond rarement à la réalité des réseau P2P déployés de part le monde. De ce fait, on procède à leur classification en différentes grandes familles .
  • 24. Architectures distribuées • P2P “pur” (par ex. Gnutella) : • Respecte les caractéristiques précédentes : • Les pairs sont égaux et fusionnent les rôles de client et de serveur. • P2P hybride (par ex. Napster) : • Données distribuées mais index centralisé : • On dispose d’un serveur central qui conserve des informations sur les pairs et peut répondre à des requêtes sur cette information (il joue souvent le rôle d’un annuaire de clients et de fichiers). • Les pairs sont responsables de l’hébergement des ressources partagées mais doivent indiquer leur disponibilité au serveur central. • Il n’y a pas de serveur central pour gérer le réseau. • Il n’y a pas de routeur central.
  • 25. Architectures distribuées • P2P Structuré (Chord, P-Grid, CAN, …) : • Index distribué et stocké par DHT (Distributed Hash Tables). • P2P Hiérarchique (Super-Peer, Kazaa,…) : • Couplage entre les architectures Client-Serveur et le P2P. • P2P Sémantique (SON, Routing Indices, …) : • P2P Pur avec routage enrichit de critères sémantiques.
  • 26. Avantages - Inconvénients • Avantages : • Tous les pairs fournissent des ressources (bande passante, stockage, puissance de calcul,...). On obtient ainsi des architectures qui Supportent beaucoup mieux la montée en charge (“scalability”) que les architectures centralisées. • La distribution augmente la robustesse du réseau dans le cas d’une panne par la réplication des données sur plusieurs pairs. Et, dans le cas d’un P2P pur, il n’y pas de point central de vulnérabilité (l’annuaire). • Inconvénients : • Mauvaise réputation du “P2P”, invariablement associé au téléchargement musical → faible adoption par l’industrie. • Les architectures distribuées amènent leur lot de problématiques spécifiques (concurrence entre les pairs, fragmentation des données, ...). • Elles ne permettent pas un contrôle avancé des échanges d’information entre les pairs (inconvénient ou avantage ?).
  • 27. Les Services Web Dans une agence de voyage, un produit « voyage » est en réalité une combinaison de plusieurs produits : • Gestion de réservation des billets de transport • Gestion de réservation des hôtels • Gestion de réservation des voitures de location • ... L'élaboration d'un produit « voyage » est bien le résultat d'informations récupérées auprès de différents fournisseurs : • Compagnies aériennes • Chaînes hôtelières • Loueurs de véhicules • ...
  • 29. Définitions  Sur le schéma précédent, l'application consultée par le client met en œuvre des applications réparties pour satisfaire sa demande. Dans cette mise en œuvre applicative, on parle: • De transformation, lorsqu'il s'agit d'adapter le dialogue en fonction du profil utilisateur. • D'agrégation, lorsqu'il s'agit de faire appel à des applications proposées par des partenaires ou fournisseurs  Que ce soit de l'agrégation ou de la transformation d'informations˛ les applications réalisant ces tâches de façon complètement automatique et opaque s'appellent des « services web ».
  • 30. Définition  Une application web communicante résulte alors d'un assemblage de services web.  Certains sont internes et d'autres externes et fournis par divers partenaires et fournisseurs.  Les deux extrémités de cet assemblage sont : • Le tout interne : entièrement composé de services internes˛ on parle alors d'intégration d'applications d'entreprise. • Le tout externe : entièrement composé de services externes, on parle alors de portail d'entreprises.
  • 31. Les Services Web, c'est quoi ?  C'est la possibilité d'invoquer une fonction distante. En l'occurrence, sur un serveur web distant puisque le protocole de base est HTTP .  On dispose d'une infrastructure souple basée sur XML pour les systèmes distribués hétérogènes.
  • 32. Les Services Web, c'est quoi ?  Ils sont accessibles via le web par des protocoles bien connus  Ils sont décrits à partir de XML  Ils interagissent via XML  Ils sont localisables à partir de registres  Ils sont entièrement transversaux aux plates-formes et très faiblement couplés
  • 33. Les Services Web, c'est quoi ?  Ils introduisent un nouveau modèle de développement basé sur ce que l'on appelle les architectures orientées services (très pratique pour B2B)  Une architecture orientée services se focalise sur une décomposition plus abstraite dans la résolution des problèmes. On parle de résolution dirigée par les services.  Un service résout un problème donné  Les services peuvent être combinés pour résoudre des problèmes de plus en plus complexes .
  • 34. Les Services Web, c'est quoi ? Les tâches associées à la manipulation des services web sont :  Interroger un annuaire : qui fournit des choses dont on ne connaît pas forcément la nature, le rôle ou le contenu . • Nature exacte du service fourni • Qualité/coût/etc.  Interagir avec le service du fournisseur choisi pour : • Connaître les modalités d'interaction • Introduire le service dans ma chaîne de traitements  Eventuellement composer des services  Eventuellement publier mes propres services  Négocier avec les fournisseurs potentiels de ces choses pour connaître :
  • 35. Les Services Web, c'est quoi ?  L'avantage essentiel des services web concerne le fait que le client consommateur n'a pas besoin de connaître l'identité du fournisseur du service.  Le client doit simplement exprimer son besoin.  Face à un besoin, plusieurs fournisseurs de services peuvent exister  Chacun ayant des caractéristiques de coût, de performance, de fiabilité, etc.  Le client choisit le fournisseur (i.e. le service) correspondant le mieux à ses besoins.
  • 36. Les Services Web, pourquoi ?  Lorsque l'on a besoin d'interopérabilité dans des environnements applicatifs distribués  Les services peuvent communiquer entre eux, et cela depuis des environnements applicatifs distants  Lorsque l'on veut accéder aux applications à travers les pare-feu  Les services web sont définis et accédés avec XML sur des protocoles standards comme HTTP et SMTP. Ils peuvent alors être invoqués à travers un pare-feu.  Lorsque l'on veut profiter de différents environnements et langages de développement  Par une description et une invocation XML, les services web sont très flexibles et indépendants des langages et des systèmes.
  • 37. Les usages  Les services web pour représenter des applications sophistiquées bien délimitées et sans forte interactivité.  Par exemple, une application qui donne les conditions du temps peut être idéalement représentée par un service.  Les services web sont adaptés pour l'assemblage de composants faiblement couplés.  Ils sont définis de façon indépendante, mais peuvent interagir.  Les services web sont adaptés à la représentation d'application orientées messages.  Les mécanismes d'invocation asynchrone des applications orientées messages sont en font de bonnes candidates aux services web.
  • 38. Les acteurs (rôles) Les principaux acteurs dans la technologie des services web sont :  Le client : celui qui utilise, invoque le service web  Le fournisseur : celui qui fournit le service web  L'annuaire : celui qui détient les informations du service web
  • 39. Les acteurs (rôles)  Le client et le fournisseur sont les éléments principaux dans l'architecture des services web  Un fournisseur est représenté par un serveur d'application (J2EE par exemple)  Le fournisseur détient un ou plusieurs services qui sont représentés par des EJBs ou des servlets et qui sont enveloppés d'une couche « service »  Le fournisseur peut être le client d'un autre fournisseur (interopérabilité)  Une fois le service définit, il peut être déclaré dans un annuaire, on parle alors de publication du service afin de le rendre accessible aux clients.
  • 40. Scénario complet Etape 1 : définition, description du service • On doit décrire d'un point de vue informatique ce que fait le service, la solution qu'il propose, ... • La définition est faite en WSDL au sein du fournisseur de services (i.e. le serveur d'applications) Etape 2 : publication du service • Une fois le service définit et décrit en termes de mise en œuvre, il peut être déclaré dans un annuaire, on parle alors de publication du service afin de le rendre accessible aux clients. • Comme on le verra, la publication sera effectué au sein d'un annuaire dédié UDDI. Etape 3 : recherche du service • Le client se connecte, sur un annuaire (UDDI) pour effectuer une recherche de service.
  • 41. Scénario complet Etape 4 : enregistrement au service web • Une fois le service trouvé par le client˛ ce dernier doit s'enregistrer auprès du fournisseur associé au service. • Cet enregistrement indique au fournisseur l'intention du client d'utiliser le service suivant les conditions décrites dans la publication. Etape 5 : mise en œuvre du service • Le client peut invoquer le service suivant les conditions inscrites au sein de l'annuaire lors de la publication du service web (étape 2) Etape 6 : composition • C'est la possibilité de combiner plusieurs services. En fait, un service peut devenir le client d'un autre service.
  • 44. Conclusion et Initiation L'architecture des Web Services repose essentiellement sur les technologies suivantes : • XML (Extensible Markup Language). • SOAP (Simple Object Access Protocol ) Protocole pour la communication entre les Services Web. • WSDL (Web Service Description Language) Langage de description de l'interface du Web. • UDDI (Universal Description˛ Discovery and Integration) Annuaire pour le référencement du Web Service. Et qui sont les sujets des présentation suivantes.