Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

Extending J2EE Applications with Web Services by sus16053

VIEWS: 5 PAGES: 22

									Table des Matières
Etendre les Applications J2EE avec des Services Web ................................................................ 1
   Qu'est ce qu'un service Web..................................................................................................... 1
   Consommation de services Web existant................................................................................. 2
   Implémentation d'un service web dans une application web .................................................... 6
      Création de Services Web depuis un WSDL...................................................................... 11
      Types de Service Web....................................................................................................... 12
   Implémentation des Services Web dans un Module EJB........................................................ 13
   Test des services Web............................................................................................................ 14
   Ajout d'un Gestionnaire de Message à un service Web.......................................................... 16

Etendre les Applications J2EE
   avec des Services Web
    Dans les sections suivantes, vous allez apprendre combien il est facile de créer et d'ajouter des
services Web à des applications J2EE (aussi bien des Applications Web que des Modules EJB) et
comment les publier pour qu'ils puissent être utilisés par d'autres applications et testés depuis
l'EDI.



Qu'est ce qu'un service Web
    L'organisation W3C définit un service Web comme ceci: "Un service Wev est un système
logiciel identifié par une URI dont les interfaces publiques et les “bindings” sont définis et décrits
dans un XML. Sa définition peut être découverte par d'autres systèmes logiciels. Ces systèmes
peuvent alors intéragir avec le service Web d'une manière prescrite par sa définition, en utilisant
des messages basés sur XML transportés par les protocoles Internets." L'implémentation d'un
service Web peut être fait dans n'importe quel language, et un service Web peut être également
accédé par différentes plateformes, puisque les messages sont basés sur XML. La plateforme J2EE
1.4 a spécifié la création de services Web pour les applications Web (Web Tier Based) et les
Modules EJB. L'EDI NetBeans 4.1 supporte la création de services Web selon le JSR 109 dans les
Applications J2EE, ainsi que la consommation de services Web publiés, dans les Applications
J2EE.
    Les services Web permettent aux Applications d'exposer des opérations Business aux autres
Applications, sans se préoccuper de leur implémentation. Cela est possible par l'utilisation des
standards suivants:
[lb]       XML, le Common markup language pour la communication – Les fournisseurs
           de services, qui rendent les services disponibles, et les utilisateurs de services, qui
           utilisent les services, communiquent entre eux par des Messages XML.
[lb]       SOAP, le Common message format pour l'échange d'information —Ces
           messages XML suivent un format bien défini. Simple Object Access Protocol
           (SOAP) fournit un format de message commun pour les services Web.
[lb]       WSDL, le Common service specification formats—En plus du SOAP et du
           XML, il devait y avoir un format commun que tous les fournisseurs de services


           Guide Pratique EDI NetBeans, Extension d'Applications J2EE avec des Services Web, 1
        pouvaient utiliser pour spécifier les détails de leurs services, comme le type du
        service, les paramètres du service, comment accéder au service, ... . Par exemple,
        Web services Description Language (WSDL) fournit des services Web avec des
        formats de spécification commun.




Consommation de services Web existant
    Pour qu'il soit utilisable par d'autres applications, un service Web doit publier un fichier
WSDL. Cela peut être fait via un répertoire UDDI, ou en exposant le fichier WSDL dans un
emplacement connu et identifé par une URL. C'est ce fichier WSDL qui est utilisé par l'application
pour construire les atrifacts nécessaires. L'assistant “Web service Client” de l'EDI NetBeans 4.1
automatise le processus de création et met à jour les fichiers de descripteur de déploiement avec les
éléments <service-ref> appropriés, le système de génération (pour générer les stubs client).
[lb]    Choisissez ce assistant appelé ose “Web service Client” dans la liste des éléments
        “new” depuis le menu contextuel d'un Projet Web application:




[lb]    Cet assistant vous permet de reprendre un fichier WSDL, soit depuis l'URL d'un
        service qui tourne, ou depuis votre répertoire local. Assurez-vous de définir un
        nom de paquetage pour les interfaces générés qui seront utilisés par le code de
        votre utilisateur pour accéder et intéragir avec ce service Web. Deux types de


        Guide Pratique EDI NetBeans, Extension d'Applications J2EE avec des Services Web, 2
        clients de service Web peuvent être générés:
