LES WEB SERVICES





SAR--Web Services

26

SOAP

 SOAP 1.0 : 1999, basé sur HTTP  SOAP 1.1 : 2000, plus générique, autres protocoles

 SOAP 1.1 : http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

 SOAP 1.2 : recommandation W3C, 2007

 SOAP 1.2 : http://www.w3.org/TR/soap12/  Indépendance du protocole de transport

 Objectifs visés

 Assurer la communication entre applications d’une même entreprise

(intranet)

 Assurer les échanges interentreprises entre applications et services

Web

 Pour comparaison, SOAP est similaire aux protocoles « RPC »

SAR--Web Services

27

Structure d’un message SOAP

 Messages : « enveloppes » où l’application

met les données à transmettre  Éléments XML avec des sous-

éléments

 Un message SOAP peut être transmis à

plusieurs récepteurs intermédiaires avant d’être reçu par le récepteur final (~chaîne de responsabilité)

 Le format SOAP peut contenir des

messages spécifiques correspondant à des erreurs identifiées par le récepteur

 Structure

 En-tête (optionnelle)

Niveau infrastructure

 Corps (obligatoire)

Niveau application

SAR--Web Services

28

SOAP par l’exemple : Requête vers le service HelloWorld

SAR--Web Services

29

L’enveloppe SOAP

 L’enveloppe est la racine d’un message SOAP identifiée par la balise

<soapenv:Enveloppe>

 La spécification impose que la balise et les sous balises soient explicitement

associées à un namespace  xsi correspond au namespace des types de données connus ;  xsd correspond au namespace du schema du document ;  soapenv correspond au namespace de l’enveloppe (utilisé pour la gestion de

la version SOAP).

 La spécification SOAP définit deux namespaces par défaut

 SOAP-ENV ou soapenv : http://schemas.xmlsoap.org/soap/envelope/  SOAP-ENC : http://schemas.xmlsoap.org/soap/encoding/

 La requête et la réponse ont la même structure

SAR--Web Services

30

En-tête SOAP

 L’en-tête d’un message SOAP est utilisé pour transmettre des informations

supplémentaires sur ce même message

 L’en-tête est défini par la balise <SOAP-ENV:Header>

 L’élément peut être facultatif  Doit être placé avant le corps

 Différents usages de l’en-tête ?

 Informations authentifiant l’émetteur  Contexte d’une transaction  Pour certains protocole de transport (FTP par exemple), l’en-tête peut

être utilisé pour identifier l’émetteur du message

 Un message SOAP peut transiter par plusieurs intermédiaires avant le

traitement par le récepteur final  Pattern « Chaîne de responsabilité »  Zone lecture / écriture par les intermédiaires

SAR--Web Services

31

En-tête SOAP

SAR--Web Services

32

Corps SOAP

 Le corps d’un message SOAP est constitué par un élément

<SOAP-ENV:Body>

 L’élément <SOAP-ENV:Body> peut contenir soit

Une erreur en réponse à une requête (élément <SOAP-

ENV:Fault>)

Des informations adressées au destinataire du message

SOAP respectant un encodage déterminé

 L’encodage des informations est précisé par les bindings du

document WSDL Attribut style (Document et RPC) Attribut use (encoded et litteral)

SAR--Web Services

33

Style RPC ou DOC

SAR--Web Services

34

Corps SOAP

 L’objectif visé par SOAP a été de fournir un mécanisme standardisé pour

l’appel de procédures distant (RPC)

 De ce fait les informations adressées au destinataire de messages SOAP

doivent respecter un certain nombre de conventions

 Appel d’une opération représentée par une struct

 Le nom de la structure est celui de l’opération à appeler  Chaque paramètre de l’opération est défini comme un sous élément

de la structure

 Si un paramètre est un type complexe (Person par exemple) une

