Discussion :

[ludosoft]

Bonjour à tous,

Je me pose une question d'ordre pratique.

J'utilise Netbeans pour consommer un WS (SOAP). Je fais donc "New>Web Service client", je donne l'URL du WSDL, ça génère du code et je peux appeler le WS. Jusque là tout va bien.

Côté environnement, l'application fournissant le WS est déployée sur un serveur de dev et sur un autre pour la prod (rien de bien extraordinaire...).
Du coup, pour appeler un WS, l'URL du WSDL (et du "point d'entrée" du WS) va être fonction de l'environnement cible. Par ex "http://192.168.1.12/?wsdl" pour le dev et "http://www.bidule.com/?wsdl" la prod.

Ma question est :
Dans l'application consommant le WS, comment gérer facilement les différentes configurations (dev et prod) de sorte que je ne sois pas obligé de demander à NetBeans de régénérer le code qui va bien avec l'URL du bon WSDL à chaque mise en prod ?
Je suppose que ce doit être automatisable avec Ant ou du Maven mais je cherche une éventuelle autre solution...

Merci par avance pour vos réponses.

[rockley]

Met des conditions sur tes endPoint.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
   private static Send_ResponseType (....Send_RequestType send_RequestElement) throws RemoteException {
    	_Proxy p = new _Proxy();
        if(...){
		p.setEndpoint("http://192.168.1.12/?wsdl");
         }else{
                p.setEndpoint("http://www.bidule.com/?wsdl");
         }
         return p...(...);
    }

[Laurent.B]

Bonjour,

Si tu cherches une solution dynamique, ou en tous les cas qui n'oblige pas à recompiler ou rebuilder le client, je pense que le mieux est de regarder du côté de cette constante BindingProvider.ENDPOINT_ADDRESS_PROPERTY, qui est l'identifiant de l'URL de la map au sein du service.
Ensuite, avec un système à base de fichier .properties par exemple, tu peux surcharger l'URL.

[rockley]

Tu te bases juste sur tes environnements.
Si t'a ton environnement de dev et de prod

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
   private static Send_ResponseType (....Send_RequestType send_RequestElement) throws RemoteException {
    	_Proxy p = new _Proxy();
        if(DEV){
		p.setEndpoint("http://192.168.1.12/?wsdl");
         }else if (PROD){
                p.setEndpoint("http://www.bidule.com/?wsdl");
         }
         return p...(...);
    }

[Laurent.B]

Tu te bases juste sur tes environnements.
Si t'a ton environnement de dev et de prod

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
   private static Send_ResponseType (....Send_RequestType send_RequestElement) throws RemoteException {
        _Proxy p = new _Proxy();
        if(DEV){
        p.setEndpoint("http://192.168.1.12/?wsdl");
         }else if (PROD){
                p.setEndpoint("http://www.bidule.com/?wsdl");
         }
         return p...(...);
    }

Désolé de te le dire mais ce n'est pas très abouti comme approche...

Premièrement, il vaut toujours mieux externaliser ce qui est censé changer en fonction du contexte d'exécution.
Deuxièmement, tu fais quoi si, à un moment donné, tu te retrouves à devoir faire avec plus d'environnements que les 2 que tu avais prévu au départ ? Du style : TEST, DEBUG, INTEGRATION, RECETTE... ? Ben t'es obligé de modifier et recompiler...
Troisièmement, si jamais t'es obligé de changer l'URL d'une des machines pour X raison, tu fais quoi ? Ben pareil, modification du code et recompilation.

Voilà, donc pour aller vite au départ, ton approche peut dépanner 5 minutes mais laisser ça en production faut simplement oublier ! Mais on sait bien que ce n'est pas rare malheureusement. Faut juste avoir conscience du piège qu'on se tend

[ludosoft]

Bonjour,

Merci pour vos réponses.
Je pencherais plus pour un mode de fonctionnement "par configuration" qui me semble moins contraignant à l'utilisation et moins intrusif dans le code.