[nl]    JSR-109 (services Web Enterprise). Étend la JSR-101 en définissant le
        packaging de services Web dans des modules J2EE standards, incluant un
        nouveau descripteur de déployement, et définissant des services Web qui sont
        implémentés en tant que session beans ou servlettes. C'est le moyen recommendé et
        portable (via la spécification J2EE 1.4).
[nl]    JSR-101 (JAX-RPC). Définit le mapping de WSDL en Java et vice versa. Il
        définit également une API cliente pour invoquer un service Web distant et un
        runtime environment sur le serveur pour accueillir un service Web.
[lb]    Cliquez sur le bouton Finish. Dans la fenêtre Project, vous devriez maintenant voir
        un nouveau noeud logique sous le noeud Web Services References. Explorez les
        enfants de ce noeud: pour chaque opération de service Web définie dans le fichier
        WSDL, l'EDI montre un noeud qui a ce nom d'opération, et un menu contextuel
        qui vous permet de tester cette opération directement dans l'EDI, sans écrire une
        seule ligne de code.




    L'entrée Web service Reference nécessaire dans le web.xml pour cette application Web a été
correctement mise à jour, ce qui vous permet d'utiliser ce service Web soit depuis une serlvette ou
depuis une classe utilitaire qui se situe dans votre application Web.


        Guide Pratique EDI NetBeans, Extension d'Applications J2EE avec des Services Web, 3
<service-ref>
    <service-ref-name>service/SforceService</service-ref-name>
    <service-interface>com.acme.SforceService</service-interface>
    <wsdl-file>WEB-INF/wsdl/enterprise.wsdl</wsdl-file>
    <jaxrpc-mapping-file>WEB-INF/wsdl/enterprise-mapping.xml</jaxrpc-
mapping-file>
    <port-component-ref>
      <service-endpoint-interface>com.acme.Soap</service-endpoint-
interface>
    </port-component-ref>
  </service-ref>




    Bien que, la plupart du temps, l'EDI va sélectionner correctement les options de l'outil
wscompile, vous pouvez contrôler pleinement l'outil wscompile utilisé pour la génération du clde
client depuis le fichier WSDL via la vue Proprerties du projet, dans le noeud “Web services->Web
services Client” . Par exemple, vous pouvez modifier les flags “Optimized”, “Verbose Operation”
ou “Debug”.




[lb]    Maintenant, vous désirez appeler une opération de ce service Web dans votre code
        Java. Sélectionnez l'emplacement dans votre code source Java où vous désirez
        insérer du code, et choisissez dans le menu contextuel l'entrée “Web services
        Client Resources---> Call Web service Operation”.




        Guide Pratique EDI NetBeans, Extension d'Applications J2EE avec des Services Web, 4
