Instructions: Développement de services Web
Ces instructions décrivent la manière de découvrir, créer, tester, déployer et publier des services Web à l'aide de l'environnement de modélisation RAD6.0.
Relations
Description principale

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.

Approches de création de services Web 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 bean Java squelette à partir d'un document WSDL

    Vous pouvez créer un bean Java squelette à partir d'un document WSDL et l'exposer en tant que service Web. Les méthodes de création de beans Java 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 :

    • 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 Web.
  • 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 :
  • Proxy de bean Java

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.