Chapitre 1 : Introduction

à l’architecture orientée
services

SONIA KEFI
3ÈME LI

Année Universitaire : 2023-2024

 2
Objectif du cours

 Comprendre le concept d’un service et les principes de

l’architecture SOA.
 Comprendre l’intérêt de l’architecture SOA.
 Comprendre le concept service Web et apprendre à utiliser ou
interpréter les standards des services Web.
 Maîtriser le développement de services Web :
 Le protocole SOAP : JAX-WS.
 L’architecture REST : JAX-RS.
 Pré-requis :
†
 Ingénierie des données
 Langages de description : XML †
 Architectures multi-couches (Java EE)
 3
Plan

 Définition d’un service

 L’architecture SOA
 Les standards des services Web
 4
Généralité : Rappel

Software de
développement

Mobile Web Bureautique Design

 Mobile 5

Web
Native Hybrid
mobile

Android
(java,
Kotlin) Android & Android &
IOS (Ionic, IOS (HTML,
IOS
React Native, CSS,
(Swift, Flutter ) JavaScript)
objectif C)

HarmonyOS
(java, JS,C,
C++)
 Mobile 6

Web
Native Hybrid
mobile

Android
(java,
Kotlin) Android & Android &
IOS (Ionic, IOS (HTML,
IOS
React Native, CSS,
(Swift, Flutter ) JavaScript)
objectif C)

HarmonyOS
(java, JS,C,
C++)
Cross Plaform
Mobile Application
 7

Web

NodeJS JEE .Net PHP

Java
Java C#
Script
 8

Web

NodeJS JEE .Net PHP

Java
Java C#
Script
 9
Evolution des langages de
programmation
Langage machine C’est le langage binaire

Assembleur Langage du bas niveau

Sous-programme: procédures et fonctions

Programmation Procédurale (Basic, Pascal, C, Fortran)

Programmation Orientée Objet = Etat+ Comportement + Identité

