Table des MatièresEtendre les Applications J2EE avec des Services Web ................................................................ 1

Qu'est ce qu'un service Web..................................................................................................... 1Consommation de services Web existant................................................................................. 2Implémentation d'un service web dans une application web .................................................... 6

Création de Services Web depuis un WSDL...................................................................... 11Types de Service Web....................................................................................................... 12

Implémentation des Services Web dans un Module EJB........................................................ 13Test des services Web............................................................................................................ 14Ajout 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 WebL'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 existantPour 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 TipUse 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\webwscompile-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:\Sun\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.wardo-dist:dist:run-deploy:Starting server Sun Java System Application Server 8C:\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 successfullyrun-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 WSDLVous 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 WebPar 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 EJBPour 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 WebL'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 WebNetBeans 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