Architecture des S.I.: Tutorial Service Web avec WebSphere 6.1

Ce tutorial adapte pour IBM WebSphere 6.1, mon tutorial sur la création de Service Web avec JBoss 5.1 qui peut être trouvé à l’adresse suivante : http://jl2tho.blogspot.com/2011/11/tutorial-service-web-avec-jbosss-51.html.

Il s’agit d’un tutorial qui présente la création d’un Service Web très simple en utilisant le mécanisme d’annotation JAX-WS avec comme serveur d’application WebSphere 6.1.

J’ai cherché dans ce tutorial à me débarrasser de l’outillage IBM qui semble ajouter de nombreux fichiers de configuration spécifiques à WebSphere. L’ensemble du tutorial (en dehors du serveur d’application) est indépendant de l’outillage IBM.

Une rapide présentation des Services Web avec WebSphere 6.1

Tout d’abord, il faut savoir que la version standard de WebSphere 6.1 ne permet pas la réalisation de Service Web reposant sur la norme JAX-WS. Pour bénéficier du support de la norme, il faut ajouter deux Feature Packs (Service Web et EJB 3.0) ainsi que 3 Fix Packs.

Le même WAR que j’avais déployé sur la version 6.1.0 qui ne fonctionnait pas, fonctionne parfaitement une fois toutes ces installations réalisées.

WebSphere s’appuie sur les EJB 3.0 pour définir et implémenter les Services Web. Il respecte les spécifications de JAX-WS pour la définition des services web. Cette norme définit un ensemble d’annotations qui permettent la transformation d’un EJB 3.0 en service web. Les annotations sont interprétées par le serveur d’application afin de transformer les classes Java en service web.

La définition des différentes annotations peut être trouvée sur le site de Sun à l’adresse suivante : http://java.sun.com/javaee/5/docs/api/javax/jws/package-summary.html

Les annotations simplifient grandement la réalisation de services web. Elles permettent de définir :

toutes les informations pertinentes pour construire un WSDL à partir de la classe Java
les correspondances entre les messages SOAP du service web et la méthode de la classe Java responsable du traitement.

Par exemple, il est possible de définir le nom du service web, des opérations et des paramètres.

Les services web nécessite la présence d’un serveur d’application capable d’être serveur de service web : dans notre tutorial nous allons utiliser WebSphere dans sa version 6.1.

Organisation du tutorial

Ce tutorial a pour objectif de présenter une mise en œuvre basique d’un Service Web avec WebSphere 6.1.

Le tutorial comprendra les étapes suivantes :

La configuration du serveur WebSphere
La réalisation du service web dans Eclipse
Le déploiement du service web dans WebSphere.
L’analyse du code et du WSDL

Configuration

Configuration de Websphere 6.1

Le tutorial a été réalisé sur un poste Windows 7.

Ce tutorial repose sur l’utilisation d’Eclipse 3.5 et sa distribution JEE. Le runtime JDK utilisé par Eclipse est la version 1.5.0_11.

Le serveur d’application utilisée est une version d’essai de IBM WebSphere 6.1 : il s’agit d’une version 32 bits pour Windows que j’ai installé dans C:\IBM afin d’éviter tout problème de droits lié à Windows 7. Pour que l’installation fonctionne sur mon poste, j’ai du utiliser le fichier responsefile.base.txt et faire une installation en mode commande.

Je ne rentrerai pas dans le détail de cette installation, ce n’est pas l’objet de ce billet. De même, je ne rentrerai pas dans le détail des installations nécessaires pour les services web : j’ai suivi, l’excellent tutorial (en anglais) qui se trouve à l’adresse suivante : http://www.myeclipseide.com/documentation/quickstarts/blueedition/blue_install_websphere6.1/

Je précise que j’ai du récupérer :