nouvelle structure est définie contenant à son tour des sous éléments …

 Le résultat est également représenté par une struct

 Le nom de la structure est celui de l’opération suivi de Response

 Les paramètres sont également structurés

SAR--Web Services

35

Corps SOAP  Exemple : corps de messages SOAP pour appeler des opérations du service

Web Notebook

SAR--Web Services

36

Corps SOAP

 Exemple : corps de messages SOAP pour le résultat des

opérations du service Web Notebook

SAR--Web Services

37

Corps SOAP

 Dans le cas où des données binaires devraient transiter

(comme une image par exemple), il est également possible d’envoyer un message SOAP avec attachement et ce grâce à un message MIME (Multimedia Internet Mail Extension).

 Pour pouvoir référencer une pièce jointe depuis le corps du message SOAP, une URI est utilisée, faisant référence à la pièce jointe.

SAR--Web Services

38

Synchrone ou Asynchrone

SAR--Web Services

39

SOAP transporté par HTTP

 SOAP utilise un protocole de transport pour véhiculer les messages SOAP

de l’émetteur au récepteur  HTTP, SMTP, FTP, POP3 et NNTP

 Le modèle requête/réponse de SOAP convient parfaitement au modèle

requête/réponse HTTP

SAR--Web Services

40

SOAP transporté par HTTP

 Requête SOAP HTTP

 Méthode de type GET ou POST  GET : la requête n’est pas un

message SOAP, seule la réponse l’est,

 POST : requête et réponse sont

des messages SOAP,

 Nécessite un attribut SOAPAction

 Réponse SOAP HTTP

 Exploite les codes retours HTTP  Si code de type 2xx, message

SOAP reçu

 Si code 500, message en erreur,

le corps SOAP doit contenir fault

SAR--Web Services

41

Pourquoi utiliser HTTP ?

 HTTP (HyperText Transfer Protocol): le protocole de communication de

l’Internet, est devenu un standard de facto

 HTTP est disponible sur toutes les plateformes – très rapidement

 HTTP est un protocole simple, qui ne requiert que peu de support pour

fonctionner correctement

 HTTP est un protocole sans connexion

 Peu de paquets sont nécessaires pour échanger des informations

 HTTP offre un niveau de sécurité simple et effectif

 HTTP est le seul protocole utilisable à travers des pare-feux

SAR--Web Services

42

Fonctionnement d’HTTP

 HTTP utilise un protocole requête/réponse basé sur du texte

 La première ligne de la requête contient 3 éléments:

 Verbe : POST/GET/HEAD

 URI : /default.htm

 Protocole : HTTP/1.0 - HTTP/1.1

 La première ligne de la réponse contient 2 éléments:

 État : 200, 4xx, 500,

 Différents états existent. Les principaux sont : 200 (ok), 400 (mauvaise requête),

403 (client non autorisé), 404 (document inexistant), 500 (erreur d’exécution –sur le serveur).

 Phrase : OK, Unauthorized

 Les lignes suivantes contiennent un nombre arbitraire d’entête

 Le “contenu” suit une ligne d’entête vide

 Utilisé essentiellement pour les réponses et pour les requêtes POST

SAR--Web Services

43

Principales méthodes HTTP

SAR--Web Services

44

Traitement des messages SOAP

SAR--Web Services

45

SOAP : encodage/décodage des données

 Un message SOAP contient des données, dont il faut pouvoir déterminer la valeur

 Encodage : donnée vers représentation XML  Décodage : représentation XML vers donnée  Encodage et décodage sont définis de diverses façons

 en général, via schéma XML

SAR--Web Services

46

SOAP UI : outil graphique de tests de Service Web

 SOAP UI est un outil pour tester des Services Web

 www.soapui.org  Disponible pour en standalone ou intégré dans les environnements de