Pour vous en dire plus sur le contexte, j'utilise en fait Netbeans. Je clique-droit sur le projet puis "New > Web service client", je rentre l'URL d'un WSDL et ça mouline tout seul pour générer un gros paquet de code (plein de classes dans le dossier "build" + des fichiers dans "META-INF"). Ce que je remarque c'est que l'URL du WSDL se retrouve un peut partout, à la fois dans les annotation du code généré et dans les fichiers présents dans "META-INF".

Alors du coup j'ai du mal à percevoir comment je peux "sauter" d'un environnement à l'autre simplement, sans devoir recompiler.

EDIT :
Je pense que je tiens un début de réponse. Au niveau de l'appel au constructeur "new org.tempuri.WebService()", je viens de voir que l'on pouvait y passer des paramètres, notamment l'URL du WSDL

Ex:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public class TestWS {
 
    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) throws Exception {
        System.out.println(helloWorld(10, "Jojo"));
    }
 
    private static Truc helloWorld(long id, String name) throws Exception {
 
        //Avant
        org.tempuri.WebService service = new org.tempuri.WebService();
        //Après
        org.tempuri.WebService service = new org.tempuri.WebService(new URL("http://localhost:3918/WebSite2/WebService.asmx"));
 
        org.tempuri.WebServiceSoap port = service.getWebServiceSoap();
        return port.helloWorld(id, name);
    }
}

Je peux donc, par de biais là, injecter une autre URL en fonction d'un fichier de configuration.

[rockley]

Je ne me suis jamais posé autant de question que toi. Je sais juste qu'en changeant le EndPoint, ça marche. T'as beau avoir l'URL qui se retrouve un peu partout dans tes classes générées, il te suffit de changer ton endpoint pour que ça marche (si c'est le même Web Service pour les 2 URL).

[ludosoft]

Je ne me suis jamais posé autant de question que toi. Je sais juste qu'en changeant le EndPoint, ça marche. T'as beau avoir l'URL qui se retrouve un peu partout dans tes classes générées, il te suffit de changer ton endpoint pour que ça marche (si c'est le même Web Service pour les 2 URL).

Oui, je me prends sans doute un peut trop la tête. En attendant je ne vois pas sur quel objet faire un "setEndpoint". Je rappelle que j'ai utilisé la moulinette automatique de Netbeans qui se base sur JAX-WS pour générer le code. Et dans la masse de code généré (dont une grosse partie est re-généré à chaque compilation), je ne vois que le morceau que j'ai mis en exemple pour intervenir sur l'adresse du WSDL.

Bref, j'ai malgré tout une solution à mon problème, même si elle n'est pas optimale.
Avec votre accord, je pense clôturer le topic

[Laurent.B]

A mon avis, si le constructeur de ton WebService te permet de le faire c'est que c'est dédié à cela... (mais n'étant très aguerri sur le sujet, je ne peux l'affirmer). Qu'est-ce qui t'embête dans cette approche ?

Sinon, j'ai trouvé ça http://wiki.netbeans.org/FaqWebServiceLocation chez NetBeans. C'est à base de la constante dont je parlais.

[rockley]

Avant tout il faut que tu sache que tu utilises le meilleur IDE pour faire un web service. Moi je boss sur eclipse mais crée mes WS sur netBeans.
Pourquoi ? Car tout est automatique. Avec un glissé déposé tu peux générer tout ce dont tu as besoin. Regarde cette vidéo.

http://dlc.sun.com.edgesuite.net/jav...ent-glassfish/

à environ 3min30 tu peux voir comment il crée simplement une méthode pour faire appelle au WS.
Vers 4 min tu peux voire qu'il y a un variable "port" qui est crée.
C'est sur le port que tu fait un setEndpoint.

[ludosoft]

Merci pour les liens !
Effectivement, Netbeans simplifie bien les chose et c'est pour cela que mon choix s'est porté dessus. Par contre je ne connais pas assez Eclipse pour le juger sur le plan des WS. Je ne vais donc pas me risquer à faire des comparaisons "trolifères"

Du coup pour conclure, je pense que je vais rester sur la solution qui me semble la mieux coller à "l'allure" qu'a le code généré par NB lors du glissé-déposé.
A savoir, injecter l'URL du WSDL au niveau de l'instanciation de la classe "org.tempuri.WebService" de mon exemple.

Merci pour vos réponses et vos éclaircissement