Les Web Services (Services Web) sont un sujet complexe, intégrant plusieurs domaines informatiques (documents, sécurité, programmation, implémentation, etc.). Le nombre de normes est impressionnant, mais est dépassé par la multitude de solutions d'implémentation.
Lors de cette présentation, nous essaierons d'améliorer notre compréhension des Web Services, ferons un survol des normes les plus importantes de l'industrie (WSDL, SOAP et UDDI) et regarderons rapidement quels sont les alternatives d'implémentations (styles et REST).
Nonobstant les nombreux débats sur la définition du terme Web Services, nous utiliserons deux définitions :
Au sens large, les services webs sont des systèmes logiciels, permettant l'intéropérabilité entre plusieurs systèmes logiciels (agents) sur un réseau informatique.
Plus spécifiquement, lorsque nous utilisons comme base les normes du W3C, l'interface du systèmes est définie par un langage lisible par un ordinateur (WSDL). D'autres système logiciels vont communiquer avec le service Web selon sa description en utilisant le langage SOAP, généralement en utilisant XML pour sérialiser les messages et HTTP comme protocole réseau.
Les Web Services rendent disponibles à plus grande échelle les intergiciels (middleware) traditionnels.
Lorsqu'on parle de Web Services, on parle aussi d'architecture orientée services.
On définit l'architecture orientée services comme un style d'architecture qui a comme objectif une interdépendance faible (loose coupling) entre différents agents logiciels (modules, services). L'architecture orientée services promeut la réutilisation de composants logiciels au niveau macro. (Comparée à la programmation orientée objet qui promeut la réutilisation au niveau micro, classes, objets).
Pour atteindre une réutilisation maximale, les services doivent être interopérables. Pour atteindre cette intéropérabilité, la définition des services doit avoir un certain nombre de caractéristiques. En voici quelques-unes :
Comme nous pouvons le constater, il n'est pas nécessaire d'utiliser les Web Services pour atteindre une architecture orientée service. Il est possible de le faire avec CORBA et DCOM. L'ubiquité et la simplicité de HTTP et XML sont toutefois des avantages des Web Services. Les guerres entre vendeurs ont rendu l'interopérabilité plus difficile pour les technologies précédents les Web Services.
Pour utiliser un Web Services, il faut premièrement savoir qu'il existe. UDDI (Universal Description, Discovery and Integration Service) est la norme qui définit le mécanisme pour découvrir dynamiquement des services. Un client pointe vers un registraire UDDI, qui lui donnera la définition du service recherché. Le registraire UDDI sert de pages jaunes et liste les services disponibles. Le registraire UDDI est lui-même un Web Service qu'un client peut questionner.
Pour être capable d'utiliser un Web Services et de programmer un client, il est nécessaire d'en connaître la définition. Le langage WSDL (Web Services Definition Language) défini la sémantique de l'interface au service. En utilisant XML Schema, WSDL défini les paramètre d'entrée et de retour d'un appel au service Web.
Les appels comme tel aux Web Services sont effectués avec le protocol SOAP (Simple Object Access Protocol). SOAP offre le transport d'objets sérialisés et autres données en XML et l'appel de procédures distantes.
UDDI, WSDL et SOAP sont les trois normes principales des Web Services. Les normes UDDI sont proposées par OASIS. WSDL et SOAP font parties des normes W3C.
Pour bien comprendre comment développer un Web Service, nous allons regarder un scénario générique. Une entreprise fournisseure de widgets veut rendre disponible certains services de gestion d'inventaire à l'externe. Elle le fait déjà par une interface Web qui nécessite d'être opérée par des humains ;-) chez ses clients, mais voudrait le faire de façon automatisée avec un Web Service.
Typiquement, le Web Service sert à rendre disponible à plus grande des fonctionnalités déjà implémentée par des intergiciels (middleware). Dans une architecture trois tiers à la J2EE, l'interface de notre Web Service sera le point limite (endpoint) équivalent à la couche présentation (ex: jsp, asp, html) dans un site Web.
WSDL décrit qu'est-ce que le service Web, où le trouver et comment l'appeler. WSDL utilise le concept de port pour définir la connexion au service Web.
Le WSDL est subdivé en plusieurs parties :
Notez que si vous avez peur des espaces de noms et de xml:schemas , sautez tout de suite à la section alternatives : REST ;-)
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://webservicepres.app.bpiette.com"
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:impl="http://webservicepres.app.bpiette.com"
xmlns:intf="http://webservicepres.app.bpiette.com"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!--WSDL created by Apache Axis version: 1.3
Built on Oct 05, 2005 (05:23:37 EDT)-->
<wsdl:types>
<schema elementFormDefault="qualified"
targetNamespace="http://webservicepres.app.bpiette.com"
xmlns="http://www.w3.org/2001/XMLSchema">
<element name="chercheInfoWidget">
<complexType>
<sequence>
<element name="noWidget" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="chercheInfoWidgetResponse">
<complexType>
<sequence>
<element name="chercheInfoWidgetReturn" type="xsd:string"/>
</sequence>
</complexType>
</element>
<wsdl:message name="chercheInfoWidgetResponse">
<wsdl:part element="impl:chercheInfoWidgetResponse" name="parameters"/>
</wsdl:message>
<wsdl:message name="chercheInfoWidgetRequest">
<wsdl:part element="impl:chercheInfoWidget" name="parameters"/>
</wsdl:message>
...
<wsdl:portType name="WidgetService">
<wsdl:operation name="chercheInfoWidget">
<wsdl:input message="impl:chercheInfoWidgetRequest" name="chercheInfoWidgetRequest"/>
<wsdl:output message="impl:chercheInfoWidgetResponse" name="chercheInfoWidgetResponse"/>
</wsdl:operation>
<wsdl:binding name="WidgetServiceSoapBinding" type="impl:WidgetService">
<wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="chercheInfoWidget">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="chercheInfoWidgetRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="chercheInfoWidgetResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
<wsdl:service name="WidgetServiceService">
<wsdl:port binding="impl:WidgetServiceSoapBinding" name="WidgetService">
<wsdlsoap:address location="http://localhost:8080/PresentationWebServiceTest/services/WidgetService"/>
</wsdl:port>
</wsdl:service>
La concept de base de SOAP est l'envelope (balise Envelope) qui est subdivisé en deux parties :
Voici l'appel du client du service Widget Service. Notez qu'il n'y a pas d'entête SOAP, vu la simplicité du service. Les entêtes HTTP sont incluses pour avoir plus d'informations.
POST /PresentationWebServices/services/WidgetService HTTP/1.1
Host: 127.0.0.1:12768
Content-Type: text/xml; charset=utf-8
Content-Length: 362
Accept: application/soap+xml, application/dime, multipart/related, text/*
User-Agent: IBM Web Services Explorer
Cache-Control: no-cache
Pragma: no-cache
SOAPAction: ""
Connection: close
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:q0="http://presentationwebservice.app.bpiette.com"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<q0:chercheInfoWidget>
<q0:noWidget>348</q0:noWidget>
</q0:chercheInfoWidget>
</soapenv:Body>
</soapenv:Envelope>
Nous voyons ici la balise noWidget qui est le paramètre d'entrée définie dans le namespace q0 (com.bpiette.etc) Nous avons défini dans le wsdl comme quoi cette balise pouvant contenir un Integer à l'aide de XML Schema.
Voici la réponse du service
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=utf-8
Date: Sun, 27 Aug 2006 17:40:10 GMT
Connection: close
<?xml version="1.0" encoding="utf-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<chercheInfoWidgetResponse
xmlns="http://presentationwebservice.app.bpiette.com">
<chercheInfoWidgetReturn>C'est un beau Widget</chercheInfoWidgetReturn>
</chercheInfoWidgetResponse>
</soapenv:Body>
</soapenv:Envelope>
Notez le retour qui est de type chercheInfoWidgetReturn qui est mappé en XML Schema pour être de type chaîne de caractères (String).
UDDI offre plusieurs services, en voici quelques exemples :
Voici à quoi ressemblerais une requête pour le W3Québec si celui-ci disposait de web services enregistrés sur un répertoire de services.
<?xml version="1.0" encoding="UTF-8"?>
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
<Body>
<find_service businessKey="*" generic="1.0" xmlns="urn:uddi-org:api" maxRows="5">
<name>W3Québec</name>
</find_service>
</body>
</Envelope>
Et la réponse :
<businessList generic="1.0"
operator="W3Québec"
truncated="false"
xmlns="urn:uddi-org:api">
<businessInfos>
<businessInfo
businessKey="3894572309850239485723049857">
<name>W3Québec</name>
<description xml:lang="fr">
Le W3Québec est né d'une volonté de rehausser la qualité du Web
et du multimédia au Québec pour qu'ils deviennent des outils
de communication accessibles à tous. À cet effet, le W3Québec
entend mettre en lumière les enjeux stratégiques, technologiques,
économiques et sociopolitiques liés à leur utilisation et faire
connaître la valeur ajoutée des normes, standards et bonnes
pratiques à tous les décideurs, acteurs et professionnels
du milieu.
</description>
<serviceInfos>
<serviceInfo
businessKey="8471974012938740129374012934780298347"
serviceKey="4572034957230498570234975802349857230">
<name>Exemple de webservice "widget service"
</serviceInfo>
</serviceInfos>
</businessInfo>
</businessInfos
Pour intégrer les Web Services aux architecures orientées services d'entreprises, il est nécessaire d'avoir des normes qui couvrent la sécurité, les transactions, le chiffrement "end to end", etc. Voici quelques unes de ces normes. Vu leur complexité, nous les verrons pas durant cette présentation.
Il existe plusieurs style de Web Services, nous avons vu dans l'exemple de WSDL que nous utilisions Document Literal.
Ces styles peuvent être utilisé de plusieurs manières :
Pour plus d'intéropérabilté (ex: entre Java et .NET), il est conseillé d'utiliser document/literal pour les messages ou envoie de document, ou document/literal wrapped pour les appels de procédure distantes.
Si vous trouvez que ce qui précéde fût complexe, nous n'avons même pas éfleuré le tip du iceberg. Il doit y avoir une solution plus simple pour faire des services Web plus simplement. La solution existe et s'appelle REST ou Representation State Trasnfer. REST est un style d'architecture de services web qui utilise les standards Web déjà très utilisé, plus spécifiquement HTTP. REST n'utilise pas SOAP, WSDL ou UDDI, et parfois même pas XML. REST utilise des conventions inspirés de HTTP
Si vous suivez certaines règles, une application Web 2.0 utilisant Ajax sera une application de services Web REST. Amazon, Google et plusieurs autres fournissent des services de cette catégorie. Le services Web REST prennent de l'ampleur avec le Web 2.0, mais ne serviront pas nécessairement dans les applications d'entreprises qui demandent plus de complexité au niveau sécurité et transactionnel.
Les IDE et plate-forme peuvent générer plusieurs des artéfacts de services Web (WSDL, SOAP, etc) ce qui rend le tout un peu plus simple. Les implentations sont toutefois encore complexes. Lorsque vous savez que votre application ne sera pas utilisé dans un contexte "enteprisy", le services Web REST sont alternatives qui est importante à évaluer.
Je vais aussi mettre à jour ma section web services sur del.icio.us, vous verrez apparaître de nouveaux liens vers des articles sur cette page
Copyright 2006 Benoit Piette, certains droits réservés.