Service et Cloud Computing

1
Plan du cours
 Introduction
 Le paradigme SOC(Service Oriented Computing)
 Le concept de service
 L’architecture orientée service
 La technologie des Services Web
 La pile de protocoles de la technologie des services Web
 SOAP (Simple Object Access Protocol)
 WSDL (Web Services Description language)
 UDDI (Universal Description , Discovery and Integration)
 BPEL4WS (Business Process Execution Language for web services)
 Les ESB (Enterprise Service Bus)
 Les plateformes de développement des services Web
 Les services Web REST
 Cloud Computing

2
Quelques Références
 Pr.Michael Papazoglou (Senior Professor, Executive
Director of the European Research Institute in Service
Science)

3
Quelques Références
 Pr .Athman Bouguettaya (IEEE Fellow, Head of School,
Computer Science & Info Tech, RMIT university, Australia)

4
Introduction
Les systèmes d’Informations d’entreprises doivent
relever de nombreux Challenges :
 Interopérabilité et intégration des systèmes
 comment faire collaborer des systèmes dans des
environnements hétérogènes?
 Réutilisabilité :
 comment réutiliser des applications déjà
existantes ?
 Agilité
 la capacité de répondre pertinemment aux
changements métiers et technologiques
 Facilitation de l’ Evolution et de la maintenance

5
Introduction
Dans l’objectif de relever les défis des systèmes d’informations
d’entreprise, plusieurs paradigmes ont été définis :
 Paradigme Procédure
 Procédure , fonctions et données structurées
 Le paradigme Objet
 Classes (fonctions et données structurées)
 Le paradigme Composant (CBSE-Component Based Software
Engineering)
 composant (groupe d’interfaces) :
 Assemblage de composants
 Le paradigme SOC (Service Oriented Computing)
 Service
 Service Oriented architecture (SOA)

6
Introduction
Service Oriented Computing
(SOC)
Cloud
Computing :
❖ Software as
SOA Service
Services Web ❖ Platform as
Service
❖ Infrastructure
BPEL as Service
WSDL
UDDI
SOAP
HTTP FTP

7
Le Paradigme SOC
 SOC permet le développement des systèmes d’information distribués, flexibles, agiles et
interopérables.

 Le paradigme SOC se base sur le concept de Service et sur une architecture appelée SOA (Service
Oriented Architecture)

 Un service est défini comme une entité informatique indépendante des plateformes, auto-
contenue (n’a pas besoin d’aucun composant installé au niveau client) et autonome permettant
le support de la composition des applications distribuées en couplage faible tout en optimisant
les coûts et les délais
 (SOA-Service Oriented Architecture) est un style d’architecture dont l’objectif est d’organiser
un ensemble d’applications isolées, en un ensemble de services interconnectés, chacun étant
accessible à travers des interfaces et des protocoles de communication standards.

 La technologie des services web constitue une implémentation de l’architecture SOA.

 Elle définit un ensemble de standards et de protocoles fournissant ainsi une infrastructure assurant
des fonctionnalités de transport, de messagerie (SOAP), de description (WSDL), de découverte et de
publication (UDDI) et de composition de services (BPEL4WS)

8
Caractéristiques du service
 Chaque service possède une implémentation et un contrat (
description de service ou spécification de service)
 Les services sont autonomes
 Les clients et les services ne partagent que des contrats
 Les services communiquent entre eux ou avec leurs clients en
utilisant des messages

Service
Application 1 Message à traiter

Application 2 Contrat Implémentation

Message traité
Service 1

Service 2

9
Architecture Orientée Services

Annuaire
de Services

Découverte Publication

Invocation Fournisseur description

Client
du Service
du Service
Service

10
Architecture Orientée Services
 Le fournisseur de services crée le service, puis publie sa
description (son interface, les informations d'accès au
service, …) dans un annuaire de services Web.

 L'annuaire de services rend disponible l'interface du

service ainsi que ses informations d'accès, pour les
demandeur potentiel de service.

 Le demandeur de services 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.
11
Plan du cours
 Introduction
 Le paradigme SOC(Service Oriented Computing)
 Le concept de service
 L’architecture orientée service
 La technologie des Services Web
 La pile de protocoles de la technologie des services Web
 SOAP
 WSDL
 UDDI
 BPEL
 ESB
 Les plateformes de développement des services Web

12
Technologie des services Web
 La technologie des services web constitue une
implémentation de l’architecture SOA
 Evolution du Web des usagers au Web des
communications entre applications

WEB Data General Data General

WEB Data General

Usager +
Navigateur Web Serveur Web Application 1 Application 2

Communications entre Communications

un usager et une application entre applications

L’entité principale est l’usager. L’entité principale est l’application.

Ex : Achat d’un livre via les Ex : Achat automatisé de
pages Web d’une compagnie fournitures (via un Web Service)
13
Technologie des services Web
 Limites des middlewares "traditionnels"
 Mono-langage : Java RMI,
 Mono-plateforme : DCOM sous Windows,
 Complexe à mettre en œuvre : CORBA.
 Adaptation des architectures réparties au contexte