[lb]     Sélectionnez l'opération que vous désirez invoquer, et voyez le nouveau code que
         l'EDI à rajouté dans votre fichier Java:


         try {
               getNameFinderWebServiceRPCPort().nameFinderSearch(
               //TODO enter operation arguments */);
           } catch(java.rmi.RemoteException ex) {
               // TODO handle remote exception
           }




[lb]     ainsi que quelques méthodes privées fait le Web service Reference lookup depuis
         l'InitialContext, et l'accesseur au RCP Port pour l'opération sélectionnée:




       private unknown.NameFinderWebService getNameFinderWebService() {
         unknown.NameFinderWebService nameFinderWebService = null;
         try {
               javax.naming.InitialContext ic =
                     new javax.naming.InitialContext();
               nameFinderWebService = (unknown.NameFinderWebService)
               ic.lookup("java:comp/env/service/NameFinderWebService");
           } catch(javax.naming.NamingException ex) {
               // TODO handle JNDI naming exception


         Guide Pratique EDI NetBeans, Extension d'Applications J2EE avec des Services Web, 5
             }
             return nameFinderWebService;
       }

    private unknown.NameFinderWebServiceRPC
getNameFinderWebServiceRPCPort() {
        unknown.NameFinderWebServiceRPC nameFinderWebServiceRPCPort =
null;
      try {
            nameFinderWebServiceRPCPort =
                  getNameFinderWebService().
        getNameFinderWebServiceRPCPort();
        } catch(javax.xml.rpc.ServiceException ex) {
            // TODO handle service exception
        }
        return nameFinderWebServiceRPCPort;
    }

[lb]       Notez les commentaires // TODO dans le code rajouté: vous pouvez tracer
           facilement ce que vous, en tant que développeur, devez rajouter pour finaliser
           votre application.

           NetBeans IDE Tip
           Use the TODO manager Tool from the IDE Tools menu item to search
           for all the TODOs in your code. NetBeans J2EE wizards always add
           some TODO statements so that you can quickly find in the Java source
           code the areas you need, as a business logic developer to complete.



Implémentation d'un service web dans une application web
    Dans l'EDI, vous pouvez créer un service Web en implémentant un fichier WSDL existant, en
exposant du code existant, ou en créant “from scratch”. L'EDI génère les informations de
déployement dans les descripteurs de déployement, le code Java nécessaire qui décrit ce service
Web (l'implémentation par défaut, l'interface Service End Point également appelée “SEI”, et une
cible de compilation dans le script Ant.)
    Une façon simple de créer un service Web est de démarrer de rien.
[lb]       Dans un projet Web application, choisissez le modèle “New Web service...” .
           Spécifiez un nom, et un paquetage Java (évitez le paquetage par défaut, qui n'a
           pas de nom), et choisissez l'option “From scratch”, et cliquez sur le bouton Finish.




           Guide Pratique EDI NetBeans, Extension d'Applications J2EE avec des Services Web, 6
[lb]   Un nouveau service Web sans opérations, est rajouté à votre projet. Vous pouvez
       voir un noeud logique représentat ce nouveau composant dans le noeud Web
       Services dans la la fenêtre Projects. Un nouvelle entrée servlet est rajouté dans le
       web.xml ainsu qu'une entrée “webservice-description” dans les fichiers de
       descriptions webservices (similaires au fichier web.xml). Généralement, vous ne
       devrez pas du tout vous souciez de ces entrées qui sont automatiquement
       maintenues à jour par l'EDI lorsque cela est nécessaire.
[lb]   En tant que développeur, la vue logiquen sera celle que vous utiliserez le plus. Elle
       synthétise les détails d'implémentation d'un service Web (c'est-à-dire sa classe
       d'implémentation et son SEI (Service Endpoint Interface), et permet:
[nl]   d'explorer les opérations existantes,
[nl]   d'ajouter de nouvelles opérations au service Web,
[nl]   de l'enregistrer dans le registre qui vous permettra de le tester depuis l'EDI, et
[nl]   de configurer les possibles classes de Web services Message Handler qui
       pourraient y être associées.




       Guide Pratique EDI NetBeans, Extension d'Applications J2EE avec des Services Web, 7
[lb]   Choisissez le menu “Add Operation” (soit depuis le menu contextuel du noeud de
       ce service Web dans la fenêtre Project ou dans l'Éditeur de Source Java pour ce



       Guide Pratique EDI NetBeans, Extension d'Applications J2EE avec des Services Web, 8
       service Web). Vous pouvez configurer la liste des paramètres pour cette opération
       ainsi que le type de retour et les exceptions possibles:




[lb]   L'opération est rajoutée à la classe Java implémentant le service Web. L'EDI a
       automatiquement synchronisé l'Interface Service End Point (SEI), ce qui vous
       permet de ne vous concentrez que sur le développement du contenu de la méthode
       de l'opération.


       Guide Pratique EDI NetBeans, Extension d'Applications J2EE avec des Services Web, 9
[lb]    Maintenant que le service Web a été rajouté à votre application Web J2EE, vous
        n'avez plus qu'à appeler l'action “Build” ou “Deploy” pour lancer le processus de
        génération Ant qui va invoquer l'outil “wscompile” avec les paramètres corrects.
        L'application Web sera paquetagée en tant que fichier WAR et déployée sur le
        serveur défini pour ce projet.
init:
deps-module-jar:
deps-ear-jar:
deps-jar:
library-inclusion-in-archive:
library-inclusion-in-manifest:
Copying 2 files to C:\Documents and
Settings\ludo\WebApplication29\build\web
wscompile-init:
NewWebService_wscompile:
command line: wscompile C:\j2sdk1.4.2_06\jre\bin\java.exe -classpath
"C:\j2sdk1.4.2_06\lib\tools.jar;C:\Sun\AppServer81ur1\lib\j2ee.jar;C:\S
un\AppServer81ur1\lib\saaj-api.jar;C:\Sun\AppServer81ur1\lib\saaj-
impl.jar;C:\Sun\AppServer81ur1\lib\jaxrpc-
api.jar;C:\Sun\AppServer81ur1\lib\jaxrpc-impl.jar;C:\Documents and
Settings\ludo\WebApplication29\build\web\WEB-INF\classes"
com.sun.xml.rpc.tools.wscompile.Main -d "C:\Documents and
Settings\ludo\WebApplication29\build\generated\wssrc" -features
:documentliteral -gen:server -keep -mapping "C:\Documents and
Settings\ludo\WebApplication29\build\web\WEB-INF\wsdl\NewWebService-
mapping.xml" -nd "C:\Documents and
Settings\ludo\WebApplication29\build\web\WEB-INF\wsdl" -verbose
-Xprintstacktrace "C:\Documents and
Settings\ludo\WebApplication29\src\java\com\acme\NewWebService-
config.xml"
[creating model: NewWebService]
[creating service: NewWebService]
[creating port: com.acme.NewWebServiceSEI]
[creating operation: getValidation]
[CustomClassGenerator: generating JavaClass for: getValidation]
[CustomClassGenerator: generating JavaClass for: getValidationResponse]
[LiteralObjectSerializerGenerator: writing serializer/deserializer
for: getValidation]
[LiteralObjectSerializerGenerator: writing serializer/deserializer
for: getValidationResponse]
[SerializerRegistryGenerator: creating serializer registry:
com.acme.NewWebService_SerializerRegistry]
compile:
compile-jsps:
Building jar: C:\Documents and
Settings\ludo\WebApplication29\dist\WebApplication29.war
do-dist:
dist:
run-deploy:
Starting server Sun Java System Application Server 8
C:\Sun\AppServer81ur1\bin\asadmin.bat start-domain --domaindir
C:\Sun\AppServer81ur1\domains\ domain1

Distributing C:\Documents and
Settings\ludo\WebApplication29\dist\WebApplication29.war to
[localhost:4848_server]
deployment started : 0%
Deployment of application WebApplication29 completed successfully


        Guide Pratique EDI NetBeans, Extension d'Applications J2EE avec des Services Web, 10
Enable of WebApplication29in target server completed successfully
run-display-browser:
Browsing: http://localhost:8080/WebApplication29/
run:
BUILD SUCCESSFUL (total time: 12 seconds)



[lb]    Vous pouvez interroger l'application Web qui a été déployée et qui s'exécute pour
        avoir le fichier WSDL publié pour ce service Web. Dans notre cas,
        http://localhost:8080/WebApplication29/NewWebService?WSD
:




    Votre service Web est maintenant disponible à tout un chacun et publiée de façon à ce que
d'autres applications (des applications J2EE, des applications .Net ou même des applications J2ME
) peuvent inter-agir avec ces opérations.




Création de Services Web depuis un WSDL
    Vous pouvez également créer un service web depuis un document WSDL. Un scénario typique
de quand cela est nécessaire est lorsque des partenaires business formulent la façon dont ils vont
communiquer en services web. Le “contrat” devrait être le WSDL, dans lequel ils vont se mettre


       Guide Pratique EDI NetBeans, Extension d'Applications J2EE avec des Services Web, 11
d'accord sur les données et messages qu'ils vont s'échanger ainsi que comment ces messages seront
envoyés et reçus. Ce WSDL est alors utilisé pour implémenter le service web.
     Les éléments d'un document WSDL peut être catégorisé en parties abstraites et concrete. Les
éléments types, message, et portType définissent les données qui forment les messages envoyés et
reçus par les services web et leur clients, ainsi que les opérations qui vont utiliser ces messages.
Ces sections constituent la portion abstraite du WSDL. Les éléments binding et service décrivent
les protocoles et mécanismes de transport qui seront utilisés pour envoyer et recevoir des messages,
ainsi que les adresses réelles de l'extremité. Cela est considéré comme étant la portion concrète du
WSDL.
     Lors de la création d'un service Web depuis le WDSL dans NetBeans, un nouveau WSDL est
créé et packagé avec le service Web. La portion abstraite du WDSL original est copiée telle quelle
dans le nouveau. La portion concrète du WDSL original est normalisée pour le “binding” SOAP
over HTTP, une recherche dans le WSDL de la première occurrence de ce “binding” est effectuée.
Si elle est trouvée, elle est copiée dans le nouvel WSDL. Sinon, un “binding” SOAP/HTTP est créé
pour le premier portType définit dans le WSDL original. Donc, le service Web créé depuis un
WSDL dans NetBeans n'aura toujours exactement qu'un “binding” SOAP, et un port de service
correspondant à ce “binding”. L'élément de service qui est ajouté sera nommé selon le nom du
service Web spécifié dans l'assistant, remplacant l'élément du service dans le WSDL original.
     Pour créer un service Web depuis un WSDL, sélectionnez le bouton "From Local WSDL File"
ou "From WSDL URL" dans l'assistant, dépendant de l'emplacement du document WSDL.
Lorsque le service Web est créé, les classes pour l'interface Service End Point (SEI) et le bean
d'implémentation seront créées. Ces classes vont contenir toutes les opérations décrites dans le
WSDL. La classe bean d'implémentation sera affichée dans l'Éditeur de Source, et vous pourrez
alors introduire du code pour implémenter ces opérations. Si le WSDL décrit des opérations qui
utilisent des types complexes, les classes pour ces types (connus comme value types) sont
également générés pour que vous puissiez les utiliser dans votre code d'implémentation.
     Du fait que c'est le document WSDL qui gouverne l'interface au service Web, vous ne pouvez
pas ajouter de nouvelles opérations aux services Web qui sont créés depuis un WSDL, puisque ces
opérations ne seront pas reportées dans le WSDL.
     Notez que les WSDL qui important d'autres WSDL ne sont pas supportés par ces
fonctionnalités.


Types de Service Web
     Par défaut, NetBeans crée des services Web "document/literal". Cela réfere à la façon dont le
message SOAP est envoyé sur le réseau et est exprimé dans la partie “SOAP binding” du WSDL.
La nomenclature "document/literal" vient de la façon dont les messages SOAP sont décrit dans la
partie “SOAP binding” d'un document WSDL, nommé par ses attributs "style" et "use".
     L'attribut “style” referre au formatage du message SOAP. Cela referre basiquement à ce que le
corps du SOAP contiendra lorsqu'il sera envoyé sur le réseau.
     Il y a deux façons de formatter un message SOAP, rpc ou document. Lorsque le stype est
“rpc”, le contenu du corps SOAP est dicté par les règles de la spécification SOAP. C'est à dire que
le premier élément est nommé après l'opération, et ses enfants sont interprétés comme les
paramètres de la méthode appelée. L'extremité interpretera cela comme une représentation XML
d'un appel de méthode (c'est-à-dire un remote procedure call). De l'autre coté, si l'attribut style est
“document”, le corps du SOAP consiste en un XML arbitraire, qui n'est contraint par aucune règle
et peut contenir n'importe quoi sur lequel les deux parties (émetteur et récepteur) se sont entendues.
     L'attribut “use” décrit comment les données sont converties entre le XML et les objets, c'est à
