Nous avons donc, coté fournisseur de service, un développeur qui souhaite se concentrer sur l’écriture les méthodes (opérations) propres au service qu’il veut offrir et, coté consommateur de service, un autre développeur qui souhaite luis aussi se concentrer sur la couche métier de son application, et qui a besoin des informations du WS et souhaite les obtenir le plus simplement possible.
Entre les deux, toute l’information relevante que le web service offre, doit être mise en forme pour répondre au « cahier des charges » que constitue le WSDL.
Pour prendre une métaphore postale, il s’agit d’un part de rédiger et mettre en forme le contenu XML du message transmis (c’est la rédaction de la lettre à proprement parler, dans une langue de préférence compréhensible par le destinataire – on peut imaginer qu’il faille préciser des clés de traduction pour le destinataire étranger), et d’autre part d’encapsuler ce message dans une enveloppe SOAP, propice à la transmission au travers du réseau et à son décodage à réception par le destinataire (il s’agit là de plier la lettre que l’on a écrite, de la glisser dans l’enveloppe sur laquelle on colle un timbre et écrit l’adresse). Le reste n’est que transmission.
C’est le serveur d’application WS qui s’y colle. Dans un projet alliant la technologie Java et autres outils du monde open source, le serveur d’application qui s’impose est bien évidemment Apache Axis. Nous aurons l’occasion par la suite de faire plus ample connaissance avec cet outil, mais dans l’immédiat, précisons que son rôle, central, dans notre projet est le suivant :
- Installé en tant que « webapp » du container de servlet Apache Tomcat, d’héberger notre service web pour le rendre accessible sur le réseau. A ce titre, il gère la « tuyauterie » SOAP.
- De nous fournir des outils permettant à partir d’une description WSDL de construire des structures Java nous facilitant la publication ou la consommation de nos web services.
- De nous fournir des API permettant de manipuler si nécessaire les composants des messages SOAP (envelope, body, header).
En résumé, et du point de vue du développeur, la chaîne du web service se présente de la façon suivante :
- 1. Coté serveur :
- a. écrire l’application et les méthodes fournissant le service
- b. Mettre ces méthodes à disposition du plus grand nombre, c’est le déploiement.
- c. Mettre à disposition du consommateur du WS une description du service proposé et la manière d’y accéder. C’est la création de la description WSDL
- 2. Du coté du consommateur du WS :
- a. écrire l’application qui devra consommer les données fournies par le WS, hors problématique chargement de ces données.
- b. A partir de la description WSDL, y ajouter une couche de permettant d’accéder au données du web service.
Les points 1a et 2a relèvent d’un développement « à la main » en Java. Les points 1b, 1c et 2b nécessiteront, quant à eux, l’aide des outils d’Axis évoqués au paragraphe précédent. Nous y reviendrons en détail dans la partie développement.
