WebServices 
Philippe.Bedu@edf.fr
Composants 
• Time to market 
• Améliorer la productivité 
• Réduire la complexité 
• Réutiliser si possible 
• Assemblage...
Web Services (1) 
• Opération : action invocable 
• Interface : partition des opérations 
• Service : ensemble des interfa...
Web Services (2) 
• Utilisation pour l'intégration 
• Dans un portail 
• Applications d'entreprise 
• B2B 
Portail 
Normal...
Web Services (3) 
SGBD procédures cataloguées 
Adaptateur progiciels 
Systèmes orientés Messages, 
courtiers d'Intégration...
Web Services (4) 
Services techniques 
WS-Transaction 
Services métier 
ebXML 
Sécurité WS-Security 
SOAP : messaging 
htt...
Plan 
• SOAP 
• Protocole de transmission de 
messages XML 
• WSDL 
• Web Services Description Language 
• UDDI 
• Univers...
SOAP 
• SOAP 1.1 
• Un moyen de faire communiquer des 
applications par RPC en utilisant HTTP 
• Proposé à W3C en 2000 par...
SOAP ? 
• SOAP protocole XML permettant la communication entre 
composants logiciels et applications en s’appuyant sur des...
OK, et CORBA alors? (1) 
• CORBA prend aussi en compte tous ces points 
• mais exige de compiler et distribuer des 
stubs ...
OK, et CORBA alors? (2) 
• String-ware ? 
• SOAP est un protocole basé sur XML 
• En conséquence, particulièrement prolixe...
SOAP Scenarii (1) 
Envoi et oublie, avec 
un ou n récepteurs 
Noeud SOAP 
émetteur 
initial 
Requête réponse, requête 
ave...
SOAP Scenarii (2) 
Noeud SOAP 
émetteur 
initial 
Appli SOAP 
A Id 
message 
processeur 
SOAP 
Niveau SOAP 
Niveau protoco...
SOAP Scenarii (3) 
Noeud SOAP 
émetteur 
initial 
Appli SOAP 
A 
routage 
processeur 
SOAP 
Niveau protocole de 
transport...
SOAP Scenarii (4) 
• Requêtes avec cryptage du contenu ou de l'en-tête 
• Echange avec tierce partie 
• Conversation 
• Me...
SOAP message 
• Un message SOAP valide est un document XML 
au bon format. Le message doit avoir la forme 
suivante: 
• Un...
SOAP message 
• Règles de syntaxe: 
• un message SOAP MUST être codé en XML 
• un message SOAP MUST avoir une enveloppe SO...
SOAP Exemple 
• <Envelope> est la racine 
• <Header>, <Body> et <Fault> sont les enfants : 
<?xml version="1.0" encoding="...
SOAP Enveloppe 
•<SOAP-ENV:Envelope ... >le style d'encodage 
de ce message SOAP suit le schéma défini dans 
http://schema...
SOAP Entête (1) 
• Mécanisme pour étendre un message de façon 
décentralisée et modulaire, sans connaissance 
a priori des...
SOAP Entête (2) 
• 2 attributs particuliers utilisés pour indiquer 
comment et par qui l’entrée est traitée 
• mustUnderst...
Soap Body 
• Mécanisme simple pour échanger les 
informations avec l’ultime receveur du 
message. 
• Typiquement appels ma...
SOAP section d’erreur 
• Utilisée pour porter les erreurs ou les statuts d’erreur d’un 
message 
• Doit apparaître comme u...
SOAP encodage de graphes 
• L’information est traitée comme un graphe 
constitué de noeuds intermédiaires ou 
terminaux et...
SOAP Types simples 
<element name="age" type="int"/> 
<element name="height" type="float"/> 
<element name="displacement" ...
SOAP Types composites (1) 
<element name="Livre"> 
<complexType> 
<element name="auteur" type="xsd:string"/> 
<element nam...
SOAP Types composites (2) 
<e:Livre> 
<titre>SOAP à INT</titre> 
<auteur href="#Personne-1"/> 
</e:Livre> 
<e:Personne id=...
SOAP Types composites (3) 
Structure du livre 
<element name="Livre" type="tns:Livre"/> 
<complexType name="Livre"> 
<sequ...
SOAP Types composites (4) 
Structure de Personne 
<element name="Personne" base="tns:Personne"/> 
<complexType name="Perso...
SOAP Types composites (5) 
Structure de Adresse 
<element name="Addresse" base="tns:Addresse"/> 
<complexType name="Addres...
SOAP Array 
• Définis par le type "SOAP-ENC:Array" 
ou dérivé 
• Représentés comme des éléments de 
valeur sans contrainte...
SOAP sur HTTP 
• Message SOAP dans le corps HTTP 
• En-tête HTTP 'soapAction' 
POST http://www.w3edfRetD.fr http/1.1 
Cont...
SOAP requête RPC 
<soap:Envelope> 
<soap:Body> 
<xmlns:m="http://www.w3edfRetD.edu/stock" 
/> 
<m:GetStockPrice> 
<m:Stock...
SOAP réponse RPC 
<soap:Envelope> 
<soap:Body> 
<xmlns:m="http://www.w3edfRetD.edu/stock" 
/> 
<m:GetStockPriceResponse> 
...
SOAP Principes RPC (1) 
• Processus Client avec binding http 
Construction 
de l'appel de 
méthode 
Sérialise en 
requête ...
SOAP Principes RPC (2) 
• Processus Serveur avec binding http 
Requête http 
du client 
SOAP 
envoie 
requête 
décodeur 
D...
SOAP Exemple (1) 
• Service de normalisation d'adresses 
• Capable de fournir une adresse postale normalisée à 
partir d'i...
SOAP Exemple (2) : Serveur-Déploiement 
Le WSDL associé 
<Definitions> Racine et namespace 
<Types> Quels types de données...
SOAP Exemple (3) : Serveur-Code 
• Classe DoNorme 
• Méthode getNorme : retourne une adresse 
normalisée 
• Local et NormA...
SOAP Exemple (4) : Client-Code 
• Mapping des types 
// Build the call. 
Service service = new Service(); 
Call call = (Ca...
SOAP Exemple (5) : Client-Code 
• Construire l'appel 
call.setTargetEndpointAddress( new java.net.URL(endpointURL) ); 
cal...
SOAP Exemple (6) : Client-Code 
• Exploiter le résultat 
// 
if (resp instanceof java.rmi.RemoteException) 
{ 
throw(java....
WSDL 
Web Services Description Language 
Vocabulaire XML, similaire dans le principe à IDL 
• Il contient des informations...
WSDL 
<definitions> : Définition du service. Racine de tout WSDL. Elle peut 
contenir les attributs précisant le nom du se...
WSDL : exemple (1) 
L’exemple suivant est la description du service Echo précédemment défini : 
<wsdl:definitions 
targetN...
WSDL : exemple(2) 
<wsdl:types> 
<schematargetNamespace="urn:NormAdresse" 
xmlns="http://www.w3.org/2001/XMLSchema"> 
<com...
WSDL : exemple (3) 
<wsdl:message name="getNormeResponse"> 
<wsdl:part name="return"type="tns1:NormAdresse" /> 
</wsdl:mes...
WSDL : exemple (4) 
<wsdl:binding 
name="NormAdresseServiceSoapBinding"type="intf:DoNorme"> 
<wsdlsoap:binding 
style="rpc...
WSDL : exemple (5) 
<wsdl:service name="DoNormeService"> 
<wsdl:port binding="intf:NormAdresseServiceSoapBinding" 
name="N...
WSDL 
• WSDL créé automatiquement à partir de Java 
avec Java2WSDL 
• Utilisation 
• Construire un proxy pour une utilisat...
UDDI 
Universal Description, Discovery and Integration 
Une spécification pour la description et la découverte de WebServi...
UDDI 
Pages blanches : noms, adresses, contacts, identifiants,… des entreprises 
enregistrées. Ces informations sont décri...
UDDI 
• Document XML 
businessEntity 
businessKey 
name 
URL 
description 
contacts 
businessServices 
identifierBag 
cate...
UDDI 
businessEntity 
RD991… 
EDF-RETD 
www.edf-retd.fr 
“Architecture Services…." 
contacts 
businessServices 
identifier...
UDDI 
• Enregistrer et retrouver un Service avec 
UDDI4J 
• 2 parties dans WSDL : interface + implantation 
Interface 
<De...
UDDI 
Implantation 
<import> 
<service> 
<port> 
<port> 
Interface 
<types> 
<messages> 
<portType> 
<Binding> 
UDDI 
Busi...
Implantation 
<wsdl:definitions name="NormAdresseService" 
targetNamespace="http://…"> 
<import namespace="http://…" 
loca...
UDDI 
• Enregistrer séparément les descriptions des 
Compagnies et les descriptions des services 
• Développeurs, éditeurs...
UDDI 
• UDDI4J simplifie l'interaction avec un annuaire 
UDDI 
• Pour l'enregistrement et la découverte 
• Utilisation de ...
UDDI 
• Inquiry API 
• Trouver 
• find_business 
• find_service 
• find_binding 
• find_tModel 
• Plus de détails 
• get_b...
UDDI 
Client 
Noeud 
annuaire 
UDDI 
Requête 
UDDI SOAP 
Réponse 
UDDI SOAP 
Serveur 
HTTP 
Serveur 
SOAP 
Annuaire 
UDDI ...
UDDI 
Client 
Noeud 
annuaire 
UDDI 
Requête 
UDDI SOAP 
Réponse 
UDDI SOAP 
Serveur 
HTTP 
Serveur 
SOAP 
Annuaire 
UDDI ...
UDDI : exemple (1) 
• Retrouver une BusinessEntity, un des services 
qu'elle propose 
• Invoquer ce service 
Dans la prati...
UDDI : exemple (2) 
Retrouver les détails pour le service référencé par les différentes 
clés 
ServiceDetail serviceDetail...
UDDI : exemple (3) 
Boucle dans bindingTemplateVector pour retrouver le 
bindingTemplate corrrespondant 
if (accessPoint.g...
UDDI : exemple (4) avec WSDL 
Il est alors possible d'invoquer 
dynamiquement le service en utilisation l'api 
WSDL4J 
Il ...
UDDI 
• En pratique les clés de classification et d'identification 
devraient être gérées et fournies par des agences 
mon...
UDDI 
• Application directe 
• La recherche du document WSDL associé au 
service est facilitée par une référence spécifiqu...
UDDI 
• Type d'annuaire utile pour la découverte de 
BusinessEntity ou de BusinessService 
• Identification et catégorisat...
WSIL 
• WebService Inspection Language 
• Une méthode de découverte de services décentralisée 
• Considère que l'on connaî...
WSIL : exemple 
<?xml version="1.0" encoding="UTF-8"?> 
<inspection xmlns="http://schemas.xmlsoap.org/ws/2001/10/inspectio...
Web Services et l'existant 
• Une nouvelle technologie pour le middleware 
• Curiosité, méfiance 
Vraiment différent de J2...
Description des services 
• Spécification CORBA 
• Langage de description des interfaces (OMG IDL) 
+ règles de projection...
Description : Coexistence 
• Spécification en cours à l’OMG 
• RFP « CORBA to WSDL/SOAP interworking » 
• Réponse commune ...
Localisation 
• Spécification CORBA 
• Référence CORBA – chaîne de caractère ou URL 
• Annuaire de services (Naming Servic...
Localisation : WebService 
• UDDI 
• Universal Description, Discovery and Integration 
• Le référentiel UDDI vu comme un a...
Localisation 
• Annuaire et découverte de service commun aux 
WebServices et aux architectures CORBA, J2EE 
• Qualité de s...
Communication 
Corba Webservices 
IDL WSDL 
Corba Services UDDI - WSIL 
Corba Stubs/Skeleton Soap messages 
CDR Binary Enc...
Communication 
• CORBA - IIOP 
• Invocation d'opération ou One-way 
• Relocalisation, 
• Multiplexage client-serveur 
• Ab...
Coexistence : CORBA - WS 
• Exposer des composants CORBA sous forme de Web Services 
• Web Services vus comme des composan...
Coexistence : J2EE - WS 
• J2EE 1.4 
• API pour SOAP, WSDL, UDDI 
• SOAP Messaging 
• JAXM, SAAJ, JAX-RPC, JMS 
• WSDL 
• ...
Coexistence : J2EE - WS 
Conteneur de 
servlet 
Conteneur Ejb 
Port Port 
servlet jsp ejb 
RMI/IIOP 
RMI/IIOP 
HTTP/SSL 
S...
Coexistence : J2EE - WS 
• Paquetage pour déploiement 
• Pour Web Component : fichier WAR 
• Pour stateless session bean :...
Coexistence : J2EE - WS 
• Développement sur J2EE 
• WSDL de/vers Web service Endpoint Interface 
(java) 
• Endpoint Inter...
Conclusion 
• WS : De nombreuses caractéritiques en commun avec 
les environnements répartis J2EE, CORBA, Net. 
Réinventer...
Atouts 
• Intégrer au niveau service 
• Contrat métier 
• Contrat technique 
• Orchestration 
• Intermédiation 
Gagner en ...
Produits 
• “HP WS” de HP 
• eSpeak, HP-AS, HP-WS 
• “E2A” de IONA 
• E2A WS Interoperation, Application Server 
• “Cape” ...
Perspectives 
• Perspectives 
• Maturité WS : encore du travail 
• Gestion de la sécurité (Microsoft, IBM, Verisign : WS-S...
WebServices : le futur ! (1) 
• SOAP Recommandations W3C , version 1.2 
• Points à voir 
• La gestion des sessions 
• L'as...
WebServices : le futur ! (2) 
• WSDL Recommandations W3C , version 1.2 
• On trouve encore plusieurs styles de 
génération...
WebServices : le futur ! (3) 
• Stabilisation des autres niveaux de la pile de 
protocole pour les WebServices 
• En parti...
Quelques URLs 
Standards 
http://xml.apache.org/axis. Apache-Axis 
http://www.w3.org/2000/xp SOAP 
http://www.w3.org/XML/S...
Alors ? 
WebServices ? 
Philippe.Bedu@edf.fr
Prochain SlideShare
Chargement dans…5
×

Soap

867 vues

Publié le

  • Soyez le premier à commenter

Soap

  1. 1. WebServices Philippe.Bedu@edf.fr
  2. 2. 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
  3. 3. 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
  4. 4. Web Services (2) • Utilisation pour l'intégration • Dans un portail • Applications d'entreprise • B2B Portail Normalisation d'adresse traduction Achat vente météo traducteur commande B Processus Service météo Intranet Internet
  5. 5. Web Services (3) SGBD procédures cataloguées Adaptateur progiciels Systèmes orientés Messages, courtiers d'Intégration Serveur d'applications Orchestration de Flux
  6. 6. Web Services (4) Services techniques WS-Transaction Services métier ebXML Sécurité WS-Security SOAP : messaging http,httpr,smtp,ftp,mq,iiop… TCP/IP WSDL UDDI, WSIL RosettaNet BPEL WS-coordination Pile de protocoles Processus, workflow Annuaire Description XML-based message Transport
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. SOAP Scenarii (1) Envoi et oublie, avec un ou n récepteurs Noeud SOAP émetteur initial Requête réponse, requête avec acquittement ou RPC sur un protocole de transport assurant la corrélation Noeud SOAP ultime récepteur Appli SOAP Appli SOAP processeur SOAP processeur SOAP Niveau SOAP Niveau protocole de transport Hôte 1 Hôte 2
  13. 13. SOAP Scenarii (2) Noeud SOAP émetteur initial Appli SOAP A Id message processeur SOAP Niveau SOAP Niveau protocole de transport Corrélation de Noeud SOAP ultime récepteur Appli SOAP B Id message processeur SOAP Noeud SOAP émetteur initial Appli SOAP B Id message processeur SOAP messages Hôte 1 Hôte 2 Noeud SOAP ultime récepteur Appli SOAP A Id message processeur SOAP Hôte 2 Hôte 1 Requête réponse, requête avec acquittement ou RPC sur un protocole de transport n'assurant la corrélation
  14. 14. SOAP Scenarii (3) Noeud SOAP émetteur initial Appli SOAP A routage processeur SOAP Niveau protocole de transport Noeud SOAP intermédiaire Appli SOAP B routage processeur SOAP Noeud SOAP ultime récepteur Appli SOAP A routage processeur SOAP Hôte 1 Hôte 2 Hôte 3 Niveau SOAP Changement de protocole possible Requête réponse, requête avec acquittement ou RPC via de multiples intermédiaires
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. 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>
  19. 19. 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>
  20. 20. 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.
  21. 21. 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>
  22. 22. 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>
  23. 23. 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>
  24. 24. SOAP encodage de graphes • L’information est traitée comme un graphe constitué de noeuds intermédiaires ou terminaux et de liens entre ces noeuds. • 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
  25. 25. 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>
  26. 26. 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>
  27. 27. 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>
  28. 28. 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>
  29. 29. 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>
  30. 30. 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>
  31. 31. 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 >
  32. 32. 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>
  33. 33. 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>
  34. 34. 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>
  35. 35. SOAP Principes RPC (1) • Processus Client avec binding http Construction de l'appel de méthode Sérialise en requête SOAP-XML Enveloppe la requête SOAP-XML En requête http Requête http envoyée au serveur SOAP Réponse http reçue du serveur SOAP Extrait la réponse SOAP-XML de la réponse http Désérialise la réponse SOAP-XML En réponse de méthode Retourne la valeur Package soap Serializer/des erializer Encoding/de coding http
  36. 36. SOAP Principes RPC (2) • Processus Serveur avec binding http Requête http du client SOAP envoie requête décodeur Décode la requête http et dé-sérialise la requête SOAP-XML Opération du Service sérialise la réponse SOAP-XML et encode de la réponse http Envoie la réponse Retourne la réponse http au client SOAP Package soap Servlet SOAP Encoding/de coding http et soap Canal de requête du servlet Canal de réponse du servlet Invoque la méthode envoie réponse décodeur
  37. 37. 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 getNorme Application Interface Implantation opération Public et standard Privé et propriétaire wsdl SOAP XML
  38. 38. SOAP Exemple (2) : Serveur-Déploiement Le WSDL associé <Definitions> Racine et namespace <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 A voir plus tard en détail
  39. 39. 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
  40. 40. 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
  41. 41. 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
  42. 42. 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) { …}
  43. 43. 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
  44. 44. 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>.
  45. 45. 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/se rvices/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
  46. 46. 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
  47. 47. WSDL : exemple (3) <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> Puis les paramètres d’entrée et de sortie des opérations du service 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.
  48. 48. 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/"namespa ce="http://cli20ir:9595/axis/services/NormAdresseService/axis/service s/NormAdresseService"use="encoded" /> </wsdl:input> <wsdl:outputname="getNormeResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"namespa ce="http://cli20ir:9595/axis/services/NormAdresseService/axis/service s/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, …).
  49. 49. 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.
  50. 50. 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
  51. 51. UDDI Universal Description, Discovery and Integration Une spécification pour la description et la découverte de WebServices • 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) White Pages Yellow Pages Green Pages
  52. 52. 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).
  53. 53. UDDI • Document XML businessEntity businessKey name URL description contacts businessServices identifierBag categoryBag Contact Contact Phone Address Email Phone Address Email businessService serviceKey tModelKey Name Description BindingTemplates businessService Key Name Description BindingTemplates keyedReference tModelKey keyName keyValue keyedReference tModelKey keyName keyValue keyedReference tModelKey keyName keyValue keyedReference
  54. 54. UDDI businessEntity RD991… EDF-RETD www.edf-retd.fr “Architecture Services…." contacts businessServices identifierBag categoryBag businessService 34257GHF12… Services support Archi “Website where you can … BindingTemplates businessService Key Name Description BindingTemplates BindingTemplate 110293-32009… http://www.edf-retd.fr/sinetics… tModelInstanceDetails tModelInstanceInfo 1112C-2244-3AXA… http://www.edf-retd.fr/catalogArchi keyedReference DFE-2B… DUNS 45231 keyedReference EE123… NAICS 007.. tModelKeys
  55. 55. 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>
  56. 56. UDDI Implantation <import> <service> <port> <port> Interface <types> <messages> <portType> <Binding> UDDI BusinessEntity BusinessService BusinessTemplate BusinessTemplate tModel
  57. 57. Implantation <wsdl:definitions name="NormAdresseService" targetNamespace="http://…"> <import namespace="http://…" location="http://…" /> <wsdl:service name="DoNormeService"> <wsdl:port name="NormAdresseService " UDDI binding="intf:NormAdresseServiceSoapBinding "> … </wsdl:service> </wsdl:definitions> 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> <BusinessEntity businessKey="…" <name> Normalisation d'adresse </name> … <businessService serviceKey="…"> <name> DoNormeService </name> <BindingTemplates bindingKey="…"> <TmodelInstanceInfo tModelKey="…"> <overviewDoc> <overviewdocURL>http://…# NormAdresseService </overviewdocURL>… </BindingTemplates> </businessService> </BusinessEntity> <tModel tModelKey="…" <name> http://… </name> … <overviewDoc> <overviewdocURL>http://…#NormAdresseServic eSoapBinding targetNamespace="http://…"> </overviewdocURL>… <categoryBag> <KeyedReference tModemKey="…" keyname="uddi-org: types keyvalue="wsdlSpec"/> </ categoryBag > </tModel> UDDI
  58. 58. 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
  59. 59. 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:// …” );
  60. 60. UDDI • Inquiry API • Trouver • find_business • find_service • find_binding • find_tModel • Plus de détails • get_businessDetail • get_serviceDetail • get_bindingDetail • get_tModelDetail • 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
  61. 61. UDDI Client Noeud annuaire UDDI Requête UDDI SOAP Réponse UDDI SOAP Serveur HTTP Serveur SOAP Annuaire UDDI Noeud WS WSDL WebService UDDI4J WSDL4J Enregistrement à partir d'un fichier wsdl Enregistrement UDDI
  62. 62. UDDI Client Noeud annuaire UDDI Requête UDDI SOAP Réponse UDDI SOAP Serveur HTTP Serveur SOAP Annuaire UDDI Noeud WS WSDL WebService UDDI4J Utilisation UDDI URI="http://…" Communication avec le WS
  63. 63. 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
  64. 64. 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; On peut aussi faire for (int i = 0; i < businessServices.size(); i++) { un find_service 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;
  65. 65. 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();
  66. 66. 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
  67. 67. 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
  68. 68. 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","");
  69. 69. 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 oeuvre relativement complexe • On lui préfère une approche plus pragmatique • WSIL • Fournit une liste simple des services disponibles
  70. 70. 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 XML UDDI WSDL HTML
  71. 71. 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
  72. 72. Web Services et l'existant • Une nouvelle technologie pour le middleware • Curiosité, méfiance Vraiment différent de J2EE ou CORBA ? • Que gagne-t-on ? • Que perd-on ? • Comment gérer la transition ?
  73. 73. 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
  74. 74. 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 Port (représentation du web service) Service endpoint interface Wsdl :portType Service instance Wsdl :service Usine à stubs Service interface Ejb ou JAX-RPC web component Cycle de vie de la responsabilité su serveur d'applications Wsdl :portType, transport et encoding binding Wsdl:portadress
  75. 75. 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 client courtier serveur 1 - import 2 - export • 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 ORB 3 - interaction
  76. 76. 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
  77. 77. 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
  78. 78. Communication Corba Webservices IDL WSDL Corba Services UDDI - WSIL Corba Stubs/Skeleton Soap messages CDR Binary Encoding XML unicode Encoding GIOP/IIOP , ESIOP HTTP,FTP,SMTP TCP/IP TCP/IP
  79. 79. 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
  80. 80. Coexistence : CORBA - WS • Exposer des composants CORBA sous forme de Web Services • Web Services vus comme des composants CORBA • Adaptation des environnements CORBA. Conteneur d’applications Web Référentiel UDDI Client SOAP Systèmes CORBA Description WSDL Serveur SOAP Client CORBA Serveur Web
  81. 81. 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
  82. 82. Coexistence : J2EE - WS Conteneur de servlet Conteneur Ejb Port Port servlet jsp ejb RMI/IIOP RMI/IIOP HTTP/SSL SOAP/HTTP et autres bindings Noyau J2EE Noyau J2EE
  83. 83. 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
  84. 84. 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
  85. 85. 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)
  86. 86. Atouts • Intégrer au niveau service • Contrat métier • Contrat technique • Orchestration • Intermédiation Gagner en abstraction
  87. 87. 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
  88. 88. 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
  89. 89. 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
  90. 90. 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 oeuvre assez complexe • Pas de modérateur IBM, MicroSoft,HP, Oracle, SAP,… • WSIL version 1.0 une solution intéressante
  91. 91. 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
  92. 92. 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/
  93. 93. Alors ? WebServices ? Philippe.Bedu@edf.fr

×