dire comment ils seront sérialisé en XML.


       Guide Pratique EDI NetBeans, Extension d'Applications J2EE avec des Services Web, 12
     Si l'attribut “use” est “encoded”, cela signifie que les règles pour encoder/décoder les données
sont dictées par certaines règles d'encodage, dont la plus courante est l'encodage SOAP spécifié
dans la spécification SOAP. La Section 5 de la spécification SOAP définit comment les données
devraient être sérialisées en XML. Les services Web ou les clients voient ces données sous la forme
d'objets.
     Si l'attribut “use” est “literal”, les règles d'encodage des données sont dictées par un schéma
XML. Il n'y a pas de règles d'encodage et le service Web ou le client voit les données sous la forme
d'un XML. Ici, le développeur fait le travail de parsing du XML pour rechercher les données
nécessaire.
     Donc, “document/literal” est typiquement utilisé pour l'échange de documents business tandis
que “rpc/encoded” est typiquement utilisé pour invoquer des objets distants. Pour cette raison,
“document/literal” est préféré à “rpc/encoded” parce que dans “document/literal”, le développeur a
le contrôle totale sur les messages qui seront échangé. Le profile WS-I Basic, qui est une
spécification pour l'interopérabilité de services Web ne supporte pas les services Web de type
“rpc/encoded”.

