webservices l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
WebServices PowerPoint Presentation
Download Presentation
WebServices

Loading in 2 Seconds...

play fullscreen
1 / 93

WebServices - PowerPoint PPT Presentation


  • 120 Views
  • Uploaded on

WebServices. Philippe.Bedu@edf.fr. Composants. Time to market Améliorer la productivité Réduire la complexité Réutiliser si possible Assemblage plutôt que programmation Réduire les besoins en compétences spécialisées Recentrage sur l’expertise du domaine Améliorer la qualité du logiciel.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'WebServices' - otto


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
webservices

WebServices

Philippe.Bedu@edf.fr

composants
Composants
  • Time to market
    • Améliorer la productivité
    • Réduire la complexité
    • Réutiliser si possible
  • Assemblage plutôt que programmation
    • Réduire les besoins en compétences spécialisées
    • Recentrage sur l’expertise du domaine
    • Améliorer la qualité du logiciel
web services 1
Web Services (1)
  • Opération : action invocable
  • Interface : partition des opérations
  • Service : ensemble des interfaces utilisables pour une autre application coopérative

Service Web

    • Service invocable à travers le réseau
    • Non basé sur le contenu (pages web)
    • Délivre des données structurées à une application

Profiter des standards du moment

web services 2
Web Services (2)
  • Utilisation pour l'intégration
    • Dans un portail
    • Applications d'entreprise
    • B2B

Internet

Intranet

Service météo

Portail

météo

Normalisation d'adresse

traducteur

traduction

vente

commande

B Processus

Achat

web services 3

WS interface

WS interface

WS interface

Web Services (3)

SGBD procédures cataloguées

WS interface

WS interface

Orchestration de Flux

Serveur d'applications

Adaptateur progiciels

Systèmes orientés Messages,

courtiers d'Intégration

web services 4
Web Services (4)

Pile de protocoles

Services techniques

Services métier

Processus, workflow

BPEL

ebXML

WS-coordination

RosettaNet

WS-Transaction

Annuaire

UDDI, WSIL

Description

WSDL

Sécurité

WS-Security

XML-based message

SOAP : messaging

Transport

http,httpr,smtp,ftp,mq,iiop…

TCP/IP

slide7
Plan
  • SOAP
    • Protocole de transmission de messages XML
  • WSDL
    • Web Services Description Language
  • UDDI
    • Universal Description Discovery and Integration
  • Web Services
    • Intégration avec l'existant
slide8
SOAP
  • SOAP 1.1
    • Un moyen de faire communiquer des applications par RPC en utilisant HTTP
    • Proposé à W3C en 2000 par UserLand, Ariba, Commerce One, Compaq, Developmentor, HP, IBM, IONA, Lotus, Microsoft etSAP
  • SOAP 1.2
    • travaux W3C
    • Protocole de transmission de messages en XML
slide9
SOAP ?
  • SOAP protocole XML permettant la communication entre composants logiciels et applications en s’appuyant sur des protocoles standards de type http, smtp, …
  • SOAP Simple Object Access Protocol
  • SOAP Service Oriented Architecture Protocol
  • SOAP est un protocole de transmission de messages
  • SOAP est adapté à la communication entre applications
  • SOAP est un format d’échange de messages
  • SOAP est conçu pour fonctionner sur l’Internet
  • SOAP est indépendant des plates-formes et des langages
  • SOAP est basé sur XML
  • SOAP est simple et extensible
  • SOAP en voie de standardisation par W3C
ok et corba alors 1
OK, et CORBA alors? (1)
  • CORBA prend aussi en compte tous ces points
    • mais exige de compiler et distribuer des stubs clients pour chaque type de clients
    • pas toujours pratique pour un grand nombre de combinaisons de plates-formes et de langages ou lors de fourniture de services à des clients anonymes au travers d’Internet
ok et corba alors 2
OK, et CORBA alors? (2)
  • String-ware ?
  • SOAP est un protocole basé sur XML
    • En conséquence, particulièrement prolixe
    • CORBA, au travers de IIOP, le battra en performance car les opérations de conversion et de déconversion (marshalling et demarshalling) dans CORBA sont plus efficaces et il y a moins de données sur le réseau.
    • Néanmoins les messages en xml sont lisibles et utilisables : utile pour la mise au point
soap scenarii 1
SOAP Scenarii (1)

Requête réponse, requête avec acquittement ou RPC sur un protocole de transport assurant la corrélation

Envoi et oublie, avec un ou n récepteurs

Nœud SOAP ultime récepteur

Nœud SOAP émetteur initial

Appli SOAP

Appli SOAP

Niveau SOAP

processeur SOAP

processeur SOAP

Niveau protocole de transport

Hôte 1

Hôte 2

soap scenarii 2
SOAP Scenarii (2)

Requête réponse, requête avec acquittement ou RPC sur un protocole de transport n'assurant la corrélation

Corrélation de messages

Nœud SOAP émetteur initial

Nœud SOAP ultime récepteur

Nœud SOAP émetteur initial

Nœud SOAP ultime récepteur

Appli SOAP B Id message

Appli SOAP B Id message

Appli SOAP A Id message

Appli SOAP A Id message

Niveau SOAP

processeur SOAP

processeur SOAP

processeur SOAP

processeur SOAP

Niveau protocole de transport

Hôte 1

Hôte 2

Hôte 2

Hôte 1

soap scenarii 3
SOAP Scenarii (3)

Requête réponse, requête avec acquittement ou RPC via de multiples intermédiaires

Nœud SOAP émetteur initial

Nœud SOAP intermédiaire

Nœud SOAP ultime récepteur

Appli SOAP B routage