de l’Internet où le Web est considéré comme un
nouveau middleware.
 Multi-langage, Multi-plateforme,
 Spécification garantie par un organisme
indépendant,
 Simple à mettre en œuvre.

14
Technologie des services Web
 «Un service Web est un système logiciel identifié
par un identificateur uniforme de ressources
(URI), dont les interfaces publiques et les liens
(binding) sont définis et décrits en XML. Sa
définition peut être découverte
dynamiquement par d’autres systèmes logiciels.
Ces autres systèmes peuvent ensuite interagir avec
le service Web d’une façon décrite par sa
définition, en utilisant des messages XML
transportés par des protocoles Internet ».[W3C]

15
Technologie des services Web
 Caractéristiques d’un service web
 Mise à disposition sur l’Internet ou sur un réseau privé
(Intranet),
 Auto-descriptive, publiable et accessible en utilisant le
langage XML et les protocoles standards du Web,
 Indépendante du système d’exploitation et du langage
de programmation,
 Visant à exposer une ou plusieurs fonctionnalités
(souvent commerciale(s)) d’une entreprise.

16
Technologie des services Web
 Le modèle des Web Services est défini par une architecture
et un ensemble de protocoles standardisés : SOAP, WSDL,
UDDI.
 Spécifications garanties par W3C et OASIS,
 Objectifs du modèle
 Modularité,
 Réutilisation et composition de services,
 Interopérabilité,
 Dialogue entre environnements et plate-formes hétérogènes,
 Couplage faible (communications synchrones/asynchrones),
 Intégration,
 Intégration du système d’information au sein et en dehors de
l’entreprise,
 Masquage de la complexité.

17
Pourquoi les Services Web ?
 Pour l’entreprise, disposer des services, c’est avant tout
ouvrir son système d’information à d’autres usages ,
d’autres besoins et d’autres clients extérieurs à
l’entreprise
 Les services web permettent d’automatiser facilement
les processus métiers
 Les services Web permettent d’intégrer, gérer et
automatiser rapidement les processus métiers intra et
interentreprises en échangeant des formats XML

18
Pourquoi les Services Web?
 Les services Web permettant de faciliter l’intéropérabilité
entre systèmes et plateformes hétérogènes
 La mise en place des services web facilite le dialogue entre
environnements hétérogènes
 Les services deviennent un moyen technique intéressant
pour interconnecter des modules s’executant sur des
plateformes hétérogènes

19
 Pourquoi les Services Web?
 Les services web facilitent l’intégration d’applications
 Intégration d’application intra entreprise
 Intégration inter entreprise

20
Exemple d’utilisation : l’agence de voyage

21
SOA pour les Web Services
Annuaire UDDI
De Web Services
Description Description
WSDL Description WSDL
WSDL
Description
WSDL
Découverte Publication

Fournisseur
Service Web
Description
Client Description
Réservation
WSDL de Web Services
Séjour
WSDL

du Web Service
Invocation Description
Proxy Web
Service WSDL
Application
Protocole SOAP
Description
WSDL

22
23
La pile des protocoles des services
Web
Composition de services
WS-BPEL, WS-CDL

Découverte/Publication
UDDI

Management
Robustesse
Sécurité
Description
Base
WSDL
Echange
SOAP
Transport
HTTP, SMTP, FTP, JMS

24
 SOAP
Invocation d’un Web Service

Service Web Fournisseur

Description
Client Description
Réservation
WSDL
Séjour de Web Services
WSDL

du Web Service
Invocation Web
Proxy
Application Protocole SOAP
Service

25
Qu’est-ce que SOAP ?
 Définition
 Protocole léger d’échange d’information structurée dans un
environnement distribué,
 Format des messages en XML,
 Transport sur le protocole HTTP (usuellement),
 Ouvert à d’autres protocoles tels que SMTP, FTP, etc.
 Les règles d’encodage (encoding rules)
 Définit le mécanisme de sérialisation permettant de construire le
message pour chacun des types de données pouvant être échangés
 Initiative conjointe de Microsoft et IBM,
 Spécification standard gérée par le W3C
 SOAP 1.2, W3C recommendation W3C, juin 2003,
 SOAP 1.1, W3C note soumise en mai 2000,

26
Echange de messages SOAP
 Modèle d’échange de base
 Message à sens unique (one-way)

Emetteur Message Récepteur

SOAP SOAP SOAP

Transport Transport

 Modèle d’échange implicite

 Requête/Réponse
 Appels RPC Message
SOAP
Emetteur (requête) Récepteur
SOAP Message SOAP
SOAP
Transport (Réponse) Transport
27
Structure d’un message

28
Structure d’un message
 Envelope
 Contenant d’un message,
 Élément racine XML,
 Schéma XML SOAP
