Introduction
RAD 6.0 fournit un ensemble complet d'outils pour la prise en charge de la découverte, de la création, du test, du
déploiement et de la publication de services Web. Ces outils permettent de développer des services Web sur la base des
standards les plus récents, et de déployer ces services dans plusieurs environnements d'exécution. Ils offrent
également un grand nombre d'assistants destinés à faciliter différentes approches de développement. Ce document décrit
les différentes approches permises par RAD 6.0 pour le développement de services Web et aborde des questions de
développement liées au déploiement des services Web et aux options d'interopérabilité.
Approches de développement
Les assistants de services Web de RAD 6.0 permettent de créer un service Web à l'aide d'une approche descendante ou
ascendante. L'approche descendante permet de partir d'un document WSDL (Web Services Description Language) et de
générer un bean Java squelette ou un EJB (Enterprise JavaBean) squelette à utiliser pour créer un service Web.
L'approche ascendante permet de créer un service Web à partir d'un bean Java, d'un EJB, d'un fichier DADX (Document
Access Definition Extender), d'une URL (Uniform Resource Locator) ou d'un fichier ISD (descripteur de déploiement de
service Web) existant. La Figure 1 décrit les approches de création de services Web fournies par RAD 6.0.
Figure 1 - Approches de création de services Web RAD 6.0
Pendant la création d'un service Web, l'assistant permet d'effectuer les opérations suivantes :
-
Test du service Web dès sa création, à l'aide de l'explorateur de services Web.
-
Création d'un proxy client à utiliser dans les applications client pour l'accès au service Web.
-
Test d'un proxy client à l'aide de l'outil UTC (Universal Test Client) ou d'un exemple d'application JSP créé par
cet outil.
-
Publication du service Web dans un registre UDDI (Universal Description, Discovery and Integration) à l'aide de
l'explorateur de services Web.
Les services Web développés dans RAD 6.0 doivent être créés au sein d'un projet Web ou EJB et doivent en outre contenir
des produits conformes aux normes suivantes :
-
WSDL (Web Services Definition Language) version 1.1
-
SOAP (Simple Object Access Protocol) version 1.1 (y compris les implémentations Apache SOAP 2.2 et 2.3)
-
UDDI (Universal Description, Discovery and Integration) version 2.0
-
WSIL (Web Services Inspection Language) version 1.0
-
JAX-RPC (Java API for XML-based Remote Procedure Call), également appelée JSR-101
-
JSR-109 et JSR-921 (Implementing Enterprise Web Services)
-
WS-I (Web Services Interoperability) - profil de base 1.0 (conformité facultative)
-
WS-Security
Pour plus d'informations sur ces sujets, reportez-vous à Concepts : Services Web pour J2EE.
Développement descendant
Le développement descendant permet d'utiliser la définition abstraite d'un service Web contenue dans un document WSDL
pour créer une implémentation concrète de ce service. (Remarque : RAD 6.0 fournit également un assistant permettant de
créer un document WSDL). Les deux approches suivantes sont prises en charge :
-
Création d'un EJB squelette à partir d'un document WSDL
Cette approche est similaire à l'approche précédente et permet de créer un EJB session sans état squelette à
partir d'un document WSDL, puis de l'exposer en tant que service Web. Les méthodes EJB correspondent aux
opérations décrites dans le document WSDL et contiennent une implémentation simple que vous pouvez remplacer.
Les considérations suivantes s'appliquent à cette approche et aux produits ainsi créés :
-
Cette approche ne peut être utilisée que si vous sélectionnez IBM WebSphere v6 comme environnement
d'exécution de services Web (voir Dépendances de déploiement)
-
Vous pouvez entrer l'URI d'un document WSDL, ou encore l'URI d'un document WSIL ou HTML désignant le
fichier WSDL comme source du service Web.
-
Le fichier WSDL doit contenir un élément de service. Vous avez également la possibilité de générer un
document de référence WSDL normalisé (WSIL) pour le service Web créé.
-
Le service Web doit être créé dans un projet EJB. Par ailleurs, un projet de routeur est créé pour
permettre au service Web de recevoir les requêtes via HTTP (Remarque : JMS n'est pas pris en charge dans
cette approche). Le projet de routeur peut être un projet Web ou EJB et ne doit pas être identique au
projet contenant le service Web ; toutefois, il doit se trouver dans le même fichier EAR.
Développement ascendant
L'objectif du développement ascendant consiste à exposer un composant d'application ou une ressource existant(e) en
tant que service Web. Les différentes approches sont détaillées ci-après.
-
Création d'un service Web à partir d'un bean Java
Cette approche permet de sélectionner un bean Java existant et d'exposer ses méthodes en tant que service Web.
Les produits générés incluent :
-
Un fichier WSDL : ce fichier décrit le service Web et porte l'extension .wsdl. Vous pouvez choisir parmi
trois styles de fichiers WSDL (Document/Littéral, RPC/Littéral et RPC/Codé). Pour plus d'informations sur
les conséquences de chaque option en termes d'interopérabilité, reportez-vous à la section consacrée à la
conformité des profils de base WS-I.
-
Une interface de noeud final de services (SEI) : cette interface Java définit les méthodes du service Web.
Son nom de fichier porte un suffixe _SEI.
-
Un descripteur de déploiement de services Web : le fichier webservices.xml spécifie les informations
d'implémentation et de déploiement du service Web.
-
Des fichiers de mappage JAX-RPC : ces fichiers définissent le mappage entre les éléments Java du service
Web et le fichier WSDL.
-
Création d'un service Web à partir d'un EJB
Vous pouvez exposer les méthodes d'un bean session sans état en tant que service Web. Les produits générés sont
similaires à ceux créés pour un bean Java et incluent un fichier WSDL, une interface SEI, un descripteur de
déploiement de services Web et des fichiers de mappage JAX-RPC. Les considérations suivantes s'appliquent à
cette approche et aux produits ainsi créés :
-
Le service Web doit être créé dans un projet EJB.
-
Un projet de routeur doit être créé pour permettre au service Web de recevoir les requêtes émises par les
clients. Si vous utilisez SOAP sur HTTP comme protocole de transport, créez le projet de routeur sous la
forme d'un projet Web. En revanche, lorsque le client utilise SOAP sur JMS, créez ce projet sous forme de
projet EJB (le routeur JMS est alors implémenté en tant que bean orienté messages). Les projets de routeur
et de service Web ne doivent pas être identiques mais doivent tous deux figurer dans le même fichier EAR.
-
Si vous utilisez SOAP sur JMS, vous devez configurer un fournisseur JMS sur votre serveur. Dans ce cas,
vous ne pouvez pas utiliser l'explorateur de services Web pour tester votre service Web.
-
Création d'un service Web à partir d'un fichier DADX
Cette approche permet d'inclure dans un service Web les données DB2 accessibles via DB2 XML Extender ou via des
instructions SQL ordinaires. Les données accessibles via DB2 XML Extender se composent de documents XML mappés
à une base de données DB2 à l'aide d'un document DAD (Document Access Definition). Le point de départ de cette
approche est un fichier DADX qui spécifie la méthode de création d'un service Web à l'aide de l'ensemble des
opérations définies par des instructions SQL ordinaires ou dans un fichier DAD. Les produits générés incluent
le fichier WSDL standard, une interface SEI, un descripteur de déploiement de services Web et des fichiers de
mappage JAX-RPC. Les considérations suivantes s'appliquent à cette approche et aux produits ainsi créés :
-
Cette approche ne peut être utilisée que si vous sélectionnez IBM SOAP comme environnement d'exécution de
services Web (reportez-vous aux dépendances de déploiement).
-
Vous pouvez également générer un fichier DADX à partir d'une combinaison d'une ou de plusieurs instructions
SQL, de procédures stockées et de fichiers DAD.
-
Le fichier DADX doit faire partie d'un groupe DADX qui définit la connexion JDBC et d'autres informations
partagées par les fichiers DADX du groupe.
-
Le service Web doit être créé dans un projet Web.
-
Création d'un service Web à partir d'une URL
A partir de son URL, vous pouvez créer un service Web qui accède directement à un servlet exécuté sur un
serveur distant. L'assistant permet de décrire l'interface de servlet en termes de ports, d'opérations et de
paramètres, et génère un document WSDL décrivant le service Web ainsi obtenu. Les considérations suivantes
s'appliquent à cette approche et aux produits ainsi créés :
-
Cette approche ne peut être utilisée que si vous sélectionnez IBM SOAP comme environnement d'exécution de
services Web (reportez-vous aux dépendances de déploiement).
-
En règle générale, le port correspond à la partie de l'URL réservée au domaine/nom d'hôte, l'opération
correspond à la racine du contexte de servlet et à la partie URI, et les paramètres correspondent aux
paramètres d'entrée du servlet.
-
Le service Web doit être créé dans un projet Web.
-
Il n'existe aucun service Web à déployer car il a déjà été implémenté par l'URL active.
-
Création d'un service Web à partir d'un fichier descripteur de déploiement de service Web
Lorsqu'un service Web est déployé, ses attributs de configuration et d'exécution sont définis dans un fichier
descripteur de déploiement (ISD). Ce fichier fournit des informations sur le service mis à la disposition des
clients par l'environnement d'exécution SOAP (par exemple URI, méthodes, classes d'implémentation (JavaBeans et
EJB), outils de sérialisation et de désérialisation). Vous pouvez créer un service Web à partir d'un fichier
ISD en utilisant les informations disponibles. Cela permet d'inclure les implémentations de services Web
existantes et de les redéployer en tant que nouveaux services Web sans qu'il soit nécessaire de spécifier de
nouveau leurs informations de configuration et de mappage. Les considérations suivantes s'appliquent à cette
approche et aux produits ainsi créés :
-
Cette approche ne peut être utilisée que si vous sélectionnez IBM SOAP comme environnement d'exécution de
services Web (reportez-vous aux dépendances de déploiement).
-
Le service Web doit être créé dans un projet Web.
Instructions relatives au développement
Les sections suivantes abordent des questions importantes relatives au développement de services Web dans RAD 6.0.
Elles décrivent les options de développement disponibles en fonction des exigences de développement et de conformité
WS-I de votre service Web.
Dépendances de déploiement
La disponibilité des approches (descendante et ascendante) de création de service Web dépend de l'environnement
d'exécution envisagé pour le déploiement. RAD 6.0 prend en charge les environnements d'exécution de services Web
suivants :
-
IBM WebSphere v6
Il s'agit de l'environnement d'exécution de services Web par défaut dans RAD 6.0 ; il est recommandé à des fins
de production. Il prend en charge les protocoles de transport JMS et HTTP, ce qui permet aux clients et aux
serveurs de services Web de communiquer via des connexions HTTP ou des files d'attente et des rubriques JMS.
Notez que les services Web doivent être implémentés sous forme d'EJB pour pouvoir être accessibles via le
protocole de transport JMS.
-
IBM SOAP
L'environnement d'exécution IBM SOAP prend en charge les protocoles Apache SOAP version 2.2 et 2.3
(reportez-vous à Ressources) et constituait l'unique environnement d'exécution de services Web pris en charge
dans WebSphere Studio version 5.0 et versions antérieures. Il ne doit être utilisé qu'à des fins de
compatibilité en amont.
-
Apache Axis 1.0
Cet environnement d'exécution prend en charge l'implémentation SOAP Apache Axis version 1.0 (reportez-vous à
Ressources). Il n'est pas recommandé de l'utiliser à des fins de production en raison de problèmes potentiels
d'interopérabilité des services Web (voir la section Problèmes d'utilisation de l'environnement d'exécution
Apache Axis 1.0 dans l'aide de l'outil)
Il est recommandé de sélectionner l'environnement d'exécution IBM WebSphere v5, sauf si votre cible de déploiement
exige précisément d'utiliser une implémentation Apache SOAP ou Apache Axis (dans ce cas, tenez compte des limitations
associées décrites dans la section Limitations des services Web de l'aide de l'outil). Le tableau 1 résume les
approches de création de services Web prises en charge par RAD 6.0 pour chaque environnement d'exécution.
Approche
|
IBM WebSphere v6
|
IBM SOAP
|
Apache Axis 1.0
|
Création d'un bean Java squelette à partir d'un document WSDL
|
Oui
|
Oui
|
Oui
|
Création d'un EJB squelette à partir d'un document WSDL
|
Oui
|
Non
|
Non
|
Création d'un service Web à partir d'un bean Java
|
Oui
|
Oui
|
Oui
|
Création d'un service Web à partir d'un EJB
|
Oui
|
Oui
|
Non
|
Création d'un service Web à partir d'un fichier DADX
|
Non
|
Oui
|
Non
|
Création d'un service Web à partir d'une URL
|
Non
|
Oui
|
Non
|
Création d'un service Web à partir d'un descripteur de déploiement de service Web (ISD)
|
Non
|
Oui
|
Non
|
Tableau 1 - Approche de création de service Web prise en charge pour les différents environnements
d'exécution
Conformité avec le profil de base WS-I
Le profil de base d'interopérabilité des services Web (WS-I) est un ensemble d'exigences publié par l'organisation WS-I
pour promouvoir l'interopérabilité des services Web sur les différentes plateformes, sur les différents systèmes
d'exploitation et pour les différents langages de programmation. Il définit les exigences WSDL et les exigences de
trafic et protocole (SOAP/HTTP) applicables à un service Web pour que ce dernier soit conforme à la norme WS-I. RAD 6.0
inclut des outils de validation que vous pouvez utiliser pour vérifier la conformité d'un service Web aux exigences du
profil de base WS-I 1.0. Vous pouvez soit configurer le niveau de conformité WS-I pour l'espace de travail ou le projet
concerné avant de développer un service Web (sur Exiger, Proposer ou Ignorer - valeur par défaut), soit exécuter les
outils de validation à l'issue du développement.
Il est recommandé de développer des services Web conformes au profil de base WS-I. Pour ce faire, il est recommandé de
respecter les instructions suivantes :
-
Utilisez le style WSDL Document/littéral ou RPC/littéral (le style RPC/Codé n'est pas compatible avec WS-I)
-
Utilisez SOAP sur HTTP comme protocole de messagerie et de transport (SOAP sur JMS n'est pas compatible avec WS-I)
-
N'utilisez pas d'option de sécurité pour le service Web (la signature numérique XML et le chiffrement XML ne sont
pas compatibles avec WS-I)
Considérations liées au proxy client
-
Vous pouvez, pendant la création d'un service Web, générer de façon facultative 2 types de proxy client :
Le proxy client de bean Java permet d'appeler les méthodes de services Web via les appels de procédure éloignée.
Vous ne pouvez le créer que dans le cadre d'un projet Web client si IBM SOAP ou Apache Axis 1.0 est sélectionné
comme environnement d'exécution client. Pour les environnements d'exécution client IBM WebSphere v6, vous pouvez le
créer dans le cadre d'un projet client Web, Java, EJB ou encore d'un projet d'application client.
-
Fonction de service Web définie par l'utilisateur
Cette option permet de créer une fonction DB2 UDF (User-Defined Function, fonction définie par l'utilisateur) pour
chacune des méthodes de service Web à appeler. Elle nécessite l'installation préalable dans la base de données de
DB2 XML Extender et du package UDF consommateur de services Web. Le package UDF est créé et ajouté à la définition
de base de données avec tous les produits client associés stockés dans un projet Web.
-
Sélectionnez un élément EAR différent pour le service Web et pour son client, afin de limiter le risque d'erreurs
d'exécution. Souvenez-vous qu'un client doit représenter une application différente du service Web, et que les
services Web ne sont pas destinés à la communication entre les applications.
Ressources
Pour plus d'informations sur les sujets ci-dessous, reportez-vous au lien correspondant.
|