Appli SOAP A routage

Appli SOAP A routage

processeur SOAP

processeur SOAP

processeur SOAP

Niveau SOAP

Niveau protocole de transport

Hôte 1

Hôte 2

Hôte 3

Changement de protocole possible

soap scenarii 4
SOAP Scenarii (4)
  • Requêtes avec cryptage du contenu ou de l'en-tête
  • Echange avec tierce partie
  • Conversation
  • Messages asynchrones
  • Multiples réponse asynchrones
  • Echange de données Non-XML
  • Notification d'événements
  • Cache, cache avec expiration
  • Qualité de service
  • Echange avec analyse et traitement incrémental
  • Routage, tracking
  • Grilles
  • Et autres, en fonction de l'imagination des architectes
soap message
SOAP message
  • Un message SOAP valide est un document XML au bon format. Le message doit avoir la forme suivante:
    • Une déclaration XML (optionnelle)
    • Une Enveloppe SOAP (l'élément racine) qui est composée de:
      • Une En-tête SOAP (optionnel : infos nécessaires à l'interprétation du message)
      • Un Corps SOAP (données du message)
        • Une section d’erreur SOAP
soap message17
SOAP message
  • Règles de syntaxe:
    • un message SOAP MUST être codé en XML
    • un message SOAP MUST avoir une enveloppe SOAP
    • un message SOAP CAN avoir un entête SOAP (header)
    • un message SOAP MUST avoir un corps SOAP (body)
    • un message SOAP MUST utiliser l'espace de désignation de l'enveloppe SOAP
    • un message SOAP MUST utiliser l'espace de désignation d'encodage SOAP
    • un message SOAP MUST NOT contenir une référence à une DTD
    • un message SOAP MUST NOT contenir des instruction de type XML Processing
soap exemple
SOAP Exemple
  • <Envelope> est la racine
  • <Header>, <Body> et <Fault> sont les enfants :

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<soap:Header>

... Header information...

</soap:Header>

<soap:Body>

... Body information...

<soap:Fault> ...Fault information...

</soap:Fault>

</soap:Body>

</soap:Envelope>

soap enveloppe
SOAP Enveloppe
  • <SOAP-ENV:Envelope ... >le style d'encodage de ce message SOAP suit le schéma défini dans http://schemas.xmlsoap.org/soap/encoding
  • Contient les définitions de namespaces.

<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

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

</SOAP-ENV:Envelope>

soap ent te 1
SOAP Entête (1)
  • Mécanisme pour étendre un message de façon décentralisée et modulaire, sans connaissance a priori des parties de la communication.
    • Typiquement authentification, transaction, …
    • Règles :
      • Identifié par un namespace et un nom local
      • Les enfants immédiats qualifiés par le namespace.
soap ent te 2
SOAP Entête (2)
  • 2 attributs particuliers utilisés pour indiquer comment et par qui l’entrée est traitée
    • mustUnderstand : Indiquer qu’une entrée est obligatoire

<SOAP-ENV:Header>

<t:Transaction xmlns:t="some-URI" SOAP-ENV:mustUnderstand="1">

5

</t:Transaction>

</SOAP-ENV:Header>

    • Actor : Indiquer qui peut utiliser l'entête ; par défaut : l’ultime

<SOAP-ENV:Header>

<m:local xmlns:m =’’http://www.w3edfRetD.edu/local/’’

soap:actor= http://www.w3edfRetD.edu/appli >

<m:language> dk </m:language>

</m:local>

</soap:Header>

soap body
Soap Body
  • Mécanisme simple pour échanger les informations avec l’ultime receveur du message.
    • Typiquement appels marshalling RPC calls et des rapports d’erreur
    • Une entrée du body est identifiée par un namesapce et un nom local

<SOAP-ENV:Body>

<ns1:doubleAnIntegerResponse

xmlns:ns1="urn:MesSoapServices"

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<return xsi:type="xsd:int">30</return>

</ns1:doubleAnIntegerResponse>

</SOAP-ENV:Body>

soap section d erreur
SOAP section d’erreur
  • Utilisée pour porter les erreurs ou les statuts d’erreur d’un message
    • Doit apparaître comme une entrée du body
    • Ne doit pas apparaître plus d’une fois
    • Sous éléments :
    • faultcode
      • Identifier l’erreur
    • faultstring
      • Explication de l’erreur

<env:Body>

<env:Fault>

<faultcode><value>env:VersionMismatch</value>

</faultcode>

<faultstring>Version Mismatch</faultstring>

</env:Fault>

</env:Body>

soap encodage de graphes
SOAP encodage de graphes
  • L’information est traitée comme un graphe constitué de nœuds intermédiaires ou terminaux et de liens entre ces nœuds.
  • Il existe des règles d’encodage de ces graphes
  • Valeurs simples
    • XML schema Built-in datatypes et dérivés
    • Ou SOAP-ENC pour des éléments indépendants d’un type hétérogène
  • Valeurs composites
  • Tableaux et structures
soap types simples
SOAP Types simples

<element name="age" type="int"/>

<element name="height" type="float"/>

<element name="displacement"  type="negativeInteger"/>

<element name="color">

<simpleType base="xsd:string">

<enumeration value="Green"/>

<enumeration value="Blue"/>

</simpleType>

</element>

<age>45</age>

<height>5.9</height>

<displacement>-450</displacement>

<color>Blue</color>

<SOAP-ENC:int id="int1">45</SOAP-ENC:int>

soap types composites 1
SOAP Types composites (1)

<element name="Livre">

<complexType>

<element name="auteur" type="xsd:string"/>

<element name="preface" type="xsd:string"/>

<element name="intro" type="xsd:string"/>

</complexType>

</e:Livre>

<e:Livre>

<author>jean Bonneau</author>

<preface>Preface Soap INT</preface>

<intro>Introduction à SOAP</intro>

</e:Livre>

soap types composites 2
SOAP Types composites (2)

<e:Livre>

<titre>SOAP à INT</titre>

<auteur href="#Personne-1"/>

</e:Livre>

<e:Personne id="Personne-1">

<name>Jean Bonneau</name>

<addresse href="#Addresse-2"/>

</e:Personne>

<e:Addresse id="Addresse-2">

<email>mailto:jbonneau@hotmail.com</email>

<web>http://www.jbonneau.com</web>

</e:Addresse>

soap types composites 3
SOAP Types composites (3)

Structure du livre

<element name="Livre" type="tns:Livre"/>

<complexType name="Livre">

<sequence minOccurs="0" maxOccurs="1">

<element name="titre" type="xsd:string"/>

<element name="auteur" type="tns:Personne"/>

</sequence>

<attribute name="href" type="uriReference"/>

<attribute name="id" type="ID"/>

<anyAttribute namespace="##other"/>

</complexType>

soap types composites 4
SOAP Types composites (4)

Structure de Personne

<element name="Personne" base="tns:Personne"/>

<complexType name="Personne">

<sequence minOccurs="0" maxOccurs="1">

<element name="nom" type="xsd:string"/>

<element name="addresse" type="tns:Addresse"/>

</sequence>

<attribute name="href" type="uriReference"/>

<attribute name="id" type="ID"/>

<anyAttribute namespace="##other"/>

</complexType>

soap types composites 5
SOAP Types composites (5)

Structure de Adresse

<element name="Addresse" base="tns:Addresse"/>

<complexType name="Addresse">

<sequence minOccurs="0" maxOccurs="1">

<element name="rue" type="xsd:string"/>

<element name="ville" type="xsd:string"/>

<element name="pays" type="xsd:string"/>

</sequence>

<attribute name="href" type="uriReference"/>

<attribute name="id" type="ID"/>

<anyAttribute namespace="##other"/>

</complexType>

soap array
SOAP Array
  • Définis par le type "SOAP-ENC:Array" ou dérivé
  • Représentés comme des éléments de valeur sans contrainte sur le nom du contenu

<element name="mesResultats"

type="SOAP-ENC:Array"/>

< mesResultats

SOAP-ENC:arrayType="xsd:int[2]">

<number>3</number>

<number>4</number>

</ mesResultats >

soap sur http
SOAP sur HTTP
  • Message SOAP dans le corps HTTP
  • En-tête HTTP 'soapAction'

POST http://www.w3edfRetD.fr http/1.1

Content-type:text/xml ; charset="utf-8"

SOAPAction: http://www.w3edfRetD.fr#service

<SOAP-ENV:Envelope

….

</SOAP-ENV:Enveloppe>

soap requ te rpc
SOAP requête RPC

<soap:Envelope>

<soap:Body>

<xmlns:m="http://www.w3edfRetD.edu/stock" />

<m:GetStockPrice>

<m:StockName>IBM</m:StockName>

</m:GetStockPrice>

</soap:Body>

</soap:Envelope>

soap r ponse rpc
SOAP réponse RPC

<soap:Envelope>

<soap:Body> <xmlns:m="http://www.w3edfRetD.edu/stock" />

<m:GetStockPriceResponse>

<m:Price>20.5</m:Price>

</m:GetStockPriceResponse>

</soap:Body>

</soap:Envelope>

soap principes rpc 1
SOAP Principes RPC (1)
  • Processus Client avec binding http

Package soap

Requête http envoyée au serveur SOAP

Enveloppe la requête SOAP-XML

En requête http

Sérialise en requête SOAP-XML

Construction de l'appel de méthode

Réponse http reçue du serveur SOAP

Désérialise la réponse SOAP-XML

En réponse de méthode

Extrait la réponse SOAP-XML

de la réponse http

Retourne la valeur

Serializer/deserializer

Encoding/decoding http

soap principes rpc 2
SOAP Principes RPC (2)
  • Processus Serveur avec binding http

Package soap

Canal de requête du servlet

Décode la requête http et dé-sérialise la requête SOAP-XML

envoie requête décodeur

Requête http du client SOAP

Invoque la méthode

Opération du Service

envoie réponse décodeur

Retourne la réponse http au client SOAP

sérialise la réponse SOAP-XML et encode de la réponse http

Canal de réponse du servlet

Envoie la réponse

Encoding/decoding http et soap

Servlet SOAP

soap exemple 1
SOAP Exemple (1)
  • Service de normalisation d'adresses
  • Capable de fournir une adresse postale normalisée à partir d'informations de localisation
  • Utilise des types de données complexes en entrée et en sortie

NormAdresse getNorme( Local adresse_local)

Service NormalisationAdresse

Application

SOAP

XML

getNorme

wsdl

Interface

Implantation

opération

Public et standard

Privé et propriétaire

soap exemple 2 serveur d ploiement
SOAP Exemple (2) : Serveur-Déploiement

Le WSDL associé

<Definitions> Racine et namespace

A voir plus tard en détail

<Types> Quels types de données dont échangés

<Message> Quels messages sont transmis

<Port type>Quelles opérations sont supportées

<Binding> Comment les messages sont transmis sur la connexion

<service> Où est situé le service

soap exemple 3 serveur code
SOAP Exemple (3) : Serveur-Code
  • Classe DoNorme
    • Méthode getNorme : retourne une adresse normalisée
    • Local et NormAdresse : Bean
      • Accesseurs (get_) et mutateurs (set_) pour chaque attribut
      • Afin d'utiliser un BeanSerializer
    • Servlet d'initialisation de contexte
soap exemple 4 client code
SOAP Exemple (4) : Client-Code
  • Mapping des types

// Build the call.

Service service = new Service();

Call call = (Call) service.createCall();

// Map the types.

QName qn1 = new QName( "urn:NormAdresse", "Local" );

call.registerTypeMapping(Local.class, qn1,

new org.apache.axis.encoding.ser.BeanSerializerFactory(Local.class, qn1),

new org.apache.axis.encoding.ser.BeanDeserializerFactory(Local.class, qn1));

QName qn2 = new QName( "urn:NormAdresse", "NormAdresse" );

call.registerTypeMapping(NormAdresse.class, qn2,

new org.apache.axis.encoding.ser.BeanSerializerFactory(NormAdresse.class, qn2),

new org.apache.axis.encoding.ser.BeanDeserializerFactory(NormAdresse.class, qn2));

Serialiser la classe Local

soap exemple 5 client code
SOAP Exemple (5) : Client-Code
  • Construire l'appel

call.setTargetEndpointAddress( new java.net.URL(endpointURL) );

call.setOperationName( new QName("NormAdresseService", "getNorme") );

call.addParameter( "AdresseDuLocal", qn1, ParameterMode.IN );

call.setReturnType(qn2,NormAdresse.class); //Build the params

le_local.setloc_no_voie(" 9 BIS");

le_local.setloc_l_voie1("Chemin de la Sablière ");

le_local.setloc_l_voie2("BP 12");

le_local.setloc_c_postal(" 91430");

le_local.setloc_l_bd(" Igny");

Object resp resp = call.invoke( new Object[] { le_local } );

Méthode

On aurait pu directement construire le XML dans un SOAPBodyElement[] et le passer au call

soap exemple 6 client code
SOAP Exemple (6) : Client-Code
  • Exploiter le résultat

//

if (resp instanceof java.rmi.RemoteException)

{

throw(java.rmi.RemoteException) resp;

}

else

try {

NormAdresse value = (NormAdresse)resp;

if ( value != null )

{

System.out.println("retour :");

System.out.println("code"+value.getAdr_c_postal());

}

} catch(java.lang.Exception e) { …}

slide43
WSDL

Web Services Description Language

Vocabulaire XML, similaire dans le principe à IDL

  • Il contient des informations opérationnelles concernant le service :
  • L'interface du service
  • Les détails d'implantation
  • Les protocoles d'accès
  • Les points d'activation (contact endpoints)

WSDL : convergence de deux langages

IBM's NASSL

Microsoft's SDL

slide44
WSDL

<definitions> : Définition du service. Racine de tout WSDL. Elle peut contenir les attributs précisant le nom du service, et les espaces de nommage. Il contient trois types d’éléments :

<message> et <portType> : Définissent les opérations offertes par

Le service. Un <message> correspond à un paramètre d’entrée ou de sortie d’une <operation>. Un <portType> définit un ensemble d’opérations. Une <operation> possède un nom et des paramètres d'E/S.

<binding> : Associe les <portType> à un protocole particulier. Par exemple SOAP.

<service> : Précise les informations nécessaires à l'invocation d'un service, en particulier l’URI du destinataire. Un <service> est une collection de <port> ;ie d’associations de <binding> et d'URI.

Les types de données complexes peuvent être précisés dans une balise <types> placée juste avant la balise <message>.

Chaque élément WSDL peut être documenté grâce à une balise <documentation>.

wsdl exemple 1
WSDL : exemple (1)

L’exemple suivant est la description du service Echo précédemment défini :

<wsdl:definitions targetNamespace="http://cli20ir:9595/axis/services/NormAdresseService/axis/services/NormAdresseService" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="http://cli20ir:9595/axis/services/NormAdresseService/axis/services/NormAdresseService-impl" xmlns:intf="http://cli20ir:9595/axis/services/NormAdresseService/axis/services/NormAdresseService" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns1="urn:NormAdresse" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/">

La première partie du fichier définit les espaces de nommage

wsdl exemple 2
WSDL : exemple(2)

<wsdl:types>

<schematargetNamespace="urn:NormAdresse" xmlns="http://www.w3.org/2001/XMLSchema">

<complexTypename="Local">

<sequence>

<element name="loc_no"nillable="true"type="xsd:string"/>

<element name="cli_ic_orig"nillable="true"type="xsd:string"/>

</sequence>

</complexType>

<element name="Local"nillable="true"type="tns1:Local"/>

</schema>

</wsdl:types>

On trouve ensuite les types particuliers utilisés

wsdl exemple 3
WSDL : exemple (3)

Puis les paramètres d’entrée et de sortie des

opérations du service

<wsdl:message name="getNormeResponse">

<wsdl:part name="return"type="tns1:NormAdresse" />

</wsdl:message>

<wsdl:message name="getNormeRequest">

<wsdl:part name="adresse_local"type="tns1:Local"/>

</wsdl:message>

<wsdl:portTypename="DoNorme">

<wsdl:operationname="getNorme"parameterOrder="adresse_local">

<wsdl:input message="intf:getNormeRequest"name="getNormeRequest" /> <wsdl:output message="intf:getNormeResponse"name="getNormeResponse" />

</wsdl:operation>

</wsdl:portType>

La définition abstraite du service Web est faite par définition du

portType, indépendante de tout protocole de communication. C’est l’interface du service définissant les méthodes exportées, et leurs paramètres d’entrée et de sortie.

wsdl exemple 4
WSDL : exemple (4)

<wsdl:binding name="NormAdresseServiceSoapBinding"type="intf:DoNorme">

<wsdlsoap:binding style="rpc"transport="http://schemas.xmlsoap.org/soap/http" />

<wsdl:operationname="getNorme">

<wsdlsoap:operation soapAction="" />

<wsdl:input name="getNormeRequest">

<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"namespace="http://cli20ir:9595/axis/services/NormAdresseService/axis/services/NormAdresseService"use="encoded" />

</wsdl:input>

<wsdl:outputname="getNormeResponse">

<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"namespace="http://cli20ir:9595/axis/services/NormAdresseService/axis/services/NormAdresseService"use="encoded" />

</wsdl:output>

</wsdl:operation>

</wsdl:binding>

Ce service est associé à un protocole existant, via un binding . Il définit les paramètres d’invocation du service spécifiques au protocole. Les paramètres nécessaires à l’utilisation (lien vers les spécifications du transport utilisé, règles d’encodage pour les messages échangés, …).

wsdl exemple 5
WSDL : exemple (5)

<wsdl:service name="DoNormeService">

<wsdl:port binding="intf:NormAdresseServiceSoapBinding"

name="NormAdresseService">

<wsdlsoap:address location=http://cli20ir:9595/axis/services/NormAdresseService />

</wsdl:port>

</wsdl:service>

</wsdl:definitions>

La définition du service se termine par la définition de plusieurs bindings, associés à plusieurs URL, et ce en utilisant la même définition abstraite du service.

slide50
WSDL
  • WSDL créé automatiquement à partir de Java avec Java2WSDL
  • Utilisation
    • Construire un proxy pour une utilisation directe à partir du client ou d'un autre Service avec WSDL2J

DoNorme binding = new DoNormeServiceLocator().getNormAdresseService();

NormAdresse value = binding.getNorme(le_local);

    • Exploiter dynamiquement le WSDL avec WSDL4J
    • Pour une invocation dynamique ou bien pour automatiser l'enregistrement et la publication dans un annuaire
slide51
UDDI

Universal Description, Discovery and Integration

Une spécification pour la description et la découverte de WebServices

WhitePages

  • Les Businesses enregistrent des informations publiques les concernant
  • Les développeurs, éditeurs de logiciels, organismes de standardisation enregistrent des types de services techniques
  • White pages (informations générales)
  • Yellow pages (catégories de services)
  • Green pages (business rules)

YellowPages

GreenPages

slide52
UDDI

Pages blanches : noms, adresses, contacts, identifiants,… des entreprises

enregistrées. Ces informations sont décrites dans des entités de type Business

Entity. Cette description inclut des informations de catégorisation permettant de

faire des recherches spécifiques dépendant du métier de l’entreprise ;

Pages jaunes : détails sur le métier de l’entreprise, les services qu’elle propose. Ces

informations sont décrites dans des entités de type Business Service ;

Pages vertes : informations techniques sur les services proposés. Les pages vertes

incluent des références vers les spécifications des services Web, et les détails

nécessaires à l’utilisation de ces services. Ces informations sont décrites dans deux documents : un Binding Template, et un Technology Model (tModel).

slide53

Contact

Contact

Phone

Address

Email

Phone

Address

Email

keyedReference

keyedReference

keyedReference

keyedReference

tModelKey

keyName

keyValue

tModelKey

keyName

keyValue

tModelKey

keyName

keyValue

UDDI
  • Document XML

businessEntity

businessKey

name

URL

description

contacts

businessServices

identifierBag

categoryBag

businessService

businessService

serviceKey

tModelKey

Name

Description

BindingTemplates

Key

Name

Description

BindingTemplates

slide54

businessEntity

RD991… EDF-RETD

www.edf-retd.fr

“Architecture Services…."

contacts

businessServices

identifierBag

categoryBag

BindingTemplate

tModelInstanceInfo

keyedReference

keyedReference

110293-32009…

http://www.edf-retd.fr/sinetics…

tModelInstanceDetails

1112C-2244-3AXA…

http://www.edf-retd.fr/catalogArchi

DFE-2B…

DUNS

45231

EE123…

NAICS

007..

UDDI

businessService

businessService

34257GHF12…

Services support Archi

“Website where you can …

BindingTemplates

Key

Name

Description

BindingTemplates

tModelKeys

slide55
UDDI
  • Enregistrer et retrouver un Service avec UDDI4J
  • 2 parties dans WSDL : interface + implantation
  • Interface
  • <Definition>
    • <Types>
    • <Import>
    • <Message>
    • <Portype>
    • <binding>
  • </Definition>
  • Implantation
  • <Definition>
  • <Import>
  • <Service>
  • <Port>
  • </Service>
  • </Definition>
slide56

<service>

<port>

<port>

UDDI

Implantation

UDDI

<import>

BusinessEntity

BusinessService

BusinessTemplate

BusinessTemplate

tModel

Interface

<types>

<messages>

<portType>

<Binding>

slide57
UDDI

Implantation

UDDI

<wsdl:definitions name="NormAdresseService"

targetNamespace="http://…">

<import namespace="http://…"

location="http://…" />

<wsdl:service name="DoNormeService">

<wsdl:port name="NormAdresseService "

binding="intf:NormAdresseServiceSoapBinding">

</wsdl:service>

</wsdl:definitions>

<BusinessEntity businessKey="…"

<name> Normalisation d'adresse </name>

<businessService serviceKey="…">

<name> DoNormeService </name>

<BindingTemplates bindingKey="…">

<TmodelInstanceInfo tModelKey="…">

<overviewDoc>

<overviewdocURL>http://…# NormAdresseService

</overviewdocURL>…

</BindingTemplates>

</businessService>

</BusinessEntity>

Interface

<wsdl:definitions name="NormAdresseService.interface"

targetNamespace="http://…">

<wsdl:message name="getNormeResponse">

</wsdl:message>

<wsdl:portType name="DoNorme">

</wsdl:portType>

<wsdl:binding name="NormAdresseServiceSoapBinding"

type="intf:DoNorme">

</wsdl:binding>

</wsdl:definitions>

<tModel tModelKey="…"

<name> http://… </name>

<overviewDoc>

<overviewdocURL>http://…#NormAdresseServiceSoapBinding

targetNamespace="http://…">

</overviewdocURL>…

<categoryBag>

<KeyedReference tModemKey="…" keyname="uddi-org:types keyvalue="wsdlSpec"/>

</ categoryBag >

</tModel>

slide58
UDDI
  • Enregistrer séparément les descriptions des Compagnies et les descriptions des services
  • Développeurs, éditeurs de logiciels, organismes de standardisation enregistrent des types de services
  • Les Compagnies enregistrent les services qu'elles supportent
slide59
UDDI
  • UDDI4J simplifie l'interaction avec un annuaire UDDI
  • Pour l'enregistrement et la découverte
  • Utilisation de l'objet UDDIProxy

UDDIProxy p = new UDDIProxy();

p. setInquiryURL( “ http:// …” );

p. setPublishURL( “https:// …” );

slide60
UDDI
  • Publishers API
    • Enregistrer
      • save_business
      • save_service
      • save_binding
      • save_tModel
    • Détruire
      • delete_business
      • delete_service
      • delete_binding
      • delete_tModel
    • Sécurité
      • get_authToken
      • discard_authToken
  • Inquiry API
    • Trouver
      • find_business
      • find_service
      • find_binding
      • find_tModel
    • Plus de détails
      • get_businessDetail
      • get_serviceDetail
      • get_bindingDetail
      • get_tModelDetail
slide61
UDDI

Enregistrement UDDI

Nœud annuaire UDDI

Client

Requête UDDI SOAP

UDDI4J

Serveur HTTP

Serveur SOAP

Réponse UDDI SOAP

Annuaire UDDI

WSDL4J

Enregistrement à partir d'un fichier wsdl

Nœud WS

WSDL

WebService

slide62
UDDI

Utilisation UDDI

Nœud annuaire UDDI

Client

Requête UDDI SOAP

UDDI4J

Serveur HTTP

Serveur SOAP

Réponse UDDI SOAP

URI="http://…"

Annuaire UDDI

Nœud WS

Communication avec le WS

WSDL

WebService

uddi exemple 1
UDDI : exemple (1)
  • Retrouver une BusinessEntity, un des services qu'elle propose
  • Invoquer ce service

Dans la pratique on rechercherait plutôt par catégorie

Retrouver la BusinessEntity

Vector names = new Vector();

names.add(new Name("EDF-RetD"));

BusinessList businessList = proxy.find_business(names, null, null,null,null,null,10);

Vector businessInfoVector = businessList.getBusinessInfos().getBusinessInfoVector();

BusinessInfo businessInfo = null;

….

Boucle dans businessInfoVector pour vérifier que c'est le bon BusinessEntity

Vector serviceInfoVector = businessInfo.getServiceInfos().getServiceInfoVector();

Boucle dans serviceInfoVector pour retrouver le serviceInfo

uddi exemple 2
UDDI : exemple (2)

Retrouver les détails pour le service référencé par les différentes clés

ServiceDetail serviceDetail = proxy.get_serviceDetail(serviceInfo.getServiceKey());

Vector businessServices = serviceDetail.getBusinessServiceVector();

Boucle dans businessServices pour retrouver le Service

BusinessService businessService = null;

for (int i = 0; i < businessServices.size(); i++) {

businessService = (BusinessService)businessServices.elementAt(i);

if (serviceName.equals(businessService.getDefaultNameString())) {…}

Maintenant,il faut retrouver l'Overview URL du tModel :

Grâce au businessServices, retrouver le bindingTemplates puis le point d'accès basé sur http

Vector bindingTemplateVector = businessService.getBindingTemplates().getBindingTemplateVector();

AccessPoint accessPoint = null;

BindingTemplate bindingTemplate = null;

On peut aussi faire un find_service

uddi exemple 3
UDDI : exemple (3)

Boucle dans bindingTemplateVector pour retrouver le bindingTemplate corrrespondant

if (accessPoint.getURLType().equals("http")) …

Il faut enfin retrouver le tModel associé

Vector tmodelInstanceInfoVector = bindingTemplate.getTModelInstanceDetails().getTModelInstanceInfoVector();

String wsdlImplURI = null;

Boucle dans tmodelInstanceInfoVector pour retrouver l'OverviewURL corrrespondant

TModelInstanceInfo instanceInfo = (TModelInstanceInfo)tmodelInstanceInfoVector.elementAt(i);

InstanceDetails details = instanceInfo.getInstanceDetails();

OverviewDoc wsdlImpl = details.getOverviewDoc();

wsdlImplURI = wsdlImpl.getOverviewURLString();

uddi exemple 4 avec wsdl
UDDI : exemple (4) avec WSDL

Il est alors possible d'invoquer dynamiquement le service en utilisation l'api WSDL4J

Il faut en particulier analyser le WSDL et extraire

Le target namespace

Le nom du service

Le nom du port le nom de l'opération ainsi que ces paramètres

slide67
UDDI
  • En pratique les clés de classification et d'identification devraient être gérées et fournies par des agences mondiales
  • Les informations du niveau "yellow pages" de UDDI sont typiquement fondées sur deux standards :
    • NAICS (the North American Industry Classification System)
      • projet des gouvernements du Canada, du Mexique et des US.
    • http:// www.naics.com
    • UNSPSC (the Universal Standard Products and Services Classification).
      • Efforts conjoints de Dun & Bradstreet et du programme de développement des nations unies pour une unification des classifications
    • http://www.unspsc.org
slide68
UDDI
  • Application directe
  • La recherche du document WSDL associé au service est facilitée par une référence spécifique de nom "uddi-org:types" et de valeur "wsdlSpec"

Lors de l'enregistrement cette clé est définie de la manière suivante :

KeyedReference kr = new KeyedReference("uddi-org:types","wsdlSpec","");

slide69
UDDI
  • Type d'annuaire utile pour la découverte de BusinessEntity ou de BusinessService
    • Identification et catégorisation
  • Encore peu implanté
  • Nécessité d'un modérateur
  • Mise en œuvre relativement complexe
  • On lui préfère une approche plus pragmatique
    • WSIL
    • Fournit une liste simple des services disponibles
slide70
WSIL
  • WebService Inspection Language
  • Une méthode de découverte de services décentralisée
  • Considère que l'on connaît déjà le fournisseur de services, donc pas de notion de businessEntity
  • WSIL représente une entité spécifique, ses services, ses contacts et est fourni directement par celui qui le représente
  • Un fichier WSIL références tous les documents qui décrivent les services de l'entreprise, y compris UDDI

WSIL

UDDI

XML

WSDL

HTML

wsil exemple
WSIL : exemple

<?xml version="1.0" encoding="UTF-8"?>

<inspection xmlns="http://schemas.xmlsoap.org/ws/2001/10/inspection/">

<abstract>The EDF-RetD W Service Search API</abstract>

<service>

<abstract>NormAdresse Search</abstract>

<description referencedNamespace="http://schemas.xmlsoap.org/wsdl/" location="http://www.edf-RetD.fr/NormAdresse.wsdl"/>

<description

referencedNamespace ="http://www.w3c.org/html/"

location ="http://www. edf-RetD.fr /1999/NormAdresse_Deployment.html" />

<description

referencedNamespace ="http://www.uddi.org/"

location ="http://www. edf-RetD.fr /soapuddi/" />

</service>

</inspection>

Une fois le fichier créé, on peut le placer sous

http://www.EDF-RetD.fr/WS/inspection.wsil

web services et l existant
Web Services et l'existant
  • Une nouvelle technologie pour le middleware
  • Curiosité, méfiance
  • Que gagne-t-on ?
  • Que perd-on ?
  • Comment gérer la transition ?

Vraiment différent de J2EE ou CORBA ?

description des services
Description des services
  • Spécification CORBA
      • Langage de description des interfaces (OMG IDL) + règles de projection vers des langages de programmation
      • Langage de description des implantations : OMG CIDL + règles de génération de guides d’implantation.
  • Structure des messages échangés déduite de la description des interfaces (explicite en WSDL).
  • Choix du protocole d’échange et de l’encodage des messages lié à l’ORB (explicite en WSDL).
  • Localisation des services déterminée au déploiement (explicite en WSDL).

Orientation service de WSDL

description coexistence
Description : Coexistence
  • Spécification en cours à l’OMG
    • RFP « CORBA to WSDL/SOAP interworking »
    • Réponse commune de Cape Clear, Fujitsu, HP, IONA, Sankhya avec le support d’IBM
  • J2EE 1.4 conteneur de service

Serveur d'applications

Ejb ou JAX-RPC web component

Cycle de vie de la responsabilité su serveur d'applications

Wsdl :portType, transport et encoding binding

Wsdl:portadress

Port (représentation du web service)

Service endpoint interface

Service instance

Wsdl :portType

Wsdl :service

Usine à stubs

Service interface

localisation

client

serveur

courtier

2 - export

1 - import

ORB

3 - interaction

Localisation
  • Spécification CORBA
    • Référence CORBA – chaîne de caractère ou URL
    • Annuaire de services (Naming Service)
    • Registre d'interfaces et d'implantation(Interface and Implementation Repository)
    • Courtier (Trading Service)
  • J2EE : JNDI
    • Passerelle vers des répertoires d’entreprises
    • Et JNDI SPI vers Corba
    • Répertoire centralisé des objets J2EE
      • Fabrique d’objets « Home »
      • Variables et ressources partagées
localisation webservice
Localisation : WebService
  • UDDI
  • Universal Description, Discovery and Integration
  • Le référentiel UDDI vu comme un annuaire
    • pages blanches (informations de contact)
    • pages jaunes (classification par catégories)
    • pages vertes (informations techniques sur le service)
  • WSIL
  • WebService Inspection Language
  • Une méthode de découverte de services décentralisée

Découverte de service

localisation77
Localisation
  • Annuaire et découverte de service commun aux WebServices et aux architectures CORBA, J2EE
  • Qualité de service pas dans UDDI mais peut être associée à ebXML
communication79
Communication
  • CORBA - IIOP
    • Invocation d'opération ou One-way
    • Relocalisation,
    • Multiplexage client-serveur
    • Abandon de requête
  • SOAP
    • one way
    • Reconstruction de protocole
    • Multiples intermédiaires
    • Attachements SOAP permettent de véhiculer des contenus MIME avec un message SOAP
coexistence corba ws
Coexistence : CORBA - WS
  • Exposer des composants CORBA sous forme de Web Services
  • Web Services vus comme des composants CORBA
  • Adaptation des environnements CORBA.

RéférentielUDDI

DescriptionWSDL

ServeurSOAP

Client CORBA

Systèmes CORBA

SOAP/HTTP

Client SOAP

Conteneur d’applications Web

Serveur Web

coexistence j2ee ws
Coexistence : J2EE - WS
  • J2EE 1.4
  • API pour SOAP, WSDL, UDDI
    • SOAP Messaging
      • JAXM, SAAJ, JAX-RPC, JMS
    • WSDL
      • Java API for WSDL
      • JAX-RPC
    • UDDI
      • JAXR
coexistence j2ee ws82
Coexistence : J2EE - WS

SOAP/HTTP et autres bindings

Conteneur de servlet

Conteneur Ejb

Port

Port

servlet

jsp

ejb

RMI/IIOP

Noyau J2EE

Noyau J2EE

HTTP/SSL

RMI/IIOP

coexistence j2ee ws83
Coexistence : J2EE - WS
  • Paquetage pour déploiement
    • Pour Web Component : fichier WAR
    • Pour stateless session bean : fichier EJB JAR
  • Descripteur de déploiement : webservices.xml
    • Différents de celui associé à l'implantation du service : web.xml ou ejb-jar.xml
  • Déploiement
    • Génération des classes d'aide : servlet, stub, proxy,… pour le client (placement du service implementation accessible par JNDI)
    • Génération, mise à jour et publication du WSDL
coexistence j2ee ws84
Coexistence : J2EE - WS
  • Développement sur J2EE
  • WSDL de/vers Web service Endpoint Interface (java)
  • Endpoint Interface spécifiée dans JAX-RPC
    • Utile pour servlet-based et EJB-based endpoint
    • Pour le cas EJB déclaration dans le descripteur de déploiement du endpoint
  • Implantation en classe Java (servlet) ou Stateless session bean
  • Création de descripteur de déploiement
    • webservices.xml
conclusion
Conclusion
  • WS : De nombreuses caractéritiques en commun avec les environnements répartis J2EE, CORBA, Net.

Réinventer la roue ?

  • Principales différences
    • Positionnement ?
      • WS : middleware de middleware
    • fonctionnement en mode déconnecté (connexions transitoires et temporaires)
    • pas de connaissance a-priori des parties qui entrent en communication (accès aux informations sur le service)
atouts
Atouts
  • Intégrer au niveau service
    • Contrat métier
    • Contrat technique
  • Orchestration
  • Intermédiation

Gagner en abstraction

produits
Produits
  • “HP WS” de HP
      • eSpeak, HP-AS, HP-WS
  • “E2A” de IONA
      • E2A WS Interoperation, Application Server
  • “Cape” de CapeClear
      • CapeConnect, CapeStudio
  • “.Net” de Microsoft
      • .Net environment, .Net framework, .Net Visual Studio
  • “Sun One Net” de Sun
      • iPlanet, Sun One Studio
  • “WebSphere” de IBM
      • WebSphere, WebSphere Studio
  • “WebLogic” de BEA
      • WebLogic Server, Integration, Portal, Studio
  • “Oracle 9i” de Oracle
      • Oracle 9iAS

Des outils existent

perspectives
Perspectives
  • Perspectives
  • Maturité WS : encore du travail
    • Gestion de la sécurité (Microsoft, IBM, Verisign : WS-Security) et des transactions (Microsoft, IBM, BEA : WS-Transaction).
    • Définition de modèles d’interaction (chorégraphie) et de collaboration (processus métiers, recherche de partenaires).
  • Périmètre WS : des interrogations
    • Persistance, gestion de l'état, …

Maturité et périmètre

webservices le futur 1
WebServices : le futur ! (1)
  • SOAP Recommandations W3C , version 1.2
  • Points à voir
    • La gestion des sessions
    • L'asynchronisme
  • Des protocoles au dessus de SOAP
    • Pour des sémantiques d'échanges particulières
      • SOAP : one way
      • Basés sur la définition de patrons d'échanges
webservices le futur 2
WebServices : le futur ! (2)
  • WSDL Recommandations W3C , version 1.2
    • On trouve encore plusieurs styles de génération de WSDL ce qui complique l'interopérabilité
  • UDDI Recommandations UDDI.org, version 3.0
    • Trouver la vitesse de croisière
    • Le démarrage est difficile
    • Mise en œuvre assez complexe
    • Pas de modérateur
  • WSIL version 1.0 une solution intéressante

IBM, MicroSoft,HP, Oracle, SAP,…

webservices le futur 3
WebServices : le futur ! (3)
  • Stabilisation des autres niveaux de la pile de protocole pour les WebServices
  • En particulier l'orchestration ou encore la chorégraphie des services
    • dérouler des processus plus complexes que l’appel d’opérations atomiques, avec plusieurs acteurs. Couvert par la spécification BPEL4WS
  • Notion d'intermédiaire entre acteurs de différentes compagnies
quelques urls
Quelques URLs

Standards

http://xml.apache.org/axis. Apache-Axis

http://www.w3.org/2000/xp SOAP

http://www.w3.org/XML/Schema XML-schema

http://www.w3.org/TR/wsdl WSDL

http://www.uddi.org/UDDI

Ressources

http://www-106.ibm.com/developerworks/webservices/

http://www-106.ibm.com/developerworks/webservices/wsdk/

http://www.webservices.org/

http://www.javaworld.com/javaworld/jw-05-2002/jw-0517-webservices.html

http://www.themindelectric.com/

Sites de WS

http://www.xmethods.net/

http://hosting.msugs.ch/

http://java.sun.com/webservices/

alors webservices
Alors ?WebServices ?

Philippe.Bedu@edf.fr