Voici la liste des avantages des services Web “document/literal” sur “rpc/encoded”:
[nl]     Formattage des “Document/literal” est plus inter-opérable que “rpc/encoded” car
         le style de formatage rpc tend à lier les messages à la structure du langage de
         programmation.
[nl]      Les services Web “Document/literal” supporte mieux la montée en charge que
         “rpc/encoded” du faut de la surcharge de travail effectué dans le
         marshalling/unmarshalling des données rpc.
[nl]     Les services Web Document-centric se prêtent mieux à la validation des
         documents échangés. Cela est plus difficile à faire dans les services de style “rpc”.



Implémentation des Services Web dans un Module EJB
    Pour implémenter un service Web dans un module EJB, vous utiliserez un assistant de service
Web similaire à celui décrit pour l'application Web. La plupart des artifacts qui sont créés et des
entrées dans le descripteur de déployement qui sont rajoutés au module sont similaires à ceux dans
l'application Web. Vous suivrez la même procédure pour ajouter des gestionnaires de message
SOAP ainsi que pour les configurer dans les services Web.
    Une différence significative est l'implémentation du bean d'un service Web dans un module
EJB. Le JST 109 requiert que les services Web soient implémentés dans un module EJB en tant
que stateless Session beans. Donc, l'implémentation des opérations de service Web dans un module
EJB est contenu dans la classe Session bean. Le descripteur de déployement du module aura une
entrée stateless session bean, mais cela déclarera une endpoint interface au lieu d'un Local interface
ou Remote Interface. Aussi, un service Web dans un module EJB n'a pas de home interface.
    Une fois que vous avez créé un service web dans un module EJB, vous verrez le noeud logique
