Invoquer les services Web DB2

group.properties.
Les paramètres de ce fichier déterminent
à  quel serveur DB2 UDB
for iSeries on accède et le profil utilisateur
adopté sur la connexion de
base de données. Voici l’exemple du
contenu d’un fichier group.properties
:

initialContextFactory=
datasourceJNDI=
dbDriver=com.ibm.db2.jdbc.app.
DB2Driver
dbURL=jdbc:db2:*LOCAL/SAMPLE
userID=
password=
namespaceTable=namespacetable.
nst
autoReLoad=true
reloadIntervalSeconds=5
groupNamespaceUri=http://schem
as.ibm.com/sample
enableXmlClob=true

Les propriétés les plus intéressantes
sont en caractères gras. dbDriver
indique quel driver JDBC utiliser.
Le driver JDBC natif iSeries (packagé
avec le Developers Kit for Java) est utilisé
par défaut. Le mot-clé dbURL détermine
sur quel serveur DB2 UDB for
iSeries le service Web est exécuté. La
valeur *LOCAL indique que la base de
données cible est sur le même serveur
qui exécute WAS. SAMPLE est le nom
du schéma (ou bibliothèque) par défaut
qui sera utilisé pour les références
objet DB2 non qualifiées pendant
l’exécution du service Web DB2 ; ce paramètre
est facultatif.
Les paramètres userID et password
contrôlent bien entendu le profil et le
mot de passe utilisateur utilisés pendant
l’exécution du service Web DB2.
Si userID n’est pas spécifié, le profil
utilisateur associé au serveur d’applications
est retenu. Par défaut, le serveur
d’applications fonctionne sous le profil
QEJBSVR. Le profil utilisateur spécifié
utilisé doit avoir des droits sur tous les
objets base de données auxquels on
accède pendant l’exécution du service
Web DB2. Si le paramètre password est
spécifié, la valeur du mot de passe peut
être codée dans le fichier group.properties.

Comme pour les autres applications
WebSphere, le pooling de
connexions peut contribuer à  la performance
des services Web DB2. Les
paramètres du pool de connexions
doivent aussi être établis dans le fichier
group.properties.

Etape 2 : Tester le service
Web DB2.
Comme mentionné plus
haut, WORF peut générer une page de
test pour faciliter le test de votre service
Web DB2 avant de l’offrir aux usagers.
Pour invoquer cette fonction de
test de WORF, l’URL serait

http://:/
///TEST

Pour cet article, l’URL était

http://localhost:7080/services/db2samples
/list.dadx/TEST

Cette URL affiche la page de test
WORF de la figure 8. Sur cette page de
test, le lien de service listEmployees a
été sélectionné, et WORF a généré une
fenêtre d’entrée sur la partie droite
pour demander d’entrer le numéro de
département qui est requis par ce service
Web. Quand le bouton invoke est
sélectionné, le résultat XML renvoyé
par ce service s’affiche en bas de la
page de test.

Etape 3 : Coder l’interface
d’invocation.
On l’a vu, les services
Web peuvent être invoqués via des requêtes
SOAP ou des méthodes HTTP
GET et POST. La figure 9 montre un
exemple d’utilisation d’une requête
SOAP pour invoquer le service
listEmployees. (WebSphere Studio
propose plusieurs outils pour aider à  la
construction et à  l’exécution des requêtes
SOAP.) La requête SOAP est
constituée d’après le WSDL généré par
WORF pour le service listEmployee.
L’URL suivante permet d’accéder au
WSDL généré par WORF pour un service
Web DB2:

http://:/
///WSDL

L’URL utilisée dans cet exemple était

http://localhost:7080/services/db2samples
/list.dadx/WSDL

Un snippet du WSDL pour les services
listDepartments et listEmployees
se trouve en figure 1. Le même WSDL
doit être utilisé si vous voulez enregistrer
un service Web DB2 dans un référentiel
UDDI.