SOAPENVELOPE
HEADER
 http://www.w3.org/2002/06/soap-envelope/
 Header (optionnel) HEADER ENTRY
 Entrées non applicatives,
 Ex : Numéros de session.
 Body (obligatoire) SOAP BODY
 Entrées applicatives,
 Ex : nom des procédures,
nom des paramètres, BODY ENTRY
valeurs de paramètres,
 Retour d’erreurs.

29
Structure d’un message
<soap:Envelope
<soap:Header>
... entête...
</soap:Header>
<soap:Body>
... Corps du message...
<soap:Fault>
... Erreurs éventuelles ...
</soap:Fault>
</soap:Body>
</soap:Envelope>

30
Requête SOAP/HTTP
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
Action: "Some-URI"

<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope/"
env:encodingStyle=" http://www.w3.org/2002/06/soap-encoding/"/>
<env:Header>
<t:Transaction xmlns:t="some-URI"> 5 </t:Transaction>
</env:Header>

<env:Body>
<m:GetLastTradePrice xmlns:m="Some-URI">
<symbol> GEM</symbol>
</m:GetLastTradePrice>
</env:Body>
</env:Envelope>

31
Réponse SOAP/HTTP
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<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:GetLastTradePriceResponse xmlns:m="Some-URI">
<Price>34.5</Price>
</m:GetLastTradePriceResponse>
</env:Body>

</env:Envelope>

32
Plan du cours
 Introduction
 Le paradigme SOC(Service Oriented Computing)
 Le concept de service
 L’architecture orientée service
 La technologie des Services Web
 La pile de protocoles de la technologie des services Web
 SOAP
 WSDL(Web Service Description Language)
 UDDI
 Les plateformes de développement des services Web

33
L’architecture de référence des
Web Services
Annuaire UDDI
De Web Services
Description Description
WSDL Description WSDL
WSDL
Description
WSDL
Découverte Publication

Fournisseur
Service Web
Description
Client Description
Réservation
WSDL de Web Services
Séjour
WSDL

du Web Service
Invocation Description
Proxy Web
Service WSDL
Application
Protocole SOAP
Description
WSDL

34
Qu’est-ce que WSDL ?
 Web Service Definition Language
 Langage de description des Web Services
 Description abstraite de l’interface du service,
 Ensemble d’opérations, de messages et de types de données
 Description concrète de l’implantation du service,
 Liaison à des formats de message concrets
 Liaison à des protocoles de transport et des serveurs réseaux

 Document XML (Schéma XML)

 Initiative de Ariba, IBM et Microsoft
 Spécification standard géré par le W3C
 WSDL 1.1, W3C Note, soumise en mars 2001

35
Document WSDL

36
Document WSDL WSDL
<definitions>
 Défini en XML <types>
</types>
<message>
 Structuré comme un ensemble </message>
<porttype>
de définitions </porttype>
…
</definitions>
 élement racine <definitions>
 Modulaire
 Fragmentation des définitions en plusieurs fichiers
 Séparation des descriptions abstraites et concrètes

 Réutilisation de définitions de services

 import d’autres documents WSDL et XSD

<import>
WSDL WSDL
37
Structure d’un document WSDL
 Un service est composé de plusieurs opérations.
 Chaque opération peut avoir une entrée et/ou une
sortie.
 Chacun de ces messages est composé de plusieurs parties.
 Chaque partie est décrite par un type.
 Ces éléments sont associés par des bindings à un protocole
particulier.
 Pour un protocole donné, les opérations associées
constituent un port, associé à une adresse.

38
 É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 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 a zéro ou un message en entrée, zéro
ou plusieurs message 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.

39
 Élément <types>
 Contient les définition de types utilisant un système de typage (comme XSD).
 Exemple
<types>
<schema targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>

40
 É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 name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>

<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePrice"/>
</message>

41
 É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

42
 Élément <portType>
 Exemple

<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>

43
 Élément <binding>
 Exemple de binding sur SOAP et HTTP
 Trois types de bindings :
• SOAP
• HTTP GET & POST
• MIME

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">

<soap:binding style="document“
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation soapAction="http://example.com/GetLastTradePrice"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>

44
Élément <port>
 Port : Associe une addresse (URL) à chaque Binding

<port name="StockQuotePort" binding="tns:StockQuoteBinding">

<soap:address
location="http://example.com/stockquote"/>
</port>

45
 Élément <service>
 Une collection de points d’entrée (endpoint) relatifs
 Exemple :
<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort"
binding="tns:StockQuoteBinding">
<soap:address
location="http://example.com/stockquote"/>
</port>
</service>

</definitions>

46
 Outils
 Générateur WSDL à partir de déploiement SOAP ou EJB, …
 Générateur de proxy SOAP à partir de WSDL
 Toolkits (Wsdl2Java / Java2Wsdl, …)
 Propriétaires (non normalisés)