du service Web dans la fenêtre Projects. Le code source que vous allez manipuler est la classe
d'implémentation du stateless session bean. L'expérience du développeur est completement similaire
au développement d'un service Web avec une application Web.




       Guide Pratique EDI NetBeans, Extension d'Applications J2EE avec des Services Web, 13
    Dans le noeud Source Packages, vous pouvez voir la classe Bean du service ainsi que le
Service Endpoint Interface (SEI), et le fichier de configuration XML du service.




Test des services Web
     L'EDI NetBeans a un Environnement de Test intégré pour la publication de services Web, soit
créés par vous et déployé dans une application Web ou une application J2EE, ou publiée à
l'extérieur. Tout ce dont vous avez besoin est d'accéder au fichier WSDL pour ce service Web.
Ensuite, utilisez l'outil Web services Registry depuis la fenêtre Runtime de l'EDI, via le noeud
“Web services”:




[lb]    Utilisez le menu contextuel de ce noeud et choisissez l'action “Add Web service”,


       Guide Pratique EDI NetBeans, Extension d'Applications J2EE avec des Services Web, 14
pour activer l'assistant qui demandera après un fichier WSDL (que ce soit une
URL ou un fichier local). Une fois le bouton Add cliqué, les opérations du service
sont disponibles en tant que noeud dans le registre et vous pouvez utiliser pour
chacune des opérations l'entrée du menu contextuel “Test Operation”. Ce assistant
vous permet d'introduire tous les Paramètres d'Entrée pour cette opération.
Lorsque vous avez introduit les valeurs correctes pour les paramètres d'entrée,
sélectionnez le bouton “Submit”: l'opération du service Web est appelée, et les
paramètres output sont affichés dans l'aire Result.




Guide Pratique EDI NetBeans, Extension d'Applications J2EE avec des Services Web, 15
Ajout d'un Gestionnaire de Message à un service Web
NetBeans simplifie le développement de services Web J2EE et de clients parce qu'il détache les
développeurs de l'application des messages SOAP qui en résultent. Au lieu d'écrire du code
pour concevoir et parser des messages SOAP, les développeurs d'application implémentent
principalement les méthodes du service et les invoquent depuis des clients distants.
Cependant, il y a des moments où vous désirez ajouter des fonctionnalités aux applications de
services Web sans avoir à modifier le code du service web ou du client. Par exemple, vous
pourriez vouloir encrypter les appels distants au niveau des messages SOAP. Le gestionnaire de
message SOAP fournit le mécanisme pour rajouter une telle fonctionnalité sans devoir modifier
la logique métier. Les “Handlers” accomplissent cela en interceptant les messages SOAP qui
s'échangent entre le client et le service.
Un “handler” de message SOAP est une instance stateless qui accede aux messages SOAP
représentant des requêtes RPC, des réponses ou des fautes. Liés aux extremités du service, les
“handlers” vous permet de processer les messages SOAP et d'étendre la fonctionnalité du
service. Pour une extrêmité de service donné, un ou plusieurs “handlers” peut résider sur le
serveur et le client.
Une requête SOAP est “handled” comme ceci:



      Guide Pratique EDI NetBeans, Extension d'Applications J2EE avec des Services Web, 16
       •   Le “client handler” est invoquée avant que la requête SOAP ne soit envoyée vers le
           serveur.
       •   Le “service handler” est invoquée avant que la requête SOAP ne soit dispatchée vers le
           “service endpoint”.
