Discussion :

[dockurt2k]

Bonjour

Grand néophyte des frameworks Web Services Java, je désirerais désactiver le querying des ?WSDL sur les Web Services développé avec Axis et Axis2 (je ne permet que la consomation des WSDLs manuels).

Quelqu'un est il au courant de la démarche à suivre ?

Merci d'avance

[alexismp]

Pourquoi l'import manuel uniquement?
Avec des services non-triviaux (WS-ReliableMessaging, ...), le WDSL doit être disponible au runtime, je ne pense pas qu'il soit prévu véritablement.
Il doit probablement y avoir des hacks au niveau du serveur web pour filtrer sur la base de l'URL....

[dockurt2k]

Je pense qu'il y a un petit problème de compréhension. Le WSDL doit définitivement être utilisé pour la création des clients. Mais surtout pas le WSDL générer automatiquement par le framework.
La raison en est très simple, nous développons en contract-first pour diverses raisons (la pérennité des Web Services notamment), ainsi le seul contrat liant consommateur et fournisseur est le contrat statique désigné manuellement, faute de quoi les avantages de développer en contract-first fondent comment neige au soleil.
Bref il existe deux manières d’interdire la création de consommateur basé sur le contrat dynamique ( ?WSDL), l’interdire par politique d’entreprise ou l’interdire techniquement.
Dans la mesure du possible nous préfèrons faire les deux. Interdire la mise à disposition du contrat dynamique en .Net est réalisable. Je doit maintenant déterminer comment le faire dans divers framework Java.

Hors-sujet : je travaille aussi sur la sélection de framework Java pour l’implémentation de Web Services, à la vue de ton blog je pense que tu sera intéressé de savoir que nous penchons en faveur de Metro pour le moment.

[alexismp]

Je pense qu'il y a un petit problème de compréhension. Le WSDL doit définitivement être utilisé pour la création des clients. Mais surtout pas le WSDL générer automatiquement par le framework.

La raison en est très simple, nous développons en contract-first pour diverses raisons (la pérennité des Web Services notamment), ainsi le seul contrat liant consommateur et fournisseur est le contrat statique désigné manuellement, faute de quoi les avantages de développer en contract-first fondent comment neige au soleil.

Il faut au moins changer le :

Code :

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

<soap:address location>

mais même sans ça, les outils sont susceptibles de rajouter des infos de qualité de services (sécurité, optimisation, fiabilité, ...). Je pense qu'en Contract-First, l'objectif est de définir principalement les types, les messages et les actions. Les outils embarquent le WSDL à partir duquel l'implémentation a été créée dans l'application.

Bref il existe deux manières d’interdire la création de consommateur basé sur le contrat dynamique ( ?WSDL), l’interdire par politique d’entreprise ou l’interdire techniquement.

En quoi l'accès au WSDL est dynamique? Si tu souhaites aller au delà du Basic Profile, tu risques rapidement d'avoir besoin d'un accès à cette URL pour des standards comme WS-MetadataExchange, WS-ReliableMessaging, ... à l'exécution (même si le client a été créer statiquement avant).

Dans la mesure du possible nous préfèrons faire les deux. Interdire la mise à disposition du contrat dynamique en .Net est réalisable. Je doit maintenant déterminer comment le faire dans divers framework Java.

C'est certainement dépendant du framework utilisé. Pose la question ici pour metro@glassfish.

[manblaizo]

Je pense qu'il y a un petit problème de compréhension. Le WSDL doit définitivement être utilisé pour la création des clients. Mais surtout pas le WSDL générer automatiquement par le framework.
La raison en est très simple, nous développons en contract-first pour diverses raisons (la pérennité des Web Services notamment), ainsi le seul contrat liant consommateur et fournisseur est le contrat statique désigné manuellement, faute de quoi les avantages de développer en contract-first fondent comment neige au soleil.
Bref il existe deux manières d’interdire la création de consommateur basé sur le contrat dynamique ( ?WSDL), l’interdire par politique d’entreprise ou l’interdire techniquement.
Dans la mesure du possible nous préfèrons faire les deux. Interdire la mise à disposition du contrat dynamique en .Net est réalisable. Je doit maintenant déterminer comment le faire dans divers framework Java.

Salut,
C'est une très bonne chose de faire du "Contract-First", et si je puis me permettre, je crois que vous avez plutot besoin d'inverser votre approche du problème. Je m'explique : une fois que le WSDL a été créé "à la main", le web service doit être implémenté pour respecter ce contrat, et lors du déploiement vous spécifier ce WSDL au framework d'implémentation de web services, qui alors n'aura plus à en générer un autre (généralement peu compatible avec les types xml schema définis en contract-first). Et donc, quand les clients font une requête ?wsdl, ils obtiennent le wsdl indiqué au framework lors du déploiement, et non pas un wsdl généré à la volée.
De plus, je pense que ce ne serait peut-être pas une bonne chose d'interdire les requêtes ?wsdl vu que même si les clients sont créés à partir d'un autre fichier wsdl, lors de la communication entre client et serveur c'est bien le wsdl déployé par le framework qui est utilisé pour les mapping wsdl/java, et donc risque potentiel d'incompatibilité, je crois.
Donc pour résumer : une fois le contrat établi, le service et le client doivent être créés pour respecter le même wsdl. Plus besoin d'interdiction de n'importe quelle forme.
Voilà, j'espère que ça aide.

[dockurt2k]

Alexismp :

Il faut au moins changer le : port/soap:address@location

Effectivement et cela est déja couvert par governance.

mais même sans ça, les outils sont susceptibles de rajouter des infos de qualité de services (sécurité, optimisation, fiabilité, ...). Je pense qu'en Contract-First, l'objectif est de définir principalement les types, les messages et les actions. Les outils embarquent le WSDL à partir duquel l'implémentation a été créée dans l'application.
En quoi l'accès au WSDL est dynamique? Si tu souhaites aller au delà du Basic Profile, tu risques rapidement d'avoir besoin d'un accès à cette URL pour des standards comme WS-MetadataExchange, WS-ReliableMessaging, ... à l'exécution (même si le client a été créer statiquement avant).

Trés bonne remarque. Simplement notre objectif étant une interoperabilité compléte Out-Of-The-Box nous ne pouvons nous permettre l'utilisation de WS-*... pour le moment (WSIT/Tango et WCF vont peut être changer la donne prochainement).

manblaizo :

De plus, je pense que ce ne serait peut-être pas une bonne chose d'interdire les requêtes ?wsdl vu que même si les clients sont créés à partir d'un autre fichier wsdl, lors de la communication entre client et serveur c'est bien le wsdl déployé par le framework qui est utilisé pour les mapping wsdl/java, et donc risque potentiel d'incompatibilité, je crois.

En faisant cela le contrat originel perdrait toute valeur et ne serait plus le contract du Web Service. Il est vrai que le garder a tout prix n'est pas un objectif en soi. En revanche garder un contract définit de manière complétement indépendante à tout framework en est un. Ce besoin est notamment apparue avec le framework .Net dont le contract exposé n'est pas complétement fidéle au contract originel. C'est un probléme certain niveau interopérabilité.
Avec cette méthode nous imposons aux fournisseurs et aux consommateurs de Web Services un format de WSDL sur lequel nous avons une parfaite maitrise. Autoriser la consommation à partir de ?WSDL revient à n'imposer notre format qu'aux fournisseurs.


Bref le besoin de désactivation n'est pas un impératif (déja couvert par gouvernance) mais plutot une assurance.