47
Génération WSDL

48
Plateforme d’implémentation des
services
 Plateforme JEE

 La plateforme .NET

49
Généralités JAX-WS
 JAX-WS est l’acronyme Java API for XML Web Services
 JAX-WS est à la fois un standard et une implémentation
 La version courante est JAX-WS 2.0, précédemment JAX-
WS s’appelait JAX-RPC
 JAX-WS s’appuie sur un ensemble de JSR :
 JSR 224 : JAX-WS
 JSR 181 : Web Services Metadata
 JSR 222 : JAXB
 JSR 250 : Common Annotations
 L’implémentation JAX-WS est intégrée nativement à la JRE
depuis la version 6
 Il est possible de développer des Services Web en dehors
d’un serveur d’application en mode autonome

50
Généralités JAX-WS

51
Généralités JAX-WS
 Le développement de Services Web avec JAX-WS est basé
sur des POJO (Plain Old Java Object)
 Un POJO est un objet Java qui n'implémente aucune
interface particulière ni n'hérite d'aucune classe mère
spécifique
 Les fonctionnalités de base pour le développement de Web
Services avec JAX-WS requiert simplement l’utilisation
d’annotations Java
 Par conséquent aucun fichier de déploiement n’est requis
Toutefois, les fonctionnalités avancées (appels asynchrones)
nécessitent d’utiliser une API JAX-WS permet d’assurer
l’indépendance du protocole (SOAP) et du transport
(HTTP)

52
Généralités JAX-WS
 Deux façons pour développer un Service Web avec JAX-WS
 Approche Top / Down (à partir d’un document WSDL)
 Génération des différentes classes Java (JAXB et squelette du
Web Service) en utilisant l’outil wsimport
 Compléter le squelette de classe de l’implémentation
 Compiler, déployer et tester
 Approche Bottom / Up (à partir d’un POJO)
 Créer et annoter un POJO
 Compiler, déployer et tester
 Le document WSDL est automatiquement généré

53
L’approche Bottom / Up
 L’approche Bottom / Up consiste à démarrer le
développement à partir d’une classe Java (POJO)
 Ajouter l’annotation @WebService
 Déployer l’application sur un serveur d’application (ou via
directement Java SE 6)
 Le document WSDL est généré automatiquement en
respectant les valeurs par défauts
 URL du WSDL : http://monserveur/app/Service?WSDL
 Toutes les méthodes du POJO sont des opérations du Web
Service
 La surcharge de méthodes n’est pas supportée

54
Exemple d’un web service selon
l’approche Bottom / Up
package ws;

import javax.jws.*;
import javax.jws.soap.SOAPBinding;

@WebService(name="AFCWebServices")
@SOAPBinding(style = SOAPBinding.Style.RPC)
public class MyWebServices
{

@WebMethod
public String hello( String nom )
{
return "Bonjour " + nom + "!";
}

@WebMethod(operationName="indexCorporel")
@WebResult(name = "votre-index")
public double indexCorporel( @WebParam(name="taille") double taille,
@WebParam(name="poids") double poids )
{
return poids / (taille * taille) / 100 * 100;
}
}

55
L’approche Bottom / Up
 Comme indiqué précédemment, la JRE 6 fournit des
API et des outils pour manipuler des Services Web

 L’outil wsgen génère des artifacts (JAXB, WSDL) à

partir de classes Java annotées via JAX-WS

 L’utilisation de cet outil n’est pas obligatoire

puisque cette génération est implicite lors de
l’exécution

56
Développement du client java
 Le développement du client consiste à appeler des
opérations du Service Web à partir d’un programme
Java
 Le client peut être une application développée Java ,
Servlet, EJB
 Possibilité de générer des appels aux Services Web de
manière synchrone et asynchrone
 Le développeur ne manipule que du code Java, le code
XML est caché (JAXB)

57
Développement du client java
 Le développement du client suit une procédure similaire à
l’approche Top/Down où le point de départ est le document
WSDL (via une URL ou via un fichier physique)
 Le développement du client se base sur
 Utilisation explicite de l’outil wsimport pour la génération
du squelette du Service Web
 Génération des classes liées à JAXB
 Génération de classes Service Web (PortType et Service)
 Création d’une instance de la classe Service
 Récupération d’un port via get<ServiceName>Port()
 Invocation des opérations

58
Exemple d’un client d’un service
web
import demo.gen.AFCWebServices;
import demo.gen.MyWebServicesService;

public class Client

{
public static void main( String[] args )
{
AFCWebServices port = new
MyWebServicesService().getAFCWebServicesPort();
System.out.println( port.hello( "Annick" ));
System.out.println(port.indexCorporel( 160.0, 60.0 ) );
}
}
59
Annotations : généralités
 JAX-WS repose sur l’utilisation massive d’annotations pour