Une réponse SOAP est traitée dans cet ordre:
       •   Le “service handler” est invoquée avant que la réponse SOAP ne soit renvoyée au
           client.
       •   Le “client handler” est invoquée avant que la réponse SOAP ne soit transformée en une
           méthode Java retournée et passée au programme client.
[lb]       Pour créer un Message Handler sur une application Web dans NetBeans,
           choisissez l'assistant appelé “Message Handler”:




[lb]       Le nouveau fichier Java contient le code central du “message handler”. Une
           méthode intéressante ici est handleRequest(MessageContext context) qui est
           appelée avant le message SOAP ne soit dispatchée au l'autre extrémité. La classe
           handler générée fournit une implémentation par défaut de cette méthode (comme
           exemple) qui affiche le contenu du corps SOAP plus quelques informations de
           date. Notez que le paramètre MessageContext fournit un contexte en obtenant le
           message SOAP transmis. Vous pouvez alors utilser l'API SAAJ (SOAP with
           Attachments API for Java) pour accéder et manipuler le message SOAP. Une
           autre méthode, handleResponse(MessageContext context) est appelée avant que le
           message de réponse ne soit renvoyé à l'appelant. Cette méthode, ainsi que


           Guide Pratique EDI NetBeans, Extension d'Applications J2EE avec des Services Web, 17
        handleFault ne fournit qu'une implémentation par défaut et c'est à vous, le
        développeur, d'en fournir une autre.


package com.acme;

import    javax.xml.rpc.handler.MessageContext;
import    javax.xml.rpc.handler.HandlerInfo;
import    javax.xml.rpc.handler.soap.SOAPMessageContext;
import    javax.xml.namespace.QName;
import    javax.xml.soap.SOAPElement;
import    javax.xml.soap.SOAPMessage;
import    javax.xml.soap.SOAPPart;
import    javax.xml.soap.SOAPEnvelope;
import    javax.xml.soap.SOAPHeader;
import    javax.xml.soap.SOAPBody;
import    java.util.Date;

public class NewMessageHandler extends
javax.xml.rpc.handler.GenericHandler {
    // TODO Change and enhance the handle methods to suit individual
needs.
    private QName[] headers;
    public void init(HandlerInfo config) {
        headers = config.getHeaders();
    }
    public javax.xml.namespace.QName[] getHeaders() {
        return headers;
    }
    // Currently prints out the contents of the SOAP body plus some
date information.
    public boolean handleRequest(MessageContext context) {
        try{
             SOAPMessageContext smc = (SOAPMessageContext) context;
             SOAPMessage msg = smc.getMessage();
             SOAPPart sp = msg.getSOAPPart();
             SOAPEnvelope se = sp.getEnvelope();
             SOAPHeader shd = se.getHeader();

                SOAPBody sb = se.getBody();
                java.util.Iterator childElems = sb.getChildElements();
                SOAPElement child;
                StringBuffer message = new StringBuffer();
                while (childElems.hasNext()) {
                    child = (SOAPElement) childElems.next();
                    message.append(new Date().toString() + "--");
                    formLogMessage(child, message);
                }

               System.out.println("Log message: " + message.toString());
           } catch(Exception e){
               e.printStackTrace();
           }
           return true;
    }

    public boolean handleResponse(MessageContext context) {
        return true;



        Guide Pratique EDI NetBeans, Extension d'Applications J2EE avec des Services Web, 18
       }

       public boolean handleFault(MessageContext context) {
           return true;
       }

       public void destroy() {
       }

    private void formLogMessage(SOAPElement child, StringBuffer
message) {
        message.append(child.getElementName().getLocalName());
        message.append(child.getValue() != null ? ":" +
child.getValue() + " " : " ");

              try{
                  java.util.Iterator childElems = child.getChildElements();
                  while (childElems.hasNext()) {
                      Object c = childElems.next();
                      if(c instanceof SOAPElement)
                          formLogMessage((SOAPElement)c, message);
                  }
              }catch(Exception e){
                  e.printStackTrace();
              }
       }
}