développement (Eclipse, Intellij, Netbeans, Maven, …)

 Peut s’utiliser pour n’importe quelle plateforme de développement

 Fonctionnalités de SOAP UI

 Supporte les Services Web étendus (WSDL + SOAP + UDDI) ou REST  Inspecter des Services Web  Invoquer des Services Web  Développer des Services Web  Simuler des Services Web via des bouchons (mocks)  Effectuer des tests qualités (temps de réponse, …)

SAR--Web Services

47

SOAP UI : outil graphique de tests de Service Web

SAR--Web Services

48

WSDL –Web Service Description Language

 Spécification (09/2000)

 Ariba, IBM, Microsoft

 TR W3C v1.1 (25/03/2001)

 Objectif:

 Décrire/définir

les services comme un ensemble d’opérations et de

messages abstraits relié (bind) à des protocoles et des serveurs réseaux

 Grammaire XML (schema XML)

 Modulaire (import d’autres documents WSDL et XSD)

 Séparation entre la partie abstraite et concrète

SAR--Web Services

49

WSDL –Web Service Description Language

 WSDL (Web Service Description Langage), est un langage de description de

services web en XML.

 Spécification (09/2000)

 Ariba, IBM, Microsoft

 TR W3C v1.1 (25/03/2001)

 Il décrit :

 Les informations sur les fonctions publiques du service web ;  Les types de données utilisés durant l’échange de messages ;  Les différents protocoles aux travers desquels le service est accessible ; et

comment y accéder ;

 Une adresse permettant de localiser le service web.

 Séparation entre la partie abstraite et concrète

 WSDL pourrait décrire n’importe quel protocole de messagerie basé sur XML.  Les documents WSDL ne sont jamais générés par des développeurs, mais le sont grâce à des outils qui automatisent la tâche (par exemple, il existe des outils qui prennent une classe Java et qui créent le WSDL correspondant).

SAR--Web Services

50

Structure d’un document WSDL

portType

SAR--Web Services

51

Exemple de document WSDL

SAR--Web Services

52

Éléments d’une définition WSDL

 <types>

 Contient les définitions de types utilisant un système de typage (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 erreur

 <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.

SAR--Web Services

53

Élément <types> --Exemple

 Description en utilisant XML Schema (XSD).

<!-- type defs --> <types> <xsd:schema targetNamespace="urn:xml-soap-address-demo"

xmlns:xsd="http://www.w3.org/1999/XMLSchema">

<xsd:complexType name="phone">

<xsd:element name="areaCode" type="xsd:int"/> <xsd:element name="exchange" type="xsd:string"/> <xsd:element name="number" type="xsd:string"/> </xsd:complexType> <xsd:complexType name="address"> <xsd:element name="streetNum" type="xsd:int"/> <xsd:element name="streetName" type="xsd:string"/> <xsd:element name="city" type="xsd:string"/> <xsd:element name="state" type="xsd:string"/> <xsd:element name="zip" type="xsd:int"/> <xsd:element name="phoneNumber" type="typens:phone"/> </xsd:complexType> </xsd:schema> </types>

SAR--Web Services

54

Élément <porttype>

 Décrit un ensemble d’opérations.  Plusieurs types d’opérations

 One-way (Unidirectionnel)

 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 SAR--Web Services 55

Web services: Toolkits

 Java

 JAX-WS - https://jax-ws.java.net/

 Axis – http://ws.apache.org/axis/

 Jdeveloper - http://www.oracle.com/technology/software/products/jdev

 PHP

 NuSOAP – http://sourceforge.net/projects/nusoap/

 ASP

 MS .Net (Visual Studio) – http://www.microsoft.com/net/default.mspx

SAR--Web Services

56

Outils

 Des outils pour construire un document WSDL

 Notepad++ (éditeur de texte puisqu’il s’agit d’XML)  Eclipse JavaEE  Netbeans  Visual Studio  … (tous les environnements de développement qui manipulent les

Services Web)

 Des outils pour valider un document WDSL

 www.validwsdl.com

 Des outils pour manipuler un WSDL

 SOAPUI

SAR--Web Services

57

Génération WSDL

SAR--Web Services

58

UDDI –Universal Description, Discovery and Integration

 UDDI (Universal Description, Discovery and Integration) est un standard ayant

pour but la création d’un annuaire distribué de services web.

 Cet annuaire contient :

 Pages jaunes

 Fournisseurs de services (catégorie)

 Catégorisation industrielle

 <nom de la société, adresse>

 Pages blanches

 Fournisseurs de services (nom)

 Pages vertes

 Définition des services fournis

– (processus métier, description de service….)

SAR--Web Services

59

Le modèle de données UDDI

Interface

Implementation

<tModel>

<businessEntity>

<businessService> <businessService>

<bindingTemplate> <bindingTemplate>

<businessService>

<tModel>

<bindingTemplate>

SAR--Web Services

60

Le modèle de données UDDI

 BusinessEntity : pages blanches

 décrivent les organisations ayant publié des services dans le répertoire.

nom de l'organisation, ses adresses (physiques et Web), des éléments de

classification, une liste de contacts, ...

 BusinessService : pages jaunes

 décrivent de manière non technique les services proposés par les différentes

organisations.

le nom et la description textuelle des services ainsi qu'une référence à

l'organisation proposant le service et un ou plusieurs « bindingTemplates ».

 BindingTemplate : coordonnées des services

 la définition du « point d'accès » (suivant les cas, une URL, un numéro de

téléphone, ...) et les éventuels « tModels » associés.

 tModel : description technique des services

 C'est à ce niveau que WSDL intervient comme le vocabulaire de choix pour