la définition d’un Service Web
 Les principales annotations sont les suivantes
 @WebService : POJO implémentant un Service Web
 @WebMethod : Paramétrer une opération
 @WebParam : Paramétrer un message
 @WebResult : Paramétrer un message de sortie
 @WebFault : Paramétrer un message fault
 A noter que seule l’utilisation de l’annotation @WebService est
nécessaire (utilisation de valeurs par défaut)
 Nous détaillerons chacune des annotations de manière à
découvrir les paramètres disponibles

60
Annotations : @WebService
 Annote une classe Java pour définir l’implémentation du
Service Web
 Annote une interface Java pour définir la description du
Service Web
 Attributs de l’annotation @WebService
 String name : nom du Service Web
 String endpointInterface : nom de l’interface décrivant le
Service Web
 String portName : nom du port
 String serviceName : nom du service du Service Web
 String targetNamespace : le namespace du Service Web
 String wsdlLocation : l’emplacement du WSDL décrivant le
Service Web

61
l’annotation : @WebMethod
 Annote une méthode d’une classe Java exposée
comme une opération du Service Web
 Attributs de l’annotation : @WebMethod
 String action : l’action de l’opération. Dans le cas d’un
binding SOAP, cela détermine la valeur de l’action SOAP
 boolean exclude : précise que la méthode ne doit pas
être exposée comme une opération. Ne pas utiliser dans
une interface Java
 String operationName : précise le nom de l’attribut
name défini dans l’élément operation du document
WSDL

62
Annotation : @WebParam
 Décrit la relation entre un paramètre d’entrée d’une
méthode et un message part d’une opération
 Attributs de l’annotation
 boolean header : précise si le paramètre doit être transmis
dans l’en-tête du message (true) ou dans le corps (false)
 WebParam.Mode mode : précise le type d’accès au
paramètre (IN, OUT ou INOUT)
 String name : nom du paramètre
 String partName : le nom du wsdl:part représentant ce
paramètre
 String targetNamespace : l’espace de nommage de ce
paramètre

63
Annotation : @WebResult
 Décrit la relation entre le paramètre de sortie d’une
méthode et un message part d’une opération
 Attributs de l’annotation
 boolean header : précise si le paramètre de sortie doit
être transmis dans l’en-tête du message (true) ou dans le
corps (false)
 String name : nom du paramètre de sortie
 String partName : le nom du wsdl:part représentant
ce paramètre de sortie
 String targetNamespace : l’espace de nommage de ce
paramètre de sortie

64
Service Web avec Java 6
 Précédemment nous avons vu comment développer un client
pour appeler un Service Web
 Le développement serveur est possible directement à partir de
Java SE 6 puisqu’il intègre un serveur Web embarqué
 Inutile de gérer un serveur Web (Tomcat, Glassfish)
 Le déploiement est immédiat
 Les deux approches (Top / Down et Bottom / Up) sont
applicables à ce mode de développement
 Usages :
 Fournir des Services Web à une application type client lourd

 A noter que le développement du client reste similaire à ce

qui a été présenté précédemment

65
Service Web avec Java 6
 Développer une classe Java implémentant le Service Web
(ou à partir d’un WSDL et en utilisant wsimport)
 Ajouter l’annotation @WebService
 Créer explicitement une instance du POJO
 Publier le Service Web par l’intermédiaire de la méthode
 Endpoint.publish(String adresse, Object implementor)
 Le document WSDL est généré automatiquement à
l’exécution de l’application
 URL du WSDL : http://monserveur/service?WSDL
 Toutes les méthodes du POJO sont des opérations du Web
Service
66
Service Web avec Java 6
 La méthode publish est utilisée pour démarrer la publication
du Service Web
 String adresse : adresse de déploiement du Service Web depuis