[lb]       Vous devez maintenant associer ce Message handler à votre service Web.
           Cliquez-droit sur le noeud du service Web dans la fenêtre Projects, et utilisez
           l'option “Configure Handlers”.




           Guide Pratique EDI NetBeans, Extension d'Applications J2EE avec des Services Web, 19
[lb]    Naviguez jusqu'à la classe du message handler nouvellement créés et sélectionnez-
        là. Cliquez sur OK. L'EDI a mis à jour automatiquement le fichier
        webservices.xml situé dans le répertoire WEB-INF de votre application Web en
        rajoutant l'élément <handler>. Voici un fichier webservices.xml mis à jour. Ne
        soyez pas effrayé par son compexité, l'EDI gère ce fichier pour vous. C'est
        pourquoi vous pouvez être très productifs en utilisant NetBeans en tant
        qu'environnement de développement...

<?xml version='1.0' encoding='UTF-8' ?>
<webservices xmlns='http://java.sun.com/xml/ns/j2ee' version='1.1'>
      <webservice-description>
            <webservice-description-name>NewWebService</webservice-
description-name>
            <wsdl-file>WEB-INF/wsdl/NewWebService.wsdl</wsdl-file>
            <jaxrpc-mapping-file>WEB-INF/wsdl/NewWebService-
mapping.xml</jaxrpc-mapping-file>
            <port-component xmlns:wsdl-port_ns='urn:NewWebService/wsdl'>
                  <port-component-name>NewWebService</port-component-
name>
                  <wsdl-port>wsdl-port_ns:NewWebServiceSEIPort</wsdl-
port>
                  <service-endpoint-
interface>com.acme.NewWebServiceSEI</service-endpoint-interface>
                  <service-impl-bean>
                        <servlet-link>WSServlet_NewWebService</servlet-
link>
                  </service-impl-bean>
                <handler>
                     <handler-name></handler-name>
                     <handler-
class>com.acme.NewMessageHandler</handler-class>
                </handler>
            </port-component>
      </webservice-description>
</webservices>

     Exécutez cette application Web. Pour voir les effets du message handler sur le service Web,
faites les étapes suivantes
[nl]    Exécutez l'application Web pour la redéployer
[nl]    Ajoutez le service Web au registre de l'EDI (cliquez-droit sur le noeud du Web
        service dans la fenêtre Projects window, et choisissez l'option “Add to Registry”)
[nl]    Allez dans la fenêtre Runtime de l'EDI, naviguez jsqu'au noeud Web services,
        sélectionnez votre service Web et choisissez une opération pour tester (option
        “Test” dans le menu contextuel du noeud d'une operation)




       Guide Pratique EDI NetBeans, Extension d'Applications J2EE avec des Services Web, 20
[nl]   Entrez les paramètres d'entrée et cliquez sur le bouton submit:




       Guide Pratique EDI NetBeans, Extension d'Applications J2EE avec des Services Web, 21
[nl]   Maintenant, si vous regardez dans le fichier log du Serveur d'Appliation
       (Sélectionnez le noeud Sun Java System Application Server dans le registre Server
       de la fenêtre Runtime, et choisissez l'option “View Server Log” dans son menu
       contextuel, vous verrez les traces du handler:


[#|2005-02-20T16:59:01.293-0800|DPL5306:Servlet Web service Endpoint
[NewWebService] listening at address
[http://129.145.133.80:8080/WebApplication29/NewWebService]|#]
[#|2005-02-20T16:59:02.084-0800|
javax.enterprise.system.tools.deployment|DPL5306:Servlet Web service
Endpoint [NewWebService] listening at address
[http://129.145.133.80:8080/WebApplication29/NewWebService]|#]
[#|2005-02-20T16:59:14.292-0800||javax.enterprise.system.stream.out|Log
message: Sun Feb 20 16:59:14 PST 2005--getValidation String_1:klkl |#]
[#|2005-02-20T17:05:40.297-0800|javax.enterprise.system.stream.out|
Log message: Sun Feb 20 17:05:40 PST 2005--getValidation
String_1:fdfd |#]




       Guide Pratique EDI NetBeans, Extension d'Applications J2EE avec des Services Web, 22

								
To top