publier des descriptions techniques de services.

SAR--Web Services

61

UDDI : <tModel>

 <tModel> représente des méta-données et des interfaces

<tModel xmlns="urn:uddi-org:api" tModelKey="UUID:AAAAAAAA-

AAAA-AAAA-AAAA-AAAAAAAAAAAA">

<name>microsoft-com:creditcheck</name> <description xml:lang="en">Check credit

limits</description>

<overviewDoc> <overviewURL>http://schema.com/creditcheck.wsdl </overviewURL> </overviewDoc> <categoryBag> <keyedReference tModelKey="UUID:CD153257-086A-4237-B336-6BDCBDCC6634" keyName="Consumer credit gathering or reporting

services"

keyValue="84.14.16.01.00"/> <keyedReference tModelKey="UUID:C1ACF26D-9672-4404-9D70-39B756E62AB4" keyName="types" keyValue="wsdlSpec"/> </categoryBag> </tModel>

SAR--Web Services

62

<bindingTemplate>

<bindingTemplate serviceKey="33c3d124-e967-4ab1-

8f51-d93d95fac91a" bindingKey="48f2bc6b-a6de-4be8- 9f2b-2342aeafaaac">

<accessPoint URLType="http">

http://localhost/HelloWorld/Service1.asmx

</accessPoint> <tModelInstanceDetails> <tModelInstanceInfo tModelKey="uuid:64c756d1-

3374-4e00-ae83-ee12e38fae63“/>

</tModelInstanceDetails> </bindingTemplate>

SAR--Web Services

63

L'interface UDDI

 définie sous forme de documents UDDI et implémentée sous forme de Service

Web SOAP.

 Elle est composée des modules suivants :

 Interrogation (« inquiry ») permet de rechercher des informations dans un répertoire UDDI et de lire les différents enregistrements enregistrés suivant le modèle de données UDDI.

 Publication permet de publier des informations dans un répertoire UDDI

conformément à son modèle de données.

 Sécurité utilisée pour obtenir et révoquer les jetons d' authentification

nécessaires pour accéder aux enregistrements protégés dans un annuaire UDDI.

 Contrôle d'accès et propriété (« custody and ownership transfer ») permet

de transférer la propriété d' informations et de gérer les droits d'accès associés.

 Abonnement (« Subscription ») permet à un client de s'abonner à un

ensemble d' informations et d'être avertis lors des modifications de ces informations.

 Réplication interne (noeuds d'un même annuaire) UDDI définit également

l'interface permettant de synchroniser les nœuds d'un même annuaire UDDI.

SAR--Web Services

64

UDDI

 L’UDDI Business Registry est une implémentation complète des

spécifications UDDI. Lancée en mai 2001 par Microsoft et IBM, elle permet maintenant à quiconque d’y chercher des informations et aux sociétés de s’enregistrer.

 UDDI repose sur une architecture distribuée comparable à celle des

serveurs DNS.

 En guise d’exemple :

 http://uddi.microsoft.com ;  http://www.ibm.com/services/uddi.

 L’annuaire UDDI est accessible via des messages SOAP à base de XML

SAR--Web Services

65

Relation entre WSDL et UDDI

 L’interface du service  tmodel

 L’implémentation du service -> Business Service

SAR--Web Services MCAR --Web Services

66

Développement de services Web

JAX-WS

Généralités - Développement de Services Web

 Nous nous intéressons dans ce cours au développement des services Web

 Côté Serveur : code pour le traitement du service Web  Côté Client : code qui permet d’appeler un service Web

 La majorité des langages de programmation orientés Web supportent le

développement de services Web  Java, PHP, C#, C++, …

 Nous nous limitons au langage Java dans ce cours  Différents frameworks de développement de Services Web

 JAX-WS Specification Sun (jax-ws.dev.java.net)  AXIS 1 et 2 Apache (ws.apache.org/axis et ws.apache.org/axis2)  CXF Apache (cxf.apache.org)  XFire Codehaus (xfire.codehaus.org)  JBossWS JBoss (www.jboss.org/jbossws)

SAR--Web Services

68

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

SAR--Web Services

69

Généralités JAX-WS

 L’implémentation de référence est fournie par METRO

appelée également JAX-WS RI (Reference Implementation) Site projet Metro : https://metro.dev.java.net/

 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

SAR--Web Services

70

Généralités JAX-WS

 Le développement de Services Web avec JAX-WS est basé sur des POJO

(Plain Old Java Object)

 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)

SAR--Web Services

71

Comment développer un web service JAX-WS

SAR--Web Services

72

Généralités JAX-WS

SAR--Web Services

73

Développement Serveur : généralités

 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 classes 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é

SAR--Web Services

74

Développement Serveur :Bottom /Up

SAR--Web Services

75

Développement Serveur :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

SAR--Web Services

76

Développement Serveur :Bottom /Up

 Exemple : Implémentation du Service Web HelloWorld

SAR--Web Services

77

Développement Serveur :Bottom /Up

 Exemple (suite) : Implémentation du Service Web HelloWorld

SAR--Web Services

78

Développement Serveur :Bottom /Up

 Exemple : Paramétrer le Service Web HelloWorld

SAR--Web Services

79

Développement Serveur :Bottom /Up

 Exemple (bis) : Paramétrer le Service Web HelloWorld

SAR--Web Services

80

Développement Serveur :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

 Exemples d’utilisation

SAR--Web Services

81

JAXB - Java Architecture for XML Binding

 JAXB est une spécification qui permet de faire correspondre un document XML à un ensemble de classes et vice versa au moyen d'opérations de sérialisation/désérialisation nommées marshaling/unmarshaling.

 La manipulation du document XML se fait en utilisant des objets

précédemment générés à partir d'une DTD pour JAXB 1.0 et d'un schéma XML du document à traiter pour JAXB 2.0.

SAR--Web Services

82

Principe de JAXB

SAR--Web Services

83

Générer XML à partir des objets java avecJAXB

SAR--Web Services

84

Générer des objets java à partir de XML avec JAXB

SAR--Web Services

85

Générer un schéma XML à partir d’une classe avec JAXB

SAR--Web Services