le serveur Web embarqué (http://localhost:8080/ws)
 Object implementor : instance de l’implémentation du Service
Web
 Différentes méthodes proposées par la classe Endpoint (type
de retour de la méthode publish)
 boolean isPublished() : vérifie si le service est en publication
 void stop() : arrête la publication du Service Web

67
Publication sur le serveur d’un
service web
package ws;

import javax.swing.JOptionPane;
import javax.xml.ws.Endpoint;

public class PublierSurServeur

{
public static void main( String[] args )
{
Endpoint endpoint = Endpoint.publish( "http://localhost:8080/services",
new MyWebServices() );
JOptionPane.showMessageDialog( null, "Eteindre le serveur" );
endpoint.stop();
}
}

68
Exemple d’un web service
package ws;

import javax.jws.*;
import javax.jws.soap.SOAPBinding;

@WebService(name="AFCWebServices")
@SOAPBinding(style = SOAPBinding.Style.RPC)
public class MyWebServices
{

@WebMethod
public String hello( String nom )
{
return "Bonjour " + nom + "!";
}

@WebMethod(operationName="indexCorporel")
@WebResult(name = "votre-index")
public double indexCorporel( @WebParam(name="taille") double taille,
@WebParam(name="poids") double poids )
{
return poids / (taille * taille) / 100 * 100;
}
}

69
Publication sur le serveur d’un
service web
package ws;

import javax.swing.JOptionPane;
import javax.xml.ws.Endpoint;

public class PublierSurServeur

{
public static void main( String[] args )
{
Endpoint endpoint = Endpoint.publish( "http://localhost:8080/services",
new MyWebServices() );
JOptionPane.showMessageDialog( null, "Eteindre le serveur" );
endpoint.stop();
}
}

70
Le client d’un service web
import demo.gen.AFCWebServices;
import demo.gen.MyWebServicesService;

public class Client

{
public static void main( String[] args )
{
AFCWebServices port = new
MyWebServicesService().getAFCWebServicesPort();
System.out.println( port.hello( "Annick" ));
System.out.println(port.indexCorporel( 160.0, 60.0 ) );
}
}
71
Exercice 1
 Réaliser un service Web pour la gestion d’un compte
bancaire

 Réaliser un service Web pour la gestion d’un annuaire

téléphonique

72
Exercice
 Définir un service web calculatrice qui offre les
fonctionnalités suivantes :
 Ajouter (float a, float b)
 Soustraire (float a, float b)
 Multiplier (float a, float b)
 Diviser (float a, float b)

73
Web Service REST
Définition
❑Acronyme de REpresentational State Transfert défini
dans la thèse de Roy Fielding en 2000.
❑REST n’est pas un protocole ou un format,
contrairement à SOAP, HTTP , mais un style
d’architecture inspiré de l’architecture du web
fortement basé sur le protocole HTTP
❑Il n’est pas dépendant uniquement du web et peut
utiliser d’autre protocoles que HTTP
REST ➔ utilisation
➢ Utiliser dans le développement des applications
orientés ressources (ROA)
➢ Les applications respectant l’architecture REST sont
dites RESTful
REST ➔ Statistiques
Statistique d’utilisation des services web REST et SOAP chez
AMAZON
REST ➔ Caractéristiques
 Les services REST sont sans états (Stateless)
 Chaque requête envoyée au serveur doit contenir toutes
les informations relatives à son état et est traitée
indépendamment de toutes autres requêtes
 Minimisation des ressources systèmes (pas de gestion de
session, ni d’état)
 Interface uniforme basée sur les méthodes HTTP
(GET, POST, PUT, DELETE)
 Les architectures RESTful sont construites à partir de
ressources uniquement identifiées par des URI(s)
Requêtes REST
 Ressources
 Identifiée par une URI
(http://www.ensaf.ac.ma/cursus/ginfo/ginfo3)
 Méthodes (verbes) permettant de manipuler les
ressources (identifiants)
 Méthodes HTTP : GET, POST, PUT, DELETE
 Représentation : Vue sur l’état de la ressource
 Format d’échanges entre le client et le serveur (XML,
JSON, text/plain,…)
Ressources
❑Une ressource est un objet identifiable sur le système
➔Livre, Catégorie, Client, Prêt
Une ressources n’est pas forcément un objet matérialisé
(Prêt, Consultation, Facture…)
❑Une ressource est identifiée par une URI : Une URI
identifie uniquement une ressource sur le système ➔
une ressource peut avoir plusieurs identifiants
➔http://ntdp.miage.fr/bookstore/books/1
Clef primaire de la
ressource dans la
BDD
Méthodes (Verbes)
 Une ressource peut subir quatre opérations de bases
CRUD correspondant aux quatre principaux types de
requêtes HTTP (GET, PUT, POST, DELETE)
 REST s’appuie sur le protocole HTTP pour effectuer ces
opérations sur les objets
 CREATE ➔ POST
 RETRIEVE ➔ GET
 UPDATE ➔ PUT
 DELETE ➔ DELETE
Méthode GET
 La méthode GET renvoie une représentation de la
ressource tel qu’elle est sur le système
GET: http://www.ensaf.ac.ma/bookstore/books/1

Statut : 200
Message : OK
Client En-tête : …. Serveur
Représentation : XML, JSON, html,…
Méthode POST
 La méthode POST crée une nouvelle ressource sur le
système
POST: http://www.ensaf.ac.ma/bookstore/books
Corps de la requête
Représentation : XML, JSON, html,…

Client Statut : 201, 204 Serveur

Message : Create, No content
En-tête : …..
Méthode DELETE
 Supprime la ressource identifiée par l’URI sur le Identifiant de la
serveur ressource sur le
serveur
DELETE: http://www.ensaf.ac.ma/bookstore/books/1

Client Statut : 200 Serveur

Message : OK
En-tête : …..
Méthode PUT
 Mise à jour de la ressource sur le système Identifiant de la
ressource sur le
serveur
PUT: http://www.ensaf.ac.ma/bookstore/books/1
En-tête : …..
Corps de la requête : XML, JSON,…

Client Statut : 200 Serveur

Message : OK
En-tête : …..
Représentation
Une représentation désigne les données échangées entre le client et
le serveur pour une ressource:
❑ HTTP GET ➔ Le serveur renvoie au client l’état de la ressource
❑ PUT, POST ➔ Le client envoie l’état d’une ressource au serveur
Peut être sous différent format :
 JSON
 XML
 XHTML
 CSV
 Text/plain
 …..
JSON
JSON « JavaScript Obect Notation » est un format
d’échange de données, facile à lire par un humain et
interpréter par une machine.
Basé sur JavaScript, il est complètement indépendant des
langages de programmation mais utilise des conventions
qui sont communes à toutes les langages de
programmation (C, C++, Perl, Python, Java, C#, VB,
JavaScript,….)
Deux structures :
 Une collection de clefs/valeurs ➔ Object
 Une collection ordonnée d’objets ➔ Array
JSON
Objet
Commence par un « { » et se termine par « } » et
composé d’une liste non ordonnée de paire clefs/valeurs.
Une clef est suivie de « : » et les paires clef/valeur sont
séparés par « , »

{"isbn": 20700542274,
“author": “papazoglou”,
“title": “service oriented
architecture”,

}
JSON
ARRAY
Liste ordonnée d’objets commençant par « [« et se
terminant par « ] », les objets sont séparés l’un de l’autre
par « , ». [
{ "id": 51,
"nom": "Mathematiques 1",
"resume": "Resume of math ",
"isbn": "123654",
"quantite": 42,
"photo": ""
},
{ "id": 102,
"nom": "Mathematiques 1",
"resume": "Resume of math ",
"isbn": "12365444455",
"quantite": 42,
"photo": ""
}
]
JSON
Value
Un objet peut être soit un string entre « ""» ou un
nombre (entier, décimal) ou un boolean (true, false) ou
null ou un objet.
Services Web étendus VS REST
REST
➔Avantages
➔Simplicité de mise en œuvre
➔Lisibilité par un humain
➔Evolutivité
➔Repose sur les principes du web
➔Représentations multiples (XML, JSON,…)
➔Inconvénients
➔Sécurité restreinte par l’emploi des méthodes HTTP
➔Cible l’appel de ressources
WADL
➔Web Application Definition Language est un
langage de description des services REST au format
XML. C’est une spécification duW3C initié par SUN
(www.w.org/Submission/wadl)
➔Il décrit les éléments à partir de leur type (Ressources,
Verbes, Paramètre, type de requête, Réponse)
➔Il fournit les informations descriptives d’un service
permettant de construire des applications clientes
exploitant les services REST.
WADL
Développer des Web Services REST avec JAVA
JAX-RS
 Acronyme de Java API for RestFul Web Services
 Version courante 2.0 décrite par JSR 339
 Depuis la version, il fait partie intégrante de la
spécification Java EE

 Son architecture se repose sur l’utilisation des classes

et des annotations pour développer les services web
JAX-RS ➔ Implémentation
 JAX-RS est une spécification et autour de cette
spécification sont développés plusieurs
implémentations
 JERSEY : implémentation de référence fournie par
Oracle ( http://jersey.java.net )
 CXF : Fournie par Apache ( http://cfx.apache.org )
 RESTEasy : fournie par JBOSS
 RESTLET : L’un des premiers framework implémentant
REST pour Java
JERSEY
 Version actuelle 2.3.1 implémentant les spécifications
de JAX-RS 2.0
 Intégré dans Glassfish et l’implémentation Java EE
(6,7)
 Supportés dans Netbeans
JAX-RS : Développement
 Basé sur POJO (Plain Old Java Object) en utilisant des
annotations spécifiques JAX-RS
 Pas de modifications dans les fichiers de configuration
 Le service est déployé dans une application web
 Pas de possibilité de développer le service à partir d’un
WADL contrairement à SOAP
 Approche Bottom/Up
 Développer et annoter les classes
 Le WADL est automatiquement généré par l’API
Protocole HTTP
 Hyper Text Transfert Protocol
 Protocole permettant d’échanger des informations
entre un client et un serveur utilisant TCP comme
couche de transport
 Version courante 1.1
 Requête HTTP
 Requête envoyée par un client http vers un serveur WWW
Ressource/Document
demandé! Version du protocole
Image, HTML, JSON, utilisée : 1.0 ou 1.1
XML…
Methode de la requete
GET, POST, PUT
<Méthode> <URI> HTTP/<version>
[<Champ d’en-tête> : <valeur>]
Ligne blanche
[Corps de la requête]
Informations
concernant le client
Donnée envoyée au
HTTP, l’utilisateur
serveur, prise en
(cookies, localisation)
compte pour les
requêtes de type POST
ou PUT
 Réponse HTTP
 Réponse du serveur à une requête du client

Statut de la réponse
caractérisé par des Information descriptive
codes prédéfinis par le sur le statut
protocole http :
200/404/500
Version du protocole
utilisée : 1.0 ou 1.1
HTTP / <Version> <Statut> <Commentaire>
Content Type : <Type MIME du contenu>
[<Champ d’en tête>: <valeur>]
Ligne blanche Information sur le type
MIME du contenu:
<Contenu>
XML/html/JSON
Informations
concernant le serveur
Annotation JAX-RS
La spécification JAX-RS dispose d’un ensemble
d’annotation permettant d’exposer une classe java dans
un services web :
❑@Path
❑@GET, @POST, @PUT, @DELETE
❑@Produces, @Consumes
❑@PathParam
JAX-RS : @PATH
❑L’annotation permet de rendre une classe accessible
par une requête HTTP
❑Elle définit la racine des ressources (Root Racine
Ressources)
❑La valeur donnée correspond à l’uri relative de la
ressource Adresse du serveur Ressource
@Path("category")
public class CategoryFacade { http://localhost:8080/Bibliotheque/webresources/category
……
}
Contexte de
Port l’application
JAX-RS : @PATH
❑L’annotation peut être utilisée pour annoter des
méthodes d’une classe
❑L’URI résultante est la concaténation entre le valeur de
@path de la classe et celle de la méthode
@Path("category")
public class CategoryFacade {
@GET
@Produces({MediaType.APPLICATION_XML,
MediaType.APPLICATION_JSON})
@Path("test")
public String hello()
{
return "Hello World!";
}
..
}

http://localhost:8080/Bibliotheque/webresources/category/hello
JAX-RS : @PATH
❑La valeur définie dans l’annotation @Path n’est
forcément un constante, elle peut être variable.
❑Possibilité de définir des expressions plus complexes,
appelées Template Parameters
❑Les contenus complexes sont délimités par « {} »
❑Possibilité de mixer dans la valeur @Path des
expressions @GET
@Consumes ({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
@Produces ({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
@Path("{nom}")
public String hello (@PathParam("nom") String nom){
return "Hello " + nom;
}

http://localhost:8080/Bibliotheque/webresources/category/hello/Miage
@GET, @POST, @PUT, @DELETE

 Permettent de mapper une méthode à un type de requête HTTP

 Ne sont utilisables que sur des méthodes
 Le nom de la méthode n’a pas d’importance, JAX détermine la méthode à
http://localhost:8080/Bibliotheque/webresources/category/test
exécuter en fonction de la requête
@Path("category")
public class CategoryFacade {
@GET
@Produces({MediaType.APPLICATION_XML,
MediaType.APPLICATION_JSON})
@Path("test")
public String hello()
{
return "Hello World!";
} @GET
.. @Consumes ({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
} @Produces ({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
@Path("{nom}")
public String hello (@PathParam("nom") String nom){
return "Hello " + nom;
}

http://localhost:8080/Bibliotheque/webresources/category/Miage
@GET, @POST, @PUT, @DELETE

 Les opérations CRUD sur les ressources sont réalisées

au travers des méthodes de la requête HTTP

/books
GET : Liste des livres
POST : Créer un nouveau livre

GET, POST
/books/{id}
PUT, DELETE GET : Livre identifié par l’id
PUT: Mis à jour du livre identifié par id
DELETE : Supprimer le livre identifié
par id
@GET, @POST, @PUT, @DELETE
@GET
@Produces("application/xml")

public String calculerPi(@QueryParam("Seuil") int N) {

//TODO return proper representation object
double s=0;
for (int i=0; i<N; i++)
s = s + Math.pow(-1, i)/(2*i+1);

return "<calculpi> valeur de PI" + s+ "</calculpi>" ;

}
@Path("somme/{a}")
@GET
@Produces("application/xml")

public String ajouter (@PathParam ("a") float a, @QueryParam ("b") float b )

{
float res = a+b;
return "<somme>"+ res+ "</somme>";
}
Paramètres des requêtes
 JAX-RS fournit des mécanismes pour extraire des
paramètres dans la requête
 Utilisés sur les paramètres des méthodes des ressources
pour réaliser des injections de contenu
 Différentes annotations :
 @PathParam : valeurs dans templates parameters
 @QueryParam : valeurs des paramètres de la requête
 @FormParam : Valeurs des paramètres de formulaire
 @HeaderParam: Valeurs dans l’en tète de la requête
 @CookieParam : Valeurs des cookies
 @Context : Informations liés au contexte de la ressource
Exemple (1)
@Path("/helloWorld/{name}")
public class HelloWorldResource {
@GET
@Produces("text/plain")
public String sayHello(@PathParam("name") String
name) {
return "Hello, " + name;
}
}

109
Exemple (2)- path avec expression
réguliere
@Path("/helloWorld")
public class HelloWorldResource {
@GET
@Produces("text/plain")
@Path("{name: ([a-zA-Z])*}")
public String sayHello(@PathParam("name") String name) {

return "Hello, " + name;

}
}

110