Objet Concepts fondamentaux : Objet, classe, héritage,
polymorphisme, encapsulation (C++, Java, C#,…)

Programmation Orientée Objets distribués sur plusieurs machines :

Objet Distribué Middlewares (RMI, CORBA, JMS, …)

Objets distribués, réutilisables, configurables,

Programmation Orientée Interchangeables, évolutifs, mobiles :
Composants Connecteurs (EJB, Spring): AOP

Programmation Orientée Composants disponibles à d’autres applications

distances hétérogènes via des protocoles (http)
Services
transportant des données : XML, JSON SOAP et
REST
Programmation Orientée Service + Intelligence +Application+…
Agents
 10
Chronique d’une évolution
 11
Introduction

 Une architecture est le modèle fondamental à la bonne réalisation d’une

application web.
 Cela permet au développeur ou n’importe quelle personne intéressée par la
conception et la création d’un logiciel de bien comprendre comment il va
fonctionner.
 Elle va être composée de tous les éléments fonctionnels, techniques et
de codage.
 L’architecture varie en fonction de son type et de ses utilisateurs. La plupart du
temps pour représenter les acteurs, les actions, les fonctionnalités et la
technique informatique utilisée dans une application, on utilise une méthode
de modélisation graphique, c’est-à-dire, on va créer un diagramme.
 En effet, le diagramme de type UML par exemple, donne une vision globale
pour son concepteur. Il permet de bien comprendre le développement d’une
application.
 L’architecture est le début de la mise en place d’un projet. Elle permet de
comprendre les besoins du client de l’application.
 12
Suite

 Une architecture d'application comprend les services front-end

et back-end. Le développement front-end concerne
l'expérience utilisateur de l'application (IHM), tandis que le
développement back-end permet de fournir l'accès aux
données, aux services et à d'autres systèmes dont dépend
l'application.
 Il existe de nombreux langages de programmation pour le
développement logiciel. Certains langages sont utilisés pour
créer certains types d'applications, par exemple Swift pour les
applications mobiles ou JavaScript pour le développement
front-end.
 D'autres langages de programmation sont aussi largement
utilisés : Java, Python, Swift, TypeScript, PHP et SQL. Le choix du
langage dépend du type d'application à créer, des ressources
de développement disponibles ainsi que d'autres facteurs.
 13
Evolution des architectures

 Auparavant, les applications étaient rédigées sous la forme d'une seule

unité de code, où tous les composants partageaient les mêmes
ressources et le même espace mémoire. C'est ce que l'on appelle une
architecture de type monolithique.
 Actuellement, les architectures d'applications sont généralement
faiblement couplées. Elles reposent sur des microservices et
des interfaces de programmation d'application (API) qui connectent
les services.
 Il existe d’autres types d'architectures d'applications différents,
au sein desquelles les relations entre les services sont plus ou
moins découplés tels que les architectures de microservices
(découplées) et les architectures orientées services (faiblement
couplées).
 14
Architecture monolithique

 Avant, toutes les applications se basent sur

l’architecture monolithique.

 En effet, elles étaient formées par :

 Un gros code contenant toutes les fonctionnalités

et les différentes couches logicielles.
 Une seule grosse compilation.
 Une seule pile logicielle (Linux, JVM, Tomcat, …)
Evolution des applications 15
 16

Quels sont les principes

de base du SOA ?
C’est quoi un
Service ?
 18
Définition d’un service

 C’est un Composant logiciel qui exécute une action

pour un client.

 «Un Service est un composant logiciel distribué,

exposant les fonctionnalités à forte valeur ajoutée
d’un domaine métier »
 19
Le rôle d’un service
 20
Propriétés du service
 21
Réutilisabilité par contrat

 Le service est réutilisable conformément à un contrat entre le

fournisseur et le consommateur.
 Le contrat décrit :
 La syntaxe du service : opération, input, output, format,
protocole…
 La sémantique de son utilisation : pré-conditions, post-conditions…
 Sa QOS : temps de réponse attendu, temps de reprise après
interruption…
 Le contrat est généralement décrit au moyen du standard WSDL.
 22
Interface adressable et
communication par message

 Chaque consommateur peut invoquer un service via son adresse

URL dans le réseau à n’importe quel moment.
 Le consommateur peut accéder localement au service pour
augmenter la performance, s’ils sont hébergés dans la même machine.
 Les services communiquent uniquement par messages.
 Appels via le réseau vu que les services sont distribués en SOA.
 Pour augmenter la performance, les concepteurs doivent penser à
augmenter la granularité des interfaces de services pour diminuer
le nombre d’appels réseau.
 23
Abstraction et Prédictibilité

 Le service fonctionne en « boîte noire »

 Seul le contrat du service (informations nécessaires pour
l’invocation) est exposé au consommateur du service.
 Le fonctionnement interne du service (sa logique métier et
son implémentation) ne sont pas visibles.
 Il est Prédictible
 Son comportement et sa réponse lors de la réception d’une
requête ne varient pas.
Couplage faible

 Dépendance faible entre le consommateur et le service

 Dépendance du contrat et non pas de l’implémentation
 Echange à travers des messages
 Orchestration assure l’indépendance des services vu qu’elle leur permet de
communiquer pour réaliser un processus, sans avoir à se connaître.
 Avantage : Maintenance facile
 Un changement dans le service suscite peu de changements dans ses
consommateurs (juste ceux relatifs au respect du contrat).

2
4
 25
Autonomie et modularité

 Autonomie :
 Le service est Indépendant des services externes : son
comportement est indépendant du contexte fonctionnel
et technique dans lequel il a été invoqué.

 Modularité : Il peut être déployé de façon atomique bien

avant le développement ou déploiement de l’application
finale.
 26
Découvrabilité

 Il est publié par le fournisseur dans un annuaire : décrit par

un ensemble de métadonnées qui permettent de l’identifier
et qu’il est possible de le mettre à jour.
 Le consommateur peut chercher un service selon un
ensemble de critères à partir de l’annuaire :
 L’annuaire renvoie au consommateur la liste des services
(adresses) qui répondent à sa requête.
 Tous les arguments nécessaires à l’exécution du service
sélectionné (opérations, paramètres…) sont accessibles à partir
de son contrat.
 27
Types de services

 Applicatif,
 Fonctionnel,
 CRUD : Create, Read, Update and Delete,
 Technique.
 28
Types de services
 29
Service Applicatif

 Il traduit la logique applicative d’une application, exprimée par les

diagrammes de cas d’utilisation ou les processus métier.
 C’est un service de la couche applicative, qui n’est en général utilisé
que dans le contexte de l’application où il a été créé.
 Il peut être modélisé par :
 UML : Uses cases et Diagramme d’activité
 MERISE : Modèle Organisationnel de Traitements
 Ses opérations peuvent être déclenchées selon que des préconditions
sont vérifiées ou non.
 Ses résultats peuvent être émises selon que des post-conditions sont
vérifiées ou non.
 Son comportement s’adapte aux besoins des clients et au contexte
d’exécution.
 30
Service CRUD

 CRUD : c’est un service élémentaire permettant

de créer, rechercher, lire, mise à jour ou exporter
vers un format (pdf, excel…), ...
 31
Service fonctionnel

 C’est un service de la couche Services, réutilisable

dans des contextes variables.
 Il exécute un traitement métier (une fonction), et
peut être invoqué par différent services applicatifs.
 Il invoque des services CRUD et/ou Transverses
pour pouvoir manipuler des objets métiers.
 Il peut aussi servir à la gestion de la sécurité, des
règles métiers, ...
 Architecture
Orientée Services
(SOA)
 33
La découverte de la SOA

 Avant, Les développeurs déployaient leurs programmes dans un ordinateur

unique. Comme le système était unifié et que tous les programmeurs
travaillaient plus ou moins dans le même environnement et avec les mêmes
technologies, tout fonctionnait parfaitement, mais il y avait beaucoup
d’inconvenients.
 Avec l’arrivée du XML, l'architecture orientée services a fait son apparition.
 L’idée est simple : organiser les SI de façon à ce qu’ils soient composés de
briques indépendantes appelées services.
 Chaque service a un nombre de fonctionnalités cohérentes et est
indépendant des autres services.
 Ces services vont communiquer entre eux grâce à un protocole standard,
connu et compris de tous.
 Le protocole qui s’est largement imposé est le SOAP basé sur le XML, après
l’architecture REST basé sur le JSON.
 La SOA selon les rôles

Chaque rôle s'approprie SOA différemment :

Décrire l’ensemble de services que l'entreprise souhaite exposer à
leurs clients et partenaires.

Dirigeants
Utiliser un style architectural basé sur un fournisseur,
un demandeur et une description de service, et qui
Analystes métier supporte les propriétés de modularité, découvrabilité,
découplage, réutilisation et composabilité

Architectes

Définir un modèle de programmation avec les

standards, les outils et les technologies associées

Développeurs Utiliser un intergiciel qui offre des fonctionnalités

en terme d'assemblage, d'orchestration, de
surveillance et de gestion des services.
Intégrateurs
 35
SOA : Généralités

 SOA est l’acronyme de Service Oriented Architecture qui est traduit comme «
Architecture Orientée Service »
 Le Service désigne le fondement de ce modèle d’interaction entre applications.
 Le paradigme SOA : Publier, Chercher et Consommer
 36
Suite
 37
Suite

❖ Un SOA est formé par trois acteurs :

 Fournisseur de service :
 Fournit un service accessible via une adresse.
 Publie son contrat dans le registre de services.
 Exécute les requêtes des consommateurs.
 Consommateur de service : application, service…
 Cherche le service dans le registre avec son adresse URL.
 Se lie dynamiquement au service.
 Invoque le service via une requête conforme au contrat.
 Registre de services : C’est un annuaire des contrats de services (UDDI)
 Le Contrat décrit le format d’échange (format des requête/réponse, les pré et post
conditions du service et sa QoS, ex: temps de réponse).
 38
Les fournisseurs de services
web ?
 Deux types de fournisseurs sont à distinguer :†
 Fournisseurs de services web « Orientés Web » (public) †
 Fournisseurs de services web « Entreprise » (privé) †

 Les grands noms du Web sont présents et leurs services sont

accessibles : Amazon, eBay, Facebook, Google, Twitter,
Netflix, Yahoo, Microsoft…
 Standards de l’architecture SOA

 Les standards sont des éléments clés d’une SOA, ils assurent
l’interopérabilité.

SOAP WSDL UDDI BPEL

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

Les trois piliers des Services Web

- 39 -
 Exemple d’une architecture SOA 40

Envoyer une réponse

❑ Comment les autres services peuvent-ils trouver le document WSDL

pour consultation ?
❑ La solution est de centraliser tous les documents WSDL dans un serveur qui
tient un annuaire appelé UDDI de ceux-ci.
❑ Les différents services connaissent l’URL de ce registre. Ils le consultent pour
découvrir les nouveaux services et lire les WSDL afin de communiquer
ensemble. Ils ont ainsi l’URL du service, ses fonctions et le type de réponse
qu’il va renvoyer.
Le langage BPEL

➢ BPEL (Business Process Execution Language), est un langage

basé sur XML permettant de créer des processus d’entreprise.
➢ C’est un Standard de l’OASIS (Organization for the
Advancement of Structured Information Standards) : est un
consortium mondial qui travaille pour la standardisation de formats
de fichiers ouverts fondés notamment sur XML.
➢ Les possibilités offertes par BPEL sont nombreuses, il est
notamment utilisé pour la mise en œuvre d’orchestration de
services.
➢ BPEL offre la possibilité d’interagir avec les autres Web
Services et ainsi de faire communiquer tout type
d’application ayant une interface Web Service, de mettre en
place des processus complexes, de gérer simplement les
exceptions, etc.
BPEL le chef d’orchestre
-
Service web via des
messages SOAP
 44
Objectifs

 Spécifier le contrat d’un service web (WSDL).

 Programmer un service web à partir d’une classe Java.
 Appeler un service web via des messages SOAP et HTTP
 Déployer un service web.
 Programmer un client d’un service web.
 45
Introduction

 L’architecture SOA peut être implémentée par différentes

Technologies :
 CORBA (architecture logicielle pour le développement des composant)
 DCOM (architecture logicielle de Microsoft),
 APIs,
 Services Web (protocole SOAP)
 Les Services Web demeurent la technologie émergente pour
l’implémentation de l’architecture SOA puisqu’ils sont :
 multiplateformes,
 multilangages,
 relativement faciles à implémenter
 Disposent de standards : WSDL, BPEL…
 46
Services web : Réponses au
SOA

 Les services web sont basés sur les protocoles et les langages du Web
 HTTP, XML, TCP/IP pour la couche réseau.
 Ne nécessite pas une configuration réseau particulière.
 Les services web sont auto-suffisants puisqu’ils contiennent toutes les
informations à leurs utilisations
 Chercher, publier et consommer.
 Annuaire, contrat de fonctionnement et un client pour les consommer.
 Les services web sont modulaires.
 Une application doit être décomposée en un ensemble de services.
 Utilisation d’une orchestration.
 47
Services web : Technologies
disponibles

 Deux familles de services web se distinguent actuellement :

 Services web « étendus »
 S’appuie sur des standards UDDI / WSDL / SOAP
 Annuaire de services web : UDDI
 Contrat : WSDL
 Consommer par le message : SOAP
 Services web REST (Representational State Transfer)
 Défini par la thèse de Roy Fielding en 2000
 Utilise directement HTTP au lieu d’utiliser une enveloppe SOAP.
 URI est utilisée pour nommer et identifier une ressource
 Méthodes HTTP (POST, GET, PUT et DELETE) sont utilisées pour effectuer les
opérations de base CRUD.
 48
Services web étendus
 49
Services web étendus
 Pile des pour les services web étendus
 50
Plateformes de développement

 La grande majorité des plateformes de développements

fournissent le support de services web (outils et APIs).
 Plateforme .NET
 Plateforme Java
 Plateforme PHP, C++, Python, …
 Il existe des outils qui permettent de :
 Manipuler des messages SOAP
 Manipuler des données au format XML
 Accéder à la couche HTTP
 Dans ce cours, nous utiliserons la plateforme Java
 gratuite, accessible, légère, respect des standards.
 51
Librairie JAX-WS

 En Java, la librairie par défaut est JAX-WS. Elle va

vous permettre de :
 Générer les WSDL : décrire les classes spécifiées dans votre
service dans un fichier WSDL à publier, comme vu plus haut,
dans un serveur UDDI.
 Invoquer un service : il vous permettra de récupérer les
fichiers WSDL et d’en générer des Class “proxy” que vous
appellerez depuis votre code comme n’importe quelle
Class. Jax-WS générera ensuite les messages SOAP et gérera
le parsing des réponses.
 52
Endpoint et Binding

 Le Endpoint est le port ou point d’accès au service.

 Il est décrit par un triplet : l’adresse du service, un binding et la liste
des opérations du service accessibles à partir de ce endpoint
 Le Binding indique le modèle à utiliser pour communiquer avec
le service
 Protocole de transport : http, https (sécurité SSL/TLS), Sockets TCP/IP
(adaptés au transfert de données volumineuses : son ou vidéo),
Canaux nommés (utilisés lorsque les clients et le service sont sur la
même machine)
 Format des messages : format des données à utiliser pour formuler
les requêtes du client et à considérer pour interpréter les réponses
du serveur (format textuel basé sur XML ou binaire pour transmettre
des flux volumineux : vidéo…)
 Il peut aussi définir les Paramètres de sécurité (cryptographie…) et
la manière de gérer les transactions par le service…
 53
Binding

 L' élément <binding> fournit des détails spécifiques sur la manière

dont une opération portType sera réellement transmise sur le
réseau.
 Les liaisons peuvent être rendues disponibles via plusieurs
transports, notamment HTTP GET, HTTP POST ou SOAP.
 Les liaisons fournissent des informations concrètes sur le protocole
utilisé pour transférer les opérations portType.
 Les liaisons fournissent des informations sur l'emplacement du
service.
 Pour le protocole SOAP, la liaison est <soap: binding> et le
transport est constitué de messages SOAP au-dessus du protocole
HTTP.
 Vous pouvez spécifier plusieurs liaisons pour un seul type de port .
 L'élément de liaison a deux attributs: nom et attribut de type .
 54
Type de Binding

 Deux modèles de style de communication sont utilisés pour convertir une liaison WSDL en
un corps de message SOAP. Ils sont : Document & RPC
 RPC :
 XML-RPC est un protocole RPC (Remote procedure call), une spécification simple et
un ensemble de codes qui permettent à des processus de s'exécuter dans des
environnements différents de faire des appels de méthodes à travers un réseau.
 Il permet d'appeler une fonction sur un serveur distant à partir de n'importe quel
système (Windows, Mac OS X, GNU/Linux) et avec n'importe quel langage de
programmation.
 XML-RPC est conçu pour permettre à des structures de données complexes d'être
transmises, exécutées et renvoyées très facilement.
 Document :
 Dans le fichier WSDL, il spécifie les détails des types des documents décrivant la
structure (le schéma) et les types de données complexes échangés par les méthodes
de service qui permettent un couplage faible.
 En utilisant ce style de document, nous pouvons valider les messages SOAP par
rapport à un schéma prédéfini. Il supporte les types de données XML et les modèles.
 55
Structure d’un document
WSDL
 56
WSDL
Interface Implementation

<definitions> <definitions>

<import> <import>

<types> <service>

<message> <port>

<portType>

<binding>
 57
Éléments d’une définition
WSDL
 <types>
 Contient les définitions de types utilisant un système de typage (comme XSD).
 <message>
 Décrit les noms et les types d’un ensemble de champs à transmettre
 Paramètres d’une invocation, valeur du retour, …
 <porttype>
 Décrit un ensemble d’opérations. Chaque opération à zéro ou un message en
entrée, zéro ou plusieurs messages de sortie ou de fautes
 <binding>
 Spécifie une liaison d’un <porttype> à un protocole concret (SOAP1.1, HTTP1.1,
MIME, …). Un <porttype> peut avoir plusieurs liaisons !
 <port>
 Spécifie un point d’entrée (endpoint) comme la combinaison d’un <binding> et
d’une adresse réseau.
 <service>
 Une collection de points d’entrée (endpoint) relatifs.
 58
Élément <types>

 Contient les définitions de types utilisant un système de typage (comme XSD)

 Exemple
 59
Élément <message>

 Décrit les noms et types d’un ensemble de champs à transmettre

 Paramètres d’une invocation, valeur du retour, …
 Exemple
<!-- message declns -->
<message name="AddEntryRequest">
<part name="name" type="xsd:string"/>
<part name="address" type="typens:address"/>
</message>

<message name="GetAddressFromNameRequest">
<part name="name" type="xsd:string"/>
</message>

<message name="GetAddressFromNameResponse">
<part name="address" type="typens:address"/>
</message>
 60
Élément <porttype>

 Décrit un ensemble d’opérations.

 Plusieurs types d’opérations
 One-way
 Le point d’entrée reçoit un message (<input>).
 Request-response
 Le point d’entrée reçoit un message (<input>) et retourne un message corrélé
(<output>) ou un ou plusieurs messages de faute (<fault>).
 Solicit-response
 Le point d’entrée envoie un message (<output>) et recoit un message corrélé
(<input>) ou un ou plusieurs messages de faute (<fault>).
 Binding HTTP : 2 requêtes HTTP par exemple
 Notification
 Le point d’entrée envoie un message de notification (<output>)
 Paramètres :
 Les champs des messages constituent les paramètres (in,out, inout) des
opérations
 61
Élément <porttype>

 Exemple
<!-- port type declns -->
<portType name="AddressBook">

<!– One way operation -->

<operation name="addEntry">
<input message="AddEntryRequest"/>
</operation>

<!– Request-Response operation -->

<operation name="getAddressFromName">
<input message="GetAddressFromNameRequest"/>
<output message="GetAddressFromNameResponse"/>
</operation>

</portType>
 62
Élément <binding>

 Exemple de binding sur SOAP et HTTP

<!-- binding declns -->

<binding name="AddressBookSOAPBinding" type="AddressBook">
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="addEntry">
<soap:operation soapAction=""/>
<input> <soap:body use="encoded" namespace="urn:AddressFetcher2"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </input>
<output> <soap:body use="encoded" namespace="urn:AddressFetcher2"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </output>
</operation>
<operation name="getAddressFromName">
<soap:operation soapAction=""/>
<input> <soap:body use="encoded" namespace="urn:AddressFetcher2"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </input>
<output> <soap:body use="encoded" namespace="urn:AddressFetcher2"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/></output>
</operation>
</binding>
 63
Élément <binding>

 Exemple de binding avec SOAP et SMTP

<definitions ...>
<types>
<schema targetNamespace="http://stockquote.com/stockquote.xsd"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="SubscribeToQuotes">
<complexType><all><element name="tickerSymbol" type="string"/></all></complexType></element>
<element name="SubscriptionHeader" type="uriReference"/>
</schema>
</types>
<message name="SubscribeToQuotes">
<part name="body" element="xsd1:SubscribeToQuotes"/>
<part name="subscribeheader" element="xsd1:SubscriptionHeader"/>
</message>
<portType name="StockQuotePortType">
<operation name="SubscribeToQuotes">
<input message="tns:SubscribeToQuotes"/>
</operation>
</portType>
 64
Élément <binding>

…
<binding name="StockQuoteSoap" type="tns:StockQuotePortType">
<soap:binding style="document" transport="http://stockquote.com/smtp"/>
<operation name="SubscribeToQuotes">
<input message="tns:SubscribeToQuotes">
<soap:body parts="body" use="literal"/>
<soap:header message="tns:SubscribeToQuotes" part="subscribeheader"
use="literal"/>
</input>
</operation>
</binding>
<service name="StockQuoteService">
<port name="StockQuotePort" binding="tns:StockQuoteSoap">
<soap:address location="mailto:subscribe@stockquote.com"/>
</port>
</service>
</definitions>
 65
Élément <service>

 Une collection de points d’entrée (endpoint)

 Exemple :
<?xml version="1.0" ?>
<definitions name="urn:AddressFetcher"
targetNamespace="urn:AddressFetcher2"
xmlns:typens="urn:xml-soap-address-demo"
xmlns:xsd="http://www.w3.org/1999/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
…
<!-- service decln -->
<service name="AddressBookService">
<port name="AddressBook" binding="AddressBookSOAPBinding">
<soap:address location="http://www.mycomp.com/soap/servlet/rpcrouter"/>
</port>
</service>
</definitions>
 Service web avec
l’architecture REST
 67
Introduction

 REST est l'acronyme de REpresentational State Transfer.

 REST est un style architectural permettant de développer des
applications accessibles via le réseau.
 Le style architectural de REST a été mis en lumière par Roy
Fielding dans sa thèse de doctorat en 2000.
 68
Les services Web Restful

 Les services Web Restful sont une architecture client-serveur

dans laquelle les services Web sont des ressources et peuvent être
identifiés par leurs URI.
 Les applications client REST peuvent utiliser des méthodes HTTP (POST,
GET, PUT et DELETE) pour effectuer les opérations de base du service
CRUD.
 REST ne spécifie aucun protocole spécifique à utiliser, mais dans
presque tous les cas, il est utilisé via HTTP / HTTPS.
 Comparés aux services Web SOAP, ils sont légers et ne respectent
aucune norme.
 Nous pouvons utiliser XML, JSON ou Texte pour la demande et la
réponse.
 69
Exemple d’une URI
 70
Web Service REST
 71
Exemple de Requête/Réponse
REST
72
 73
API de services Web Java
RESTful

 L'API Java pour les services Web RESTful (JAX-RS) permet de créer
des services Web REST.
 JAX-RS utilise des annotations pour simplifier le développement et
le déploiement de services Web.
 JAX-RS fait partie de JDK, vous n'avez donc rien à ajouter pour
utiliser ses annotations.
 74
Annotations sur les services
Web Restful

 Certaines des annotations importantes de JAX-RS sont les

suivantes :
 :@Path utilisé pour spécifier le chemin relatif de la classe et des
méthodes. Nous pouvons obtenir l'URI d'un service Web en analysant la
valeur d'annotation de chemin.
 @GET, @PUT, @POST, @DELETE, @HEAD: utilisé pour spécifier le type
de requête HTTP pour un procédé.
 @Produces, @Consumes: utilisé pour spécifier les types de demande et
de réponse.
 75
Exemple d’une architecture
avec serveur REST

PHP,
JEE,
.Net,
NodeJS
 76
Services Web Rest vs SOAP

 SOAP est un protocole tandis que REST est un style architectural.

 Les applications serveur et client SOAP sont étroitement liées et liées
au contrat WSDL alors qu'il n'y a pas de contrat dans les services
Web REST et le client.
 La courbe d'apprentissage est facile pour REST par rapport aux
services Web SOAP.
 Les types de demande et de réponse de services Web REST peuvent
être XML, JSON, texte, etc., tandis que SOAP fonctionne uniquement
avec XML.
 JAX-RS est l'API Java pour les services Web REST, tandis que JAX-WS
est l'API Java pour les services Web SOAP.
To be continued !