86

Génération des classes à partir d’un schéma XML

SAR--Web Services

87

Quelques annotations

SAR--Web Services

88

Développement Serveur :Bottom /Up

 Un Service Web est déployé dans une application Web (un Service Web par

application Web)

 Différentes catégories de serveur d’application pour gérer les Services Web

avec JAX-WS  Conteneur respectant JSR 109 (Implementing Entreprise Web Services) La gestion du Service Web est transparente et maintenue par le

serveur d’application

Exemple : Glassfish http://jcp.org/en/jsr/summary?id=109  Conteneur nécessitant une gestion par Servlet

Nécessite une configuration explicite du Service Web Exemple : Tomcat Note : un composant additionnel se propose de fournir le support JSR

109 (http://tomcat.apache.org/tomcat-6.0-doc/extras.html)

SAR--Web Services

89

Développement Serveur :Top /Down

SAR--Web Services

91

Développement Serveur :Top /Down

 L’approche Top / Down consiste à démarrer le développement à partir d’un

document WSDL

 Le document WSDL est accessible via une URL ou via un fichier physique

 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 des interfaces WS (interface décrivant le PortType)

 Création d’un POJO annotée @WebService en précisant l’emplacement de

l’interface du portType (Proxy)

 Déployer l’application sur un serveur d’application

 Le reste du processus de développement est identique à celui de l’approche

Bottom / Up

SAR--Web Services

92

Service Web avec Java 6 : généralités

 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

Pour les tests unitaires, fournir des Mock de Services Web

SAR--Web Services

93

Service Web avec Java 6 : serveur

 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

 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

SAR--Web Services

94

Service Web avec Java 6 : serveur

 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

SAR--Web Services

95

Service Web avec les EJB : généralités  A partir d’un EJB Session, il est possible de définir le POJO associé

comme étant un Service Web

 Pour rappel, l’appel à un EJB Session passe obligatoirement par un

client écrit en Java

 Les avantages à transformer un EJB Session en Service Web

Caractéristiques des EJBs (transactions, sécurité, scalabilité, …) Plus grande hétérogénéité, le client n’est pas forcément écrit en

Java

Réutilisabilité du code Modularité (avec les annotations JAXB possibilité de masquer les

méthodes qui ne doivent pas être découvertes)

 Nécessite d’avoir un conteneur EJB pour le déploiement

Glassfish, OpenEJB, …

SAR--Web Services

96

Service Web avec les EJB :serveur

 Partir d’une classe Java définissant un EJB Session (statefull ou stateless)

 Ajouter l’annotation @WebService

 Déployer l’application sur un serveur d’application ayant le support EJB

(Glassfish par exemple)

 Le conteneur EJB s’occupe de la gestion du Service Web, aucune Servlet

n’est nécessaire

 Le document WSDL est généré automatiquement en respectant les valeurs

par défaut  URL du WSDL : http://monserveur/app/Service?WSDL

 Toutes les méthodes de l’EJB sont par défaut des opérations du Service Web

SAR--Web Services

97

Développement Client Java

SAR--Web Services

98

Développement 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 SE (Swing, Eclipse RCP)  Java EE avec les EJB (JSP, Servlet, …)

 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)

SAR--Web Services

99

Développement Client Java : Exemple

SAR--Web Services

100

Service Web avec les EJB : client

 Le développement du client est similaire au client développé

précédemment où le point de départ est le document WSDL (via une URL ou via un fichier physique)

 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)

 Injecter un @WebServiceRef pour récupérer une instance du Service à

partir du conteneur EJB

 Récupération d’un port via get<ServiceName>Port()

 Invocation des opérations

SAR--Web Services

101

Annotations : généralités

 JAX-WS repose sur l’utilisation massive d’annotations pour la

configuration d’un Service Web

 JSR utilisées (JSR 224, 222, 181 et 250)

 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)

SAR--Web Services

102

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 : l