l’UpdateInstaller de Webphere 6.1.9 : download.updii.61019.windows.ia32.zip : Cet utilitaire est nécessaire à l’installation des Fix Pack. Je l’ai installé dans C:\IBM\WebSphere.
les 3 Fix Packs suivants :
- 6.1.0-WS-WAS-WinX32-FP0000013.pak
- 6.1.0.9-WS-WASWebSvc-IFPK53084.pak
- 6.1.0-WS-WASWebSvc-WinX32-FP0000013.pak
les 2 feature Packs suivants :
- 6.1.0-WS-WAS-WSFEP-WinX32.zip : pour les Services Web
- fep.61.ejb3.windows.ia32.zip : pour les EJB 3.0

Tous les fichiers ont été récupéré depuis le site IBM : il s’agit d’autant de téléchargements supplémentaires. J’ai utilisé l’utilitaire DownLoad Director d’IBM pour tous à l’exception du Fix Pack 6.1.0.9-WS-WASWebSvc-IFPK53084.pak pour lequel le serveur a répondu pendant toute une journée qu’il était occupé. Pour ce dernier, j’ai utilisé le téléchargement par HTTP.

Attention ! utilisant Windows 7 qui n’est pas officiellement supporté par WebSphere 6.1, j’ai du à plusieurs reprises acquitter un message m’indiquant que je n’avais pas passé le test de compatibilité. Il a toujours été possible de Continuer l’installation.

De même à chaque fin d’installation, on m’a averti que l’installation s’était peut-être mal passée, j’ai du répondre que je considérais que l’installation était correcte

En dehors de ces petits avertissements, j’ai respecté à la lettre la procédure d’installation indiquée plus haut qui se décompose comme suit :

J’ai arrêté mon serveur WebSphere : je suis passé par le menu “Tous les programmes” –> “IBM Websphere” –> “Application Server V6.1” –> Profils –> AppSrv01 –> “Arrêter le serveur”.
J’ai installé l’UpdateInstaller.
J’ai copié le fichier 6.1.0-WS-WAS-WinX32-FP0000013.pak dans C:\IBM\WebSphere\updateInstaller\maintenance
J’ai lancé son installation par l’updateInstaller en cliquant droit sur le menu “Tous les programmes” –> “IBM Websphere” –> “Update Installer for Websphere V6.1 Software –> Update Installer” et choisissant “Executer en tant qu’administrateur”
J’ai installé (sans passer par l’update installer) le Feature Pack 6.1.0-WS-WAS-WSFEP-WinX32.zip après l’avoir dézippé.
J’ai copié les fichiers 6.1.0.9-WS-WASWebSvc-IFPK53084.pak et 6.1.0-WS-WASWebSvc-WinX32-FP0000013.pak dans C:\IBM\WebSphere\updateInstaller\maintenance
J’ai lancé l’installation de 6.1.0.9-WS-WASWebSvc-IFPK53084.pak par l’updateInstaller (toujours en tant qu’administrateur)
J’ai lancé l’installation de 6.1.0-WS-WASWebSvc-WinX32-FP0000013.pak par l’updateInstaller (toujours en tant qu’administrateur)
J’ai installé (sans passer par l’update installer) le Feature Pack fep.61.ejb3.windows.ia32.zip après l’avoir dézippé.
J’ai fait l’augmentation du Profil AppSrv01 en lui ajoutant le profil EJB 3.0

Je n’ai pas eu besoin de récréé un Profil avec le profil Service Web JAX-WS.

Cette phase de configuration peut bien prendre un ou deux jours. Il s’agit réellement d’une opération fastidieuse.

Création d’un projet Eclipse pour le service web

Autant avec JBoss, j’avais pu me contenter de créer un jar (voir mon tutorial http://jl2tho.blogspot.com/2011/11/tutorial-service-web-avec-jbosss-51.html), avec WebSphere 6.1, j’ai été obligé de passer par un WAR.

Dans Eclipse, on crée un projet de type “Dynamic Web Project” que l’on nommera MaCalculetteWasSwWar. Ces projets permettent la création d’un WAR.

Dans Eclipse, à partir de la barre de menu : File -> New –> Other.

Dans la dialogue New, choisir le dossier “Web” puis le nœud “Dynamic Web Project”. Appuyez sur le bouton Next.

Pour Project name, tapez : MaCalculetteWasSwWar et laissez les autres options par défaut (je rappelle que WebSphere 6.1 utilise un Runtime Java 1.5, il faudra donc éviter d’utiliser un Runtime 1.6).

Appuyez sur Finish. Acceptez le choix de la perspective si la dialogue « Open Associated Perspective » s’affiche.

Ajout des External Jars

Nous allons ajouter des external jars au projet : ces jars ne sont pas déployé dans le war. Ils sont juste nécessaire pour la phase de compilation. Il s’agit de jar qui font parti du serveur d’application.

Il faut importer des jar WebSphere : cliquez droit sur le projet dans l’explorateur et choisissez Properties. Dans la dialogue qui s’ouvre choisir « Java Build Path ».

Appuyer sur « Add External Jars.. », et utiliser l’explorateur pour aller dans le répertoire C:\IBM\WebSphere\AppServer\lib et sélectionnez le jar suivant :

j2ee.jar qui définit l’annotation @Remote

Validez en appuyant sur Ouvrir.

Appuyer sur « Add External Jars.. », et utiliser l’explorateur pour aller dans le répertoire C:\IBM\WebSphere\AppServer\runtimes et sélectionnez le jar suivant :

com.ibm.jaxws.thinclient_6.1.0.jar qui définit les annotations @WebService, @SOAPBinding et @SOAPBinding

Validez en appuyant sur Ouvrir.

Validez en appuyant sur le bouton OK.

Notre poste est maintenant correctement configuré pour construire un Service Web.

Création de l’interface

Nous commençons par créer l’interface du service. L’interface définit les méthodes qui seront disponibles dans l’EJB et le service web.

Nous allons créer l’interface fr.j2ltho.calculette.was.Calculette. Par rapport à la définition d’un EJB, il faut ajouter deux autres informations au niveau de la classe :

Le nom du service web qui sera dans notre cas ICalculetteSw
Le format et le style des messages échangés entre le client et le serveur. En d’autre terme, on choisit entre RPC/encoded et Document/literal, tout comme on choisit pour un Document/Literal s’il est wrapped ou unwrapped. Le format le plus répandu et portable étant Document/Literal/Wrapped c’est ce dernier que l’on retiendra.

Ensuite pour chaque méthode, il faut indiquer qu’elle est accessible comme opération du service web, il est possible de définir son nom pour le service web, le nom du paramètre de sortie et le nom des paramètres dans le fichier WSDL (ce point est important car par défaut, leur nom est arg0, arg1…).

Création de l’interface

Dans Eclipse, à partir de la barre de menu : File -> New -> Interface.

Dans la dialogue New Java Interface:

Pour Package, tapez : fr.j2ltho.calculette.was
Pour Name tapez : Calculette

Laissez les autres options par défaut et appuyez sur Finish.

On modifie le code pour définir les deux méthodes add et substract du service.

On ajoute l’annotation @Remote pour spécifier au conteneur d’EJB qu’il devra créé un lien de type Remote avec cette interface pour l’EJB.

Ajout des annotations Service Web

On ajoute l’annotation @WebService qui déclare la classe comme un service web. Le paramètre name, permet de définir un nom différent de celui de la classe. C’est le nom du portType du WSDL. Ce sera le nom également de la classe d’interface cliente si on utilise l’outil JBoss wsconsume pour créer les classes clientes à partir du WSDL.

On ajoute ensuite l’annotation @SOAPBinding qui permet de définir le format des messages :

Le paramètre style permet de choisir entre DOCUMENT et RPC,
le paramètre use permet de choisir entre LITERAL et ENCODED
le paramètre parameterStyle entre WRAPPED ou BARE (unwrapped).

Il faut ensuite pour chaque méthode ajouter le tag @WebMethod pour indiquer qu’il s’agira d’une opération du service web. Le paramètre operationName permet de définir un nom dans le WSDL différent de celui de la méthode Java. Il est également possible grâce au tag @WebResult de définir le nom du paramètre de sortie de la méthode tel qu’il apparait dans le WSDL.

Pour chaque paramètre, il est possible de définir grâce au tag @WebParam son nom (par défaut ce sera arg0, arg…) mais également grâce à la propriété mode si un paramètre est IN, OUT ou IN/OUT.

On obtient le code suivant (en gras le code ajouté par rapport à l’EJB):

package fr.j2ltho.calculette.was;

import javax.ejb.Remote;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebResult;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;

@Remote
@WebService(name = "ICalculetteSw")
@SOAPBinding(style=Style.DOCUMENT, use=SOAPBinding.Use.LITERAL, parameterStyle= SOAPBinding.ParameterStyle.WRAPPED)
public interface Calculette {

    @WebMethod(operationName="ajouterWithWAS")
    @WebResult(name = "resultat")
    public int add(int x, int y);

    @WebMethod
    public int subtract(
    @WebParam(name = "x")
    int x,
    @WebParam(name = "y")
    int y);

}

Création du Bean

Pour la classe qui implémente le service web défini par l’interface précédente, il est possible d’utiliser l’implémentation de l’EJB : Il suffira d’y ajouter l’annotation @Webservice en indiquant la propriété endpointInterface : cette propriété doit pointer vers l’interface du service. C’est grâce aux informations contenue dans l’interface que le conteneur saura quel WSDL généré.

Nous commençons par créer la classe qui implémente le service.

Dans Eclipse, à partir de la barre de menu : File -> New -> Class.

Dans la dialogue New Java Class :

Pour Package, tapez : fr.j2ltho.calculette.was
Pour Name tapez : CalculetteBean

Appuyez, sur le bouton Add.. afin de définir l’interface. Dans la dialogue « Implemented Interfaces Selection » tapez Calculette puis sélectionnez l’interface Calculette – fr.j2ltho.calculette.was de votre projet. Validez en appuyant sur Ok. La dialogue se referme et l’interface apparait dans la liste Interfaces de la dialogue « New java Class ».

Laissez les autres options par défaut et appuyez sur Finish. Le code de la classe apparait avec les deux méthodes créées, il faut maintenant compléter le code.

Il faut également ajouter :

l’annotation @Stateless en début de classe. Cette annotation précise que cet EJB sera sans état : il ne conserve pas une mémoire de ce qu’il a fait précédemment.
l’annotation @WebService pour indiquer la classe d’interface qui contient les annotations décrivant le service web. Il permet également de définir le nom du service web tel qu’il apparait dans le WSDL.

On obtient le code suivant :

package fr.j2ltho.calculette.was;

import javax.ejb.Stateless;
import javax.jws.WebService;

@Stateless
@WebService(endpointInterface="fr.j2ltho.calculette.was.Calculette", serviceName="CalculetteWasSw")
public class CalculetteBean implements Calculette {

    public int add(int x, int y) {
        return x + y ;
        }

    public int subtract(int x, int y) {
        return x - y;
        }

}

Assurez vous d’avoir bien sauvegarder la classe et son interface.

Déploiement du service web sur Websphere 6.1

Nous avons du créer un Dynamic Web Project afin de pouvoir créer simplement un WAR pour déployer le Service Web dans Websphere.

Avant de créer le war puis de le déployer, nous allons finir la configuration du projet en modifiant le fichier web.xml afin d’y déclarer notre service web.

Déclarer un service web dans le web.xml

Dans le répertoire WebContent –> WEB-INF de votre projet, se trouve le fichier web.xml. Editer ce fichier.

On ajoute la déclaration de la servlet qui correspondra au service web.

servlet-name correspond au serviceName de l’annotation WebService du bean CalculetteBean. C’est ce nom qui sera utilisé pour accéder au WSDL
servlet-class correspond au nom complet du bean qui implémente le service web.

On obtient le code suivant :

?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" id="WebApp_ID" version="2.5">
<display-name>MaCalculetteWasSwWar</display-name>
    <servlet>
        <servlet-name>CalculetteWasSw</servlet-name>
        <servlet-class>fr.j2ltho.calculette.was.CalculetteBean</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>CalculetteWasSw</servlet-name>
        <url-pattern>/*</url-pattern>
    </servlet-mapping>
<welcome-file-list>
    <welcome-file>index.html</welcome-file>
    <welcome-file>index.htm</welcome-file>
    <welcome-file>index.jsp</welcome-file>
    <welcome-file>default.html</welcome-file>
    <welcome-file>default.htm</welcome-file>
    <welcome-file>default.jsp</welcome-file>
</welcome-file-list>
</web-app>

Génération du War

Assurez vous d’avoir bien sauvegarder l’ensemble des fichiers.

Cliquez droit dans l’explorateur de ressource d’Eclipse sur votre projet MaCalculetteWasSwWar, sélectionnez Export –> WAR File, dans la dialogue « Export » qui s’affiche choisissez :

Web Project : MaCalculetteWasSwWar qui est le nom de votre projet
Destination : Naviguez pour sélectionner l’emplacement et le nom du WAR File. Pour ma part je l’ai créé sur le bureau. Le nom du fichier est MaCalculetteWasSwWar.war.
Décochez l’option “Optimize for a specific server runtime”

Le nom du war n’a aucune importance, il n’est pas utilisé pour obtenir le WSDL et n’a aucun d’impact sur le contenu du WSDL.

Appuyez, ensuite sur Finish. Vous devriez trouver un fichier MaCalculetteWasSwWar.war sur le bureau.

Déploiement sous WebSphere 6.1

Le serveur doit être lancé, soit il est lancé automatiquement au démarrage (en tant que service Windows), soit il peut être démarré par le menu : “Tous les programmes” –> “IBM Websphere” –> “Application Server V6.1” –> Profils –> AppSrv01 –> “Démarrer le serveur”.

On se connecte à la console d’administration : https://localhost:9043/ibm/console/logon.jsp

Sélectionnez sous le nœud Applications le lien “Installation d’une nouvelle application”

Dans Système de fichiers local, sélectionnez MaCalculetteWasSwWar.war et saisir pour :

Racine du contexte : MaCalculetteWasSwWar : j’ai repris le nom du projet Eclipse qui est également le display name du web.xml. Cela sera utile pour récupérer le WSDL.

En théorie, cet écran permet le déploiement direct d’un JAR. Cette option ne fonctionne que suite à l’installation de la série de Feature et Fix Packs. Sans ces packs, il n’est pas possible d’installer simplement un jar dans WebSphere 6.1. Néanmoins dans mon cas, si le JAR semble avoir été correctement déployé, je n’ai pas pu accéder au WSDL. L’application WebSphere résultant du déploiement n’avait pas les mêmes options que celle contenant un Service Web correctement déployé. C’est pour cette raison que nous sommes passé dans ce tutorial par un WAR.

Appuyez sur Suivant.

Sur l’écran “sélection des options d’installation”, on choisit :

On coche : “Déploiement de beans entreprise”
Nom de l’application : on laisse le nom par défaut en : MaCalculetteWasSwWar_war
On coche “Déploiement de services Web”

On appuie sur Suivant, sur l’écran “Mapper les modules vers les serveurs”, je laisse les options par défaut :

On appuie sur Suivant puis Terminer. L’écran Installation en cours s’affiche. On obtient après un délai, la page suivante :

On appuie sur le lien Sauvegarder qui se trouve en bas de la page.

Si on clique ensuite sur “Applications d’entreprise”, on doit voir une ligne MaCalculetteWasSwWar_war qui s’affiche : il s’agit du nom par défaut laissé à l’étape “Sélection des options d’installation”

Il faut démarrer l’application : cochez la case en début de ligne puis appuyez sur le bouton Démarrer. Après un lapse de temps, une flèche verte s’affiche en fin de ligne.

Vérifier le déploiement

Dans “Applications d’entreprise”, il est possible de cliquer sur le lien MaCalculetteWasSwWar_war. Cela affiche la page de configuration de l’application.

Pour un application contenant un service web fonctionnant correctement, vous pouvez appuyer sur le lien “Publication des fichiers WSDL” dans la rubrique “Propriétés des services Web”.

Sur la nouvelle page, vous devriez avoir une ligne indiquant un fichier zip contenant le WSDL de votre service web.

Si vous obtenez le même résultat, cela indique que votre service web est correctement déployé.

Analyse du WSDL

Dans cette dernière partie nous allons récupérer le WSDL non pas par la console d’administration mais directement par un navigateur puis, nous allons l’analyser.

Récupération du WSDL

Pour récupérer le WSDL d’un Web Service déployé sous WebSphere 6.1, il faut taper l’URL suivante : http://localhost:9080/MaCalculetteWasSwWar/CalculetteWasSw?WSDL

Où :

MaCalculetteWasSwWar est la Racine du contexte qui est spécifiée lors du déploiement du Service Web dans la console d’administration
CalculetteWasSw est le servlet-name dans le web.xml. Il correspond également au serviceName du bean.

Si vous obtenez l’erreur suivante :

Error 404: No target servlet configured for uri:

Vérifier le nom MaCalculetteWasSwWar qui doit correspondre à la racine du contexte.

Si vous obtenez l’erreur suivante :

Error 404: SRVE0201E: Le servlet [fr.j2ltho.calculette.was.CalculetteBean] : n'est pas une classe de servlet

Vérifier le nom CalculetteWasSw qui doit correspondre au servlet name du web.xml. La racine du contexte est correcte. C’est le nom du service qui est incorrecte.

Nous allons analyser succinctement son contenu afin de mettre en évidence les correspondances entre les annotations et le contenu du WSDL.

ServiceName

Tout d’abord le premier tag, le tag definition :

Il contient le nom du Service Web tel qu’il est définit par la propriété serviceName dans l’annotation @WebService du bean d’implémentation.

On retrouve ce nom de service dans le tag service à la fin du WSDL :

Choix du protocole et du format des messages

Le service web est la collection de protocoles qu’il est possible d’utiliser pour déclencher un traitement donné. Dans certains cas plusieurs protocoles peuvent être mis à disposition comme SOAP 1.1, SOAP 1.2 et http.

Le protocole est de type SOAP 1.1. Un seul mécanisme est retenu dans cette implémentation. Il n’y a qu’un seul tag port dans le tag service, de même il n’y a qu’un seul tag binding. C’est la présence de l’annotation @SOAPBinding qui est responsable du choix du protocole SOAP.

Cette annotation permet également de définir le format du message :

Le paramètre style permet de choisir entre DOCUMENT et RPC : cela est visible dans le tag soap:binding la propriété style indique le style.

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

Le paramètre use permet de choisir entre LITERAL et ENCODED : cela est visible dans les tags soap:body avec la propriété use qui indique le mécanisme d’encodage :

<soap:body use="literal" />

Pour finir, le paramètre parameterStyle permettait de choisir entre WRAPPED ou BARE (unwrapped). Le mode WRAPPED implique que dans le message appelant, les paramètres sont encapsulés dans un type portant le nom de l’opération. On peut le vérifier dans la partie message ou operation du WSDL où l’on voit la définition de l’opération ajouterWithWAS indiquer un input message (notez que cette partie diffère de ce que l’on obtient sur JBoss : les noms de message diffère) :

Cet input message fait référence à un message composé d’un unique élément qui porte comme nom ajouterWithWAS (le nom de l’opération) :

Les annotations sur les méthodes

Les annotations @WebMethod, @WebResult et @WebParam utilisées dans l’interface modifie les noms par défaut des opérations dans le WSDL.

On a pu constater que la propriété operationName de @WebMethod a permis pour la méthode add que celle-ci apparaisse sous le nom de ajouterWithWAS dans le WSDL. Le nom par défaut aurez été add (on peut le vérifier avec la méthode substract).

Définition des types

Le WSDL généré par WebSphere n’inclut pas la définition des types : les arguments et les résultats.

Le tag types indique qu’on importe un schéma qui se trouve dans le fichier CalculetteWasSw_schema1.xsd.

Pour afficher la définition, il faut taper l’URL suivante : http://localhost:9080/MaCalculetteWasSwWar/CalculetteWasSw/CalculetteWasSw_schema1.xsd où l’on a remplacé le wsdl par le nom du schéma devant être importé : CalculetteWasSw_schema1.xsd.

Avec l’opération ajouterWithWAS, on constate que les noms des arguments de la méthode sont peu significatifs :

<xs:complexType name="ajouterWithWAS">

<xs:sequence>

<xs:element name="arg0" type="xs:int"/>

<xs:element name="arg1" type="xs:int"/>

</xs:sequence>

</xs:complexType>

Le WSDL étant le contrat entre le client et le serveur, il est également la première source de documentation pour utiliser un service web, il est donc souhaitable que les noms d’éléments soient plus significatifs. On a utilisé pour cela l’annotation @WebParam pour la méthode substract afin d’imposer la valeur de la propriété name. Il faut également savoir que c’est cette valeur qui sera prise par l’outil wsconsume de JBoss afin de nommer les paramètres lors de la génération du stub client (comme on le verra plus loin). En conséquence des noms correctes et significatifs vont grandement simplifier l’utilisation du service.

Pour finir, on constate que l’annotation @WebResult a permis de renommer le nom de l’élément de sortie (la valeur renvoyée par la méthode) :

<xs:complexType name="ajouterWithWASResponse">

<xs:sequence>

<xs:element name="resultat" type="xs:int" />

</xs:sequence>

</xs:complexType>

On obtient une valeur resultat au lieu de return : cela n’a priori pas d’intérêt particulier dans notre cas.

PortType ou name de @WebService

On constate que la propriété name du tag portType du WSDL reprend la valeur de la propriété name de l’annotation @Webservice de l’interface.

Ce nom est utilisé lors de la génération des classes Java cliente avec l’outil wsconsume comme nom pour la classe d’interface qui sera utilisée. Je vous conseille donc d’utiliser le même nom que celui de l’interface afin de simplifier votre développement.

Types des données

Les données pour les types simples qu’on a utilisés utilisent des types simples du XMLSchema :

<xs:element name="arg0" type="xs:int" />

<xs:element name="arg1" type="xs:int" />

Ces types simples sont indépendants des langages de programmation. Cela est un point positif.

Conclusion

Ce tutorial est déjà bien long, je ne montrerai pas la création d’un client. Vous pouvez néanmoins vous reporter à mon tutorial sur les Service Web avec JBoss 5.1 : http://jl2tho.blogspot.com/2011/11/tutorial-service-web-avec-jbosss-51.html. J’y décris longuement la création d’un client. Faites attention ! l’url du WSDL n’est pas la même et les noms de méthodes et services sont différents : il vous faudra faire preuve d’un minimum d’adaptation.

L’exemple est volontairement simple et certainement pas très significatif vis-à-vis de la problématique d’un véritable projet mais il donne un point de départ pour la création de service web sans utiliser tout l’outillage d’IBM : Nous n’avons, hors phase de déploiement, utilisé que des mécanismes standards : ceux sont les mêmes que j’ai utilisé dans mon tutorial JBoss 5.1.

La seule adaptation a été l’utilisation d’un WAR pour le déploiement du service web : on reste ainsi dans une approche standard du déploiement.

Le service web déployé sous WebSphere 6.1 peut être appelé en utilisant un client JBoss 5.1. J’ai testé avec succès l’utilisation du wsconsume de JBoss pour générer mon client. La norme des services web joue (sur une exemple simple) son rôle : faciliter l’interopérabilité entre différentes technologies.

DiggIt!

Enregistrer sur Del.icio.us

Architecture des S.I.

Pages

lundi, novembre 21, 2011

Tutorial Service Web avec WebSphere 6.1