Service - e

Transcription

Service - e

Architecture orientée service
Introduction
Définition des services Web


Un service Web est
−
Une interface
−
Qui décrit une collection d'opérations
−
Accessibles par réseau
−
Au travers de messages
−
Standardisés par XML
Famille des architectures distribuées
Architecture distribuée
orientée message/opération
Avantages

Réutilisation

Indépendance
−
Plate-forme

−
Implémentation

−
UNIX, Windows, ...
C#, Java, VB, ...
Architecture

Axis, Java EE, .NET, ...
Intention


Ce qu'a fait le Web pour les utilisateurs, les
services Web le font pour les applications
Nouvel horizon pour les entreprises
−
Réduction du coût des applications
−
Déploiement plus rapide
−
Développement plus facile
Pourquoi





Pour fournir un service au public ou à des
entreprises
Les utilisateurs peuvent utiliser différents
langages (C#, Java, etc.)
Les utilisateurs peuvent utiliser différents
systèmes d'exploitation (Linux, Windows, etc.)
Les utilisateurs appellent les services via
Internet
Le service peut passer au travers des pare-feux
Types d'application



B2C
−
Business To Consumer
−
Applications pour les consommateurs
B2B
−
Business To Business
−
Applications pour les entreprises
A2A
−
Applications intra-entreprise
−
Intégration d'applications
Standards

Protocole HTTP

Extensible Markup Language (XML)

Simple Object Access Protocol (SOAP)

Web Services Description Language (WSDL)

Universal Description Discovery and Integration
(UDDI)
Accessibilité
Serveur
Serveur Web : http://www.serveur.fr
Service
Service Web : /Service
Opération A
http://www.serveur.fr/Service
Internet
Opération B
Système de noms

Espace de noms (namespace)
−
Équivalent à un paquetage Java
−
Doit être unique
−
Exemple


Nom local (local name)
−

http://www.serveur.fr/unnom/Service
Ici Service est un nom local
Nom qualifié (Qname)
−
Toute l'URL : http://www.serveur.fr/unnom/Service
Mots clefs

Message et opération

Protocole

Binding

URI ou endpoint

Interface

Service

Ressource
Interfaces et bindings
Concepts



L'intégration des services Web se fait à un
haut niveau dans la pile protocolaire
Les services Web sont basés sur les
messages
−
Plus centrés sur une sémantique de service
−
Moins centrés sur des sémantiques de protocole
réseaux
Intégration souple des fonctions métier
Modèle

Le modèle est basé sur l'interaction de trois
rôles :
−
Le fournisseur de services (Service provider)
−
L'annuaire des services (Service registry)
−
Le consommateur de services (Service requestor)
Modèle de comportement

Le modèle est basé sur trois opérations :
−
Publication (Publish)
−
Recherche (Find)
−
Consommation (Bind)
Rôle, opération et objet
service
Registry
Find
Service
Description
Publish
WSDL, UDDI
WSDL, UDDI
Service
Service
Requestor
Bind
Service
Provider
Service
Description
Rôles en détail


Service provider
−
Le propriétaire du service
−
Plate-forme qui héberge l'accès au service
Service requestor
−
Le demandeur de fonctions, le client
−
Application qui recherche et invoque une interaction
avec un service
−
Un navigateur, une application
Rôles en détail

Service registry
−
L'annuaire de description des services
−
Lieu de publication des fournisseurs de services
−
Lieu de recherche et de découverte des services
pour les Service requestors
−
Rôle optionnel
Protocoles sans annuaire


Un fournisseur de services peut envoyer
directement la description d'un service à un
client (Service requestor)
Un client peut obtenir la description d'un
service par :
−
Un fichier local, un site FTP, un site Web
−
Advertisement and Discovery of Services (ADS)
−
Discovery of Web Services (DISCO)
Opérations en détail

Publier (Publish)
−
Pour être accessible un service Web doit être
publié.
−
Ainsi un client peut le trouver
−
Le lieu de publication est variable

Trouver (Find)
−
Directement
−
Auprès d'un annuaire
−
Deux phases du cycle de vie
Lors de la conception et du développement

Lors de l'exécution (runtime)

−
−
Pour le binding description
Pour la location description

Connecter (Bind)
−
Localiser, contacter et invoquer un service
−
Lors de l'exécution
Objets d'un service Web

Service
−
C'est une interface
−
Décrit par un Service Description
−
Son implémentation est le service lui-même
−
Déployé et accessible via le réseau
−
Existe pour interagir avec ou être invoqué par un
service requestor
−
Il peut lui-même être un requestor
Objets d'un service Web

Service Description
−
Contient le détail de l'interface et de son
implémentation
−
Ceci inclus :
Types de données

Opérations

Informations de connexion (binding)

Localisation sur le réseau

−
Peut être publié vers un service requestor ou
dans un service registry
Cycle de vie
1 - je recherche un service WEB
Annuaire
2 – j'ai trouvé voici le serveur Web
hébergeant ce service
3 – quel est le format d'appel du
service que tu proposes ?
4 – voici mon contrat (WSDL)
Client
5 – j'ai compris comment invoquer
ton service et je t'envoie un document
XML représentant ma requête
6 – j'ai exécuté ta requête et
je te retourne le résultat XML
Serveur
Cycle de vie complet
1. Déploiement du service Web
−
Dépendant de la plate-forme (Apache : WSDD)
2. Enregistrement du service Web
−
WSDL : description du service
−
Référentiels : DISCO (local), UDDI (global)
3. Découverte du service Web
4. Invocation du service Web par le client
Architecture
WSFL
static
direct
Service Flow
UDDI
Service Discovery
UDDI
Service Publication
S
WSDL
Service Description
SOAP
XML-Based Messaging
HTTP, FTP, email,
MQ, IIOP, etc.
Network
M QS
La pile Web Services

Réseau (Network)
−

Le protocole HTTP est le standard
Messages XML (XML-Based Messaging)
−
Le protocole SOAP est le standard
−
HTTP POST avec une enveloppe XML
−
Mécanisme standardisé d'enveloppe XML
Message sous forme de document

Invocation de procédure distante (RPC)

La pile Web Services

Description de service
−
Description de documents XML
−
WSDL est le protocole standard
Définit l'interface du service

Autres descriptions

−
−
−
Contexte métier
Qualité de service
Relations entre services
SOAP et messages XML
Service Requestor
Service Provider
Application
Application Web
service
SOAP
SOAP
Network Protocol
Network Protocol
Réponse
Requête
Un message XML SOAP
<SOAPenv:Envelope
xmlns:SOAPenv="http://schemas.xmlSOAP.org/SOAP/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAPenv:Body>
<req:getNumberOfArticles xmlns:req="http://dailymoon.com/CMS/">
<req:category>classifieds</req:category>
</req:getNumberOfArticles>
</SOAPenv:Body>
</SOAPenv:Envelope>
Autres protocoles

Representational State Transfer (REST)
−
Service Web accessible via une simple URL
Spécifications étendues

WS-Security
−

WS-policy
−

Comment et par qui est utilisé le service
WS-I
−

Cryptage et signature numérique
Ensemble de standards pour l'interopérabilité
WS-BPEL
−
Orchestration des services
Protocole SOAP
Introduction
Simple Object Access Protocol


Spécifications
−
Standard W3C
−
http://www.w3c.org/TR/SOAP
Un support pour l'accès à l'information
−
un protocole client-serveur

−
RPC (Remote Procedure Call)
des protocoles de transport
Au dessus de TCP/IP

protocoles HTTP/SMPT/POP

Requête SOAP
Décodage et appel
de la méthode
CLIENT
Internet
LISTENER
Requête SOAP
NOM+PARAMETRES
SERVICE
exécution de la méthode
SERVEUR HTTP
Simple Object Access Protocol

Simple et extensible

Permet le diagnostic des erreurs

Message unidirectionnel

Fonctionne de façon synchrone et asynchrone

Indépendant de la plate-forme et du langage

N'est pas gêné par les pare-feux

Un système de désignation universelle : URL

Une représentation de documents : HTML
Structure SOAP

Enveloppe
−


Entête
−
Optionnelle
−
Permet de spécifier des directives pour le
traitement du message
Corps
−

Permet de spécifier la version SOAP utilisée
Contient les données
Pièces jointes
−
Permet l'envoi de données non XML
Enveloppe SOAP

C'est l'unité de base d'un message

C'est un document XML
−
Avec deux sous-sections

Header et Body
<?xml version='1.0' ?>
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/SOAP-envelope">
<env:Header>
</env:Header>
<env:Body>
</env:Body>
</env:Envelope>
Enveloppe

Élément obligatoire

Permet de spécifier la version
−
en utilisant un espace de nom


http://www.w3.org/2003/05/soap-envelope
Permet de spécifier les règles d'encodage
−
Encoding Style
−
Sérialisation (Marshalling) et désérialisation
(Unmarshalling)
Exemple de Header SOAP

Contient des informations sur le message
−
Informations de routage
?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/SOAP-envelope">
<env:Header>
<wsa:ReplyTo xmlns:wsa=
"http://schemas.xmlSOAP.org/ws/2004/08/addressing">
<wsa:Address>
http://schemas.xmlSOAP.org/ws/2004/08/addressing/role/anonymous
</wsa:Address>
</wsa:ReplyTo>
<wsa:From>
<wsa:Address>
http://localhost:8080/axis2/services/MyService</wsa:Address>
</wsa:From>
<wsa:MessageID>ECE5B3F187F29D28BC11433905662036</wsa:MessageID>
</env:Header>
<env:Body>
</env:Body>
</env:Envelope>
<
Entête

Élément optionnel

Contient des éléments spécifiques à l'application

Peut contenir 3 types d'éléments
−
Actor

−
Permet de préciser le destinataire final du message
MustUnderstand
Spécifie que le récepteur doit comprendre cet élément

Si ce n'est pas le cas il arrête tout traitement

−
Encodingstyle

Même définition que pour l'enveloppe
Exemples
Actor
<m:Trans xmlns:m="http://www.w3schools.com/transaction/"
soap:actor="http://www.w3schools.com/appml/">
MustUnderstand
<m:Trans xmlns:m="http://www.w3schools.com/transaction/"
soap:mustUnderstand="1">234</m:Trans>
Header SOAP

Contient des informations sur le message
−
Comment le message peut être traité par des
intermédiaires


Le protocole SOAP ne garantit pas qu'un message soit
directement échangé entre un client et un serveur
Il peut y avoir d'autres informations dans le Header
Body SOAP

Contient l' information pour dire au récepteur du
message de faire quelque chose

Cette information est appelée « payload »

Le Body possède son propre espace de nom

−
Arbitraire en fonction du contexte applicatif
−
Mais différent de celui de SOAP
Le choix de structuration du « payload » dépend
du style et de l'encodage
Exemple de Body SOAP
?xml version='1.0' ?>
<env:Header>
...
</env:Header>
<env:Body>
<cms:addArticle xmlns:cms="http://www.daily-moon.com/cms">
<cms:category>classifieds</category>
<cms:subcategory>forsale</cms:subcategory>
<cms:articleHeadline></cms:articleHeadline>
<cms:articleText>Vintage 1963 T-Bird. Less than 300 miles.
Driven by my daughter until I took it away. Serious inquires only.
555-3264 after 7 PM.</cms:articleText>
</cms:addArticle>
</env:Body>
</env:Envelope>
<
SOAP Message Structure
SOAP Message
HTTP Headers
SOAP Envelope
SOAP Header
Headers
SOAP Body
Method calls & Data
Le message SOAP complet
Entête standard HTTP et
entête SOAP HTTP
Enveloppe
Entête
Entête individuelle
Corps qui contient les appels
de méthodes SOAP
Appel des méthodes et description
en XML des données
Réponse SOAP


Le retour du service
−
Réponse
−
Erreur (SOAP FAULT)
Exemple de réponse
<?xml
version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body>
<m:GetPriceResponse xmlns:m="http://www.w3schools.com/prices">
<m:Price>1.90</m:Price>
</m:GetPriceResponse>
</soap:Body>
</soap:Envelope>
SOAP Fault

Réponse SOAP

Fait partie du corps d'un message SOAP

Envoyé à l'émetteur de l'appel
−

Indique les raisons de l'échec
Il existe 4 descripteurs (Faultcode)
−
Version Mismatch
−
MustUnderstand
−
Client
−
Server
Style et encodage


Style RPC
−
Utilise SOAP pour créer des Remote Procedure Calls
−
Invocation d'une méthode avec ses paramètres
−
Types des paramètres
Style document/literal
−
Simple liste de paramètres
−
Pas de détail sur le processus qui les prend en
charge
Exemple de style RPC
<env:Header>
</env:Header>
<env:Body>
<cms:addArticle xmlns:cms="http://www.daily-moon.com/cms">
<cms:category xsi:type="xsd:string">classifieds</category>
<cms:subcategory xsi:type="xsd:string">forsale
</cms:subcategory>
<cms:articleHeadline xsi:type="xsd:string" />
<cms:articleText xsi:type="xsd:string">Vintage 1963
T-Bird. Less than 300 miles. Driven by my daughter until
I took it away. Serious inquires only. 555-3264 after 7
PM.</cms:articleText>
</cms:addArticle>
</env:Body>
</env:Envelope>
Style document/literal
<env:Header>
</env:Header>
<env:Body>
<category>classifieds</category>
<subcategory>forsale</subcategory>
<articleHeadline></articleHeadline>
<articleText>Vintage 1963 T-Bird. Less than 300 miles.
Driven by my daughter until I took it away. Serious
inquires only. 555-3264 after 7 PM.</articleText>
</env:Body>
</env:Envelope>
Motifs d'échange de messages

Envoi d'une requête et attente de réponse

Envoi d'une requête et oubli

Échange via des intermédiaires

Options possibles
−
Request-Response
−
One-Way
−
Solicist-Response
−
Notification
Portée de SOAP

SOAP est simple et extensible
−
−
−
−
−
Il permet de réaliser des appels de méthode sur
le Web
Indépendant des OS, des modèles d'objets, des
langages
Transport des message par HTTP + XML
Fonctionne avec l'infrastructure Internet existant
Permet l'interopérabilité entre OS, langages et
modèles objets
Portée de SOAP

Ce n'est pas un système reparti à objets, il
ne couvre donc pas les fonctions suivantes:
−
−
−
−
−
Pas de ramassage de miettes
Pas de contrôle de types, pas de gestion de
version
Pas de dialogue entre deux serveurs HTTP
Pas de passage d'objets par référence
Pas d'invocation
WSDL
Introduction
Web Service Description
Language

C'est le langage de définition des services

Permet de définir le contrat de service

Historique
−
IBM a développé le langage Network Accessible
Service Specification Language (NASSL)
−
Microsoft a développé SOAP Contract Language
( SCL) qui est une évolution de SDL
−
WSDL est la fusion de SCL et de NASSL
Versions WSDL

Première version
−
Version V1.1 (15 Mars 2001)


http://www.w3.org/TR/wsdl
Seconde version
−
Version V1.2 (Working Draft, 3 Mars 2003)

http://www.w3.org/TR/wsdl12
Objectif et représentation

Objectif
−

Décrire les services comme un ensemble
d’opérations et de messages abstraits relié
(bind) à des protocoles et des serveurs réseaux
Grammaire XML (schéma XML)
−
Modulaire (import d’autres documents WSDL et
XSD)
Définition



Une description en XML des services web.
Il décrit de manière abstraite et indépendante
du langage de programmation l’ensemble des
fonctionnalités offertes par un service.
Il permet de connaître
−
les protocoles, les serveurs, les ports
−
le format des messages, les entrées, les sorties
−
les exceptions possibles
−
les opérations réalisées par un service web.
Découplage
Interface/Implémentation
Service
Implementation
Definition
Service
Port
Binding
Service
Interface
Definition
PortType
Message
Type
Pourquoi



Pour décrire les informations à envoyer au
service
Pour décrire les informations que le service
retourne
Pour indiquer où trouver le service
Éléments WSDL
élément
Description
types
A container for abstract type definitions defined using XML Schema
message
A definition of an abstract message that may consist of multiple parts,
each part may be of a different type
portType
An abstract set of operations supported by one or more endpoints
(commonly known as an interface); operations are defined by an
exchange of messages
binding
A concrete protocol and data format specification for a particular
portType
service
A collection of related endpoints, where an endpoint is defined as a
combination of a binding and an address (URI)
Structure WSDL


Section definitions
−
Elle contient le nom du service
−
Elle contient les espaces de nom faisant
référence aux types utilisés dans le document
Section types
−
Permet la définition des éléments abstraits
−
Utilise généralement la grammaire XSD
−
Présent qu'une fois mais peut contenir plusieurs
définitions
Exemples
Définition :
<definitions name="GetStockQuote
targetNamespace="http://advocatemedia.com/GetStockQuote.wsdl"
xmlns:myns = "http://advocatemedia.com/GetStockQuote.wsdl"
xmlns:myXsd = "http://advocatemedia.com/GetStockQuote.xsd"
xmlns:soap = "http://schemas.xmlsoap.org/wsdl/soap"
xmlns="http://schemas.xmlsoap.org/wsdl/">
</definitions>
Types :
<types>
<schema targetNamespace=http://advocatemedia.com/GetStockQuote.xsd
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="StockQuoteRequest">
<complexType>
<all>
<element name="symbol" type="string"/>
</all>
...
Structure WSDL

Section message
−
Deux types de message
IN et OUT

Si aucun argument alors pas de IN

−
Définition abstraite des messages échangés entre
deux noeuds
−
Peut être composé de plusieurs section part
Exemple
Message :
<message name="GetStockQuoteRequest">
<part name="body" element="myXSD:StockQuoteRequest"/>
</message>
<message name="GetStockQuoteResponse">
<part name="body" element="myXSD:StockQuoteResponse"/>
</message>
Structure WSDL

Section part
−
Il peut être défini comme un type simple ou
complexe ou un element
−
l'ordre des part dépend de la signature de la
méthode
−
Une section element implique une définition
obligatoire dans la section types
Structure WSDL

Section portType
−
Correspond à une interface IDL CORBA
−
Il contient les classes accessibles
−
A chaque portType sont associées des opérations
correspondant aux méthodes
−
Pour chaque méthode on définit le message d'entrée
et de sortie
−
Les opérations peuvent être de natures différentes

Unidirectionnelle, requête/réponse, sollicitation/réponse,
notification
Exemple
PortType :
<portType name="GetStockQuotePort">
<operation name="GetStockQuote">
<input message="myns:GetStockQuoteRequest"/>
<output message="myns:GetStockQuoteResponse"/>
</operation>
</portType>
Structure WSDL

Section binding
−
Permet de spécifier le protocole d'invocation

HTTP GET/POST, SOAP, SMTP, FTP, ...
−
Un portType peut être invoqué par plusieurs
protocoles
−
Possède un nom unique

portType+protocole+binding
Exemple
Binding :
<binding name="GetStockQuoteBindingName" type="GetStockQuotePort ">
<soap:binding style="rpc" transport=" http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetStockQuote">
<soap:operation soapAction="http://advocatemedia.com/GetStockQuote"/>
<input> <soap:body use="literal"/> </input>
<output> <soap:body use="literal"/> </output>
</operation>
</binding>
Structure WSDL

Section service
−
Permet de
spécifier le nom du service

où se trouve la documentation du service

où envoyer le message

−
La section port permet d'indiquer l'adresse URI
−
L'attribut binding permet d'associer le nom du port au
binding du fichier WSDL
−
La section soap:address spécifie l'adresse du service
Exemple
Service :
<service name="AdvocateMediaGetStockQuotes">
<documentation>Simple Web Service to Retrieve a stock quote</documentation>
<port name="GetStockQuotePort" binding="myns:GetStockQuoteBindingName">
<soap:address location="http://advocatemedia.com/GetStockQuote"/>
</port>
</service>
Limitations

Incapacité de décrire des organisations
complexes
−
Les web services sont des tâches simples, il est
donc nécessaire de définir des enchaînements plus
ou moins complexes pour réaliser des tâches
élaborées.
−
D’autres standards pour cela:
ebXML

Business Process Specification Schema (BPSS)

Web Services Choreography Interface (WSCI).

UDDI
Introduction
Universal Description,
Discovery and Integration

Standard
−

Permet aux fournisseurs de services
−


Organisation for the Advancement Of Structured
Information Standard » (avril 2003)
De s’inscrire et de répertorier les services qu’ils
proposent.
Ne contient que des références associées à
des services, et non les services eux-mêmes
Il peut être public ou privé
Hébergement



Les annuaires publics sont hébergés par des
sociétés comme IBM ou Microsoft.
Les annuaires publics
−
moins développés que les annuaires privés
−
pas suffisamment sécurisés.
Les annuaires privés
−
peuvent être hébergés par une société quelconque
−
sur un réseau privé ou sur internet
Messages entre client
et annuaire
Annuaire UDDI
Client
Requête SOAP UDDI
HTTP Serveur
SOAP Serveur
UDDI API
Réponse SOAP UDDI
données
Structure

Pages vertes
−
Contiennent les informations techniques
détaillées sur les services

Processus métier, description de service, etc.
Structure

L’annuaire UDDI est composé de

Pages blanches
−
Contiennent des informations sur l’entreprise


Nom de la société, adresse, etc.
Pages jaunes
−
Contiennent la description des services déployés
par l’entreprise

Au format WSDL
Pages Blanches

BusinessEntity
−
Décrites sous la forme d’un schéma XML
−
Elles contiennent les éléments relatifs à
l’entreprise

Nom, coordonnées, secteur d’activité, l’adresse du
site web, etc.
Pages Jaunes

BusinessService
−
Décrites aussi sous la forme d’un schéma XML
−
Ensemble de services proposés répondant à un
besoin métier spécifique
−
Contiennent des informations relatives au métier
de l’entreprise.
−
Contiennent aussi la description des services
web proposés

−
Nom du service, description, code, etc.
Une entreprise peut avoir plusieurs métiers et
donc plusieurs businessService.
Pages Vertes

BindingTemplate
−
Contiennent les informations techniques pour
accéder à un service
−
Contiennent aussi les références aux tModels

Spécification des interfaces des services
Les tModels

Représentés par un schéma XML

Représentent les Méta-données et interfaces

Ils contiennent des informations permettant de
connaître
−
Les normes que respecte le service
−
Le format des messages
−
Le protocole de transport
−
etc.
Les tModels

Permettent d’identifier la catégorie à laquelle
appartient le service
−
North American Industry Classification System
( NAICS)
−
Universal Standards Products and Services
Classification (UNSPSC)
−
ISO 3166

Standards pour la localisation géographique
PublisherAssertion



Introduite dans la version 2.0
Représente un ensemble de règles
contractuelles d’invocation de services sous
forme de protocoles entre deux partenaires
métier
Pour qu’une assertion soit publiée, les deux
partenaires doivent publier les mêmes
informations.
Découverte de services



Les standards UDDI sont implémentés dans des
API, permettant l’accès et la manipulation
Il existe deux types d’API
−
API d’interrogation
−
API de publication
La communication avec les registres UDDI se fait
par des messages XML encapsulés dans des
enveloppes SOAP
Relation entre UDDI et WSDL

Le WSDL contient deux parties
−
La description de l’interface du service
−
La description de l’implémentation du service

La description de l’interface d’un service
−
Correspond aux informations techniques du service

−
C’est en quelque sorte une classe abstraite qui sera
utilisée pour implémenter un ou plusieurs autres services.
Elle regroupe

types, import, message, portType, binding

La description de l’implémentation du service
−
Correspond aux informations relatives à l’endroit
où est publié le service
−
Elle regroupe

Documentation, import, service, port
Sécurité
Introduction
Problèmes de sécurité

Authentification

Autorisation

Confidentialité

Intégrité
Techniques de sécurité

Chiffrement et déchiffrement
−

Conversion des données en une forme
inintelligible.
Signatures
−
Pour trouver l’auteur d’un message.

Certificats

Couche physique
Clients SOAP
Avec les produits Axis et Axis2
Deux implémentations

Ancienne manière
−
Le client doit entièrement créer l'enveloppe SOAP


Header et Body
Nouvelle manière
−
Masque la complexité
−
Avec Axis2 il y a le modèle AXIOM
Ressemble à l'API DOM XML

C'est Axis2 qui construit l'enveloppe SOAP

Exemple ancienne manière
public class SendSOAP {
public static void main(String args[]) {
try {
MessageFactory messageFactory = MessageFactory.newInstance();
SOAPMessage message = messageFactory.createMessage();
//Create objects for the message parts
SOAPPart SOAPPart = message.getSOAPPart();
SOAPEnvelope envelope = SOAPPart.getEnvelope();
SOAPBody body = envelope.getBody();
SOAPElement bodyElement =
body.addChildElement(envelope.createName("echo",
"req", "http://localhost:8080/axis2/services/MyService/"));
bodyElement.addChildElement("category").addTextNode("classifieds");
message.saveChanges();
SOAPPart SOAPpartbefore = message.getSOAPPart();
SOAPEnvelope reqenv = SOAPpartbefore.getEnvelope();
System.out.println("REQUEST:");
System.out.println(reqenv.toString());
Exemple (suite)
//Now create the connection
SOAPConnectionFactory SOAPConnFactory =
SOAPConnectionFactory.newInstance();
SOAPConnection connection =
SOAPConnFactory.createConnection();
SOAPMessage reply = connection.call(message,"
http://localhost:8080/axis2/services/MyService");
SOAPPart SOAPpart = reply.getSOAPPart();
SOAPEnvelope replyenv = SOAPpart.getEnvelope();
System.out.println("\nRESPONSE:");
System.out.println(replyenv.toString());
connection.close();
} catch (Exception e){ System.out.println(e.getMessage()); }
}
}
Compilation et exécution

Il faut compiler ce client avec les librairies de
l'ancienne version d'Axis
−
Le produit Axis fait partie du groupe apache
Exemple nouvelle manière
public class ClassifiedClient {
private static EndpointReference targetEPR =
new EndpointReference("http://localhost:8080/axis2/services/MyService");
public static OMElement getEchoOMElement() {
SOAPFactory fac = OMAbstractFactory.getSOAP12Factory();
OMNamespace omNs = fac.createOMNamespace( "http://example1.org/example1",
"example1");
OMElement method = fac.createOMElement("echo", omNs);
OMElement value = fac.createOMElement("category", omNs);
value.addChild(fac.createOMText(value, "classifieds"));
method.addChild(value);
return method;
}
...
Création du « payload »
Exemple (compléments)
...
public class ClassifiedClient {
private static EndpointReference targetEPR = new EndpointReference(
"http://localhost:8080/axis2/services/MyService");
...
}
public static void main(String[] args) {
try {
OMElement payload = ClassifiedClient.getEchoOMElement();
Options options = new Options();
options.setTo(targetEPR);
options.setTransportInProtocol(Constants.TRANSPORT_HTTP);
} catch (Exception e) { System.out.println(e.toString());
}
}
}
Création de la requête
...
try {
OMElement payload = ClassifiedClient.getEchoOMElement();
ServiceClient sender = new ServiceClient();
sender.setOptions(options);
OMElement result = sender.sendReceive(payload);
}
}
}
Envoi de la requête
...
System.out.println(result.toString());
}
}
}
Réception de la réponse
Service SOAP
Avec le produit Axis2
Méthodologie
1. Création du manifest du service
•
Fichier services.xml
2. Création de la classe du service
3. Création du paquetage Axis
4. Déploiement de l'archive
Création du manifest
<service name="CMSService">
<description>
This is a sample Web Service for the newspaper's
Content Managment System.
</description>
<parameter name="ServiceClass" locked="false">CMSService</parameter>
<operation name="getNumberOfArticles">
<messageReceiver class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/>
</operation>
</service>
Fichier services.xml
Création du service
public class CMSService {
public OMElement getNumberOfArticles(OMElement element) throws XMLStreamException {
element.build();
element.detach();
return element;
}
}
Création du service (suite)
...
public OMElement getNumberOfArticles(OMElement element) throws XMLStreamException {
element.build();
element.detach();
String rootName = element.getLocalName();
OMElement categoryElement = element.getFirstElement();
String categoryElementName = categoryElement.getLocalName();
String categoryValue = childElement.getText();
return element;
}
}
Extraction du « payload »
Création du service (suite)
...
SOAPFactory factory = OMAbstractFactory.getSOAP12Factory();
OMNamespace namespace = factory.createOMNamespace("http://daily-moon.com/cms/",
"resp");
OMElement resultElem = factory.createOMElement("numberOfArticles",namespace);
String actualValue = (articleCount(categoryValue)).toString();
resultElem.setText(actualValue);
return resultElem;
}
private Integer articleCount(String catId){
return new Integer(42);
}
}
Création et retour de la réponse
Déploiement du service
<?xml version="1.0"?>
<project name="project" default="default">
<description>
description
</description>
<target name="default" depends="depends" description="--> description">
<jar destfile="${basedir}/build/CMSService.aar" basedir="${basedir}">
<include name="META-INF/**"/>
<include name="service/**"/>
</jar>
</target>
<target name="depends">
<mkdir dir="${basedir}/build"/>
</target>
</project>
Fichier build.xml
Création d'un client
public class CMSClient {
new EndpointReference("http://localhost:8080/axis2/services/CMSService");
OMNamespace omNs =
fac.createOMNamespace( "http://example1.org/example1", "example1");
}
...
OMElement method = fac.createOMElement("getNumberOfArticles", omNs);
OMElement value = fac.createOMElement("category", omNs);
value.addChild(fac.createOMText(value, "classifieds"));
method.addChild(value);
return method;
Création d'un client (suite)
public class CMSClient {
...
try {
OMElement payload = CMSClient.getEchoOMElement();
ServiceClient sender = new ServiceClient();
String response = result.getText();
System.out.println("Il y a "+response+" classées pour le moment.");
}
}
} catch (Exception e) { System.out.println(e.toString());}
Service one-way
Introduction
Création du service
...
private Integer articleCount(String catId){
...
}
}
public void addArticle(OMElement element) throws XMLStreamException{
element.build();
System.out.println(element);
}
Modification de la classe service
Création du manifest
<service name="CMSService">
<description>
This is a sample Web Service for the newspaper's
Content Managment System.
</description>
<parameter name="ServiceClass" locked="false">CMSService</parameter>
<operation name="getNumberOfArticles">
<messageReceiver class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/>
</operation>
<operation name="addArticle">
<messageReceiver class="org.apache.axis2.receivers.RawXMLINOnlyMessageReceiver"/>
</operation>
</service>
Création du client
public class AddArticleClient {
new EndpointReference("http://localhost:8080/axis2/services/CMSService");
private static OMElement getOMElement(){
OMNamespace omNs = fac.createOMNamespace("http://daily-moon.com", "cms");
OMElement method = fac.createOMElement("addArticle", omNs);
OMElement category = fac.createOMElement("category", omNs);
category.setText("classifieds");
OMElement subcategory = fac.createOMElement("subcategory", omNs);
category.setText("wantads");
OMElement adtext = fac.createOMElement("article", omNs);
adtext.setText("Bonjour Le Monde");
method.addChild(category);
method.addChild(subcategory);
method.addChild(adtext);
return method;
}
Création du client (suite)
...
try {
OMElement payload = AddArticleClient.getOMElement();
ServiceClient serviceClient = new ServiceClient();
serviceClient.setOptions(options);
serviceClient.fireAndForget(payload);
} catch (AxisFault axisFault) { axisFault.printStackTrace();
}
}
Accès au service via GET HTTP
Introduction
La méthode GET

Ouvrir un navigateur

Entrer l'URL suivante :
http://localhost:8080/axis2/services/CMSService/getNumberOfArticles?category=classifieds

Service - e

Transcription

Documents pareils

Web Services en Java

Comparatif des intergiciels présentés

Objectifs Plan de cours Pré-Requis

Les Services Web

“1900”de MARIUS FABRE

Immobilier Pro à vendre Colombier-le

UpV@lue - ASPOne.fr

Services Web - Research web sites