Rubriques

IntroductionTo top of page

RAD 6.0 contient un ensemble complet d'outils de support de découverte, de création, de test, de déploiement et de publication de services Web. Ces outils permettent de développer des services Web sur la base des normes les plus récentes, et de déployer ces services dans différents 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 prévues par RAD 6.0 pour développer un service Web et fournit des informations de développement pour le déploiement de services Web et le niveau des options d'interfonctionnement.

Approches de développement To top of page

Dans RAD 6.0, les assistants de services Web permettent de créer un service Web à l'aide d'une approche descendante ou ascendante. L'approche descendante permet d'utiliser un document WSDL (Web Services Description Language) et de générer un Java bean ou un EJB (Enterprise JavaBean) à utiliser pour créer un service Web. L'approche ascendante permet de créer un service Web à partir d'un Java bean, d'un EJB, d'un fichier DADX (Document Access Definition Extender), d'une URL (Uniform Resource Locator) ou d'un fichier ISD 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'une application JSP créée 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 artefacts conformes aux normes suivantes :

  • WSDL (Web Services Definition Language) version 1.1
  • SOAP (Simple Object Access Protocol) version 1.1 (incluant 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 aux concepts de services Web pour J2EE.

Développement descendant To top of page

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 contient également un assistant permettant de créer un document WSDL). Les deux approches suivantes sont prises en charge :

  • Création d'un Java bean à partir d'un document WSDL

    Vous pouvez créer un Java bean à partir d'un document WSDL et le publier en tant que service Web. Les méthodes de création de Java bean correspondent aux opérations décrites dans le document WSDL et contiennent une implémentation que vous pouvez remplacer. Les considérations suivantes s'appliquent à cette approche et aux artefacts 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 du service. Vous avez également la possibilité de générer un document normalisé WSDL (WSIL) pour le service Web créé.
    • Le service Web créé doit faire partie d'un projet Web.

 

  • Création d'un EJB à partir d'un document WSDL

    Cette approche est similaire à l'approche précédente et permet de créer un EJB de session sans état à partir d'un document WSDL, puis de le publier en tant que service Web. Les méthodes EJB correspondent aux opérations décrites dans le document WSDL et contiennent une implémentation que vous pouvez remplacer. Les considérations suivantes s'appliquent à cette approche et aux artefacts 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 (reportez-vous aux 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 du service. Vous avez également la possibilité de générer un document normalisé WSDL (WSIL) pour le service Web créé.
    • Le service Web créé doit faire partie d'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 même fichier EAR.

Développement ascendantTo top of page

L'objectif du développement ascendant consiste à publier 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 Java bean

    Cette approche permet de sélectionner un Java bean existant et de le publier en tant que service Web. Les artefacts générés incluent :

    • Fichier WSDL : ce fichier décrit le service Web et porte l'extension .wsdl. Vous pouvez choisir parmi trois styles de fichier WSDL (Document/Littéral, RPC/Littéral et RPC/Codé). Pour plus d'informations sur l'impact de l'interfonctionnement de chaque option, reportez-vous à la section consacrée à la conformité des profils WS-I.
    • Interface d'extrémité de services (SEI) : cette interface Java définit les méthodes du service Web. Son nom de fichier porte un suffixe _SEI.
    • 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.
    • Fichiers de mappage JAX-RPC : ces fichiers définissent le mappage des éléments Java du service Web à WSDL.
  •  

  • Création d'un service Web à partir d'un EJB

    Vous pouvez publier les méthodes d'un bean de session sans état en tant que service Web. Les artefacts générés sont similaires à ceux créés pour un Java bean 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 artefacts ainsi créés :

    • Le service Web créé doit faire partie d'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. Sinon, 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. Les données accessibles via DB2 XML Extender se composent de documents XML mappés à une base de données DB2 via 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 ou par un fichier DAD. Les artefacts 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 artefacts 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 créé doit faire partie d'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 artefacts 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 servlet et à la part URI, et les paramètres correspondent aux paramètres d'entrée du servlet.
    • Le service Web créé doit faire partie d'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 contient 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 numérotation et de dénumérotation). Vous pouvez créer un service Web à partir d'un fichier ISD et des 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 données de configuration et de mappage. Les considérations suivantes s'appliquent à cette approche et aux artefacts 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 créé doit faire partie d'un projet Web.

Principes et conseils applicables au développement To top of page

Les sections suivantes contiennent des considérations importantes sur le développement de services Web dans RAD 6.0. Elles décrivent les options de développement disponibles pour le développement et la conformité WS-I de votre service Web.

Dépendances de déploiement To top of page

Les approches (descendante et ascendante) de création de service Web dépendent de l'environnement d'exécution envisagé. RAD 6.0 prend en charge les environnements d'exécution de services Web suivants :

  • IBM WebSphere v6

    Il s'agit de l'environnement par défaut dans RAD 6.0 ; il est recommandé pour les utilisations 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 l'utilisation de connexions HTTP ou de files d'attente 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 représente 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'interfonctionnement des services Web (reportez-vous à la section consacrée aux problèmes d'utilisation de l'environnement d'exécution Apache Axis 1.0 dans le contenu de l'aide)

Il est recommandé de sélectionner l'environnement d'exécution IBM WebSphere v5, sauf si votre cible de déploiement nécessite l'utilisation d'une implémentation Apache SOAP ou Apache Axis (dans ce cas, tenez compte des limitations associées décrites dans le contenu de l'aide (limitations des services Web). 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 JavaBean à partir d'un document WSDL
Oui
Oui
Oui
Création d'un EJB à partir d'un document WSDL
Oui
Non
Non
Création d'un service Web à partir d'un JavaBean
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
Non
Oui
Non

Tableau 1 - Approche de création de service Web prise en charge pour les différents environnements d'exécution

Conformité du profil de base WS-I To top of page

Le profil de base d'interfonctionnement des services Web (WS-I) est un ensemble de conditions publié par l'organisation WS-I pour promouvoir l'interfonctionnement des services Web sur les différentes plates-formes, sur les différents systèmes d'exploitation et pour les différents langages de programmation. Il définit les conditions de trafic et de 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 conditions applicables au profil WS-I 1.0. Vous pouvez configurer le niveau de conformité WS-I(niveau exigé, suggéré ou ignoré (valeur par défaut)) pour l'espace de travail ou le projet concerné avant de développer un service Web ou d'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. Les principes suivants doivent être pris en compte :

  • 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 transmission de messages 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 chiffrage XML ne sont pas compatibles avec WS-I)

Considérations liées au proxy client To top of page

  • Vous pouvez, pendant la création d'un service Web, générer de façon facultative 2 types de proxy client :
    • Proxy Javabean

    Le proxy client Javabean 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) pour chacune des méthodes de service Web à appeler. Elle nécessite l'installation préalable au sein de la base de données du package UDF de services Web et de DB2 XML Extender. Le package UDF est créé et ajouté à la définition de base de données avec tous les artefacts 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 To top of page

Pour plus d'informations sur les sujets ci-dessous, reportez-vous au lien correspondant.

 

RUP (Rational Unified Process)   2003.06.15