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.

[manblaizo]

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.

J'avoue que là, j'ai un peu de mal à te suivre. Je comprends bien que le wsdl soit défini indépendemment de tout framework d'implémentation, ce qui permet d'avoir un contrat défini à l'avance auquel tout le monde doit se conformer, le web service ainsi que ses clients. Ce qui veut dire que le web service doit être implémenté en respectant ce même wsdl qui sera donc spécifié au framework lors du déploiement du service.
Ce qu'il faudrait savoir c'est qu'à l'exécution, le framework de déploiement se base sur le wsdl pour faire la correspondance xml/java, faire correspondre par exemple une opération soap à un appel de méthode Java, un type xmlschema à un objet Java ..., et cela il le fait sur la base du wsdl publié (soit fourni au moment du déploiement, soit généré par lui-même dans le cas contraire). Donc si les clients sont créés à partir d'un contrat établi et que le web service génère un autre wsdl à l'exécution, il y a bien un risque d'incompatibilité entre le client et le service dans les messages soap échangés. L'objectif doit donc être d'implémenter également le web service en respectant le contrat, et le framework permet de publier un wsdl créé à l'avance. Ce qui garantit que, même en faisant une requête ?wsdl, les clients ne verront que le "bon" wsdl défini par contrat.
De plus, la spécification JAX-WS "impose" aux frameworks d'implémentation de publier le wsdl sous la forme ?wsdl, donc je ne vois pas trop pourquoi on devrait encore l'interdire aux clients.
Bref, tout ça pour dire qu'à mon avis le problème ne se pose pas, contract-first ou pas. Sauf si, ce qui est possible, je n'ai toujours pas bien compris le coeur de ton problème.

[dockurt2k]

Ce qu'il faudrait savoir c'est qu'à l'exécution, le framework de déploiement se base sur le wsdl pour faire la correspondance xml/java, faire correspondre par exemple une opération soap à un appel de méthode Java, un type xmlschema à un objet Java ..., et cela il le fait sur la base du wsdl publié (soit fourni au moment du déploiement, soit généré par lui-même dans le cas contraire). Donc si les clients sont créés à partir d'un contrat établi et que le web service génère un autre wsdl à l'exécution, il y a bien un risque d'incompatibilité entre le client et le service dans les messages soap échangés. L'objectif doit donc être d'implémenter également le web service en respectant le contrat, et le framework permet de publier un wsdl créé à l'avance.

Effectivement il y a un risque d'incompatibilité si le framework utilisé n'est pas capable de respecter ce qui est définit dans le WSDL (nom d'opérations qui change, SOAPAction qui change, ...) mais dans ce cas la :
La plupart des intéréts de faire du WSDL-first s'envole. En effet si ce qui est définit dans le WSDL n'est pas respecté dans l'implémentation (messages SOAP différent), pourquoi commencer par faire du WSDL. Pour cette raison, je ne recommenderai un tel framework à personne et certainement pas dans ma sociéte. Sauf si je voulais faire couler tout les efforts d'intégration de ma sociéte.

Le probléme pour moi est quand deux interfaces (WSDL) définit différement donnent exactement le même message SOAP. Dans ce cas je veut (et doit) maitriser quelle représentation WSDL est utilisé. Un exemple.

Si je veut inclure un soap header dans mes messages, je peut le définir en explicit ou implicit (IBM : http://www-128.ibm.com/developerwork...p-headers.html). Ces deux représentations ne sont pas uniformément accepté, en effet Metro (du moins JAX-WS RI 2.0) ne supporte pas les définitions implicit et les ignore complétement. Donc pour contrer cela il me faut définir tout mes soap headers en explicit. Admettons que je l'implémente en .Net, le ?WSDL servie par le framework lui définit les soap headers en implicit (ce qui est un postulat tout as fait valide, les messages SOAP échangées sont exactement les mêmes).
Maintenant, si je fournit le ?WSDL à JAX-WS RI, il ne générera aucun support pour les soap headers (car il ne supporte pas les définitions implicit)
Conclusion, le client JAX-WS doit absolument être génére à partir du WSDL manuel, le généré à partir du ?WSDL est un probléme d'interoperabilité avéré.

Pour être honnéte je n'ais aucun autre exemple en tête, ce probléme est suffisant pour moi, il me faut utiliser les WSDL manuels parcque deux WSDL différents peuvent donner le même message SOAP et je doit donc maitriser parfaitement les WSDLs consommés si je veut m'assurer d'une bonne interoperabilité.

De plus, la spécification JAX-WS "impose" aux frameworks d'implémentation de publier le wsdl sous la forme ?wsdl, donc je ne vois pas trop pourquoi on devrait encore l'interdire aux clients.

Merci de l'information, je l'ignorai complétement. En revanche cette spécification ne retire pas mon besoin, elle m'interdit juste de le satisfaire. Je préfére raisoner en terme de ce que je veut plutot que de ce que je peut. Si je ne peut vraiment pas, je me satisferai d'une solution par governance (interdire de consommer les ?wsdl)

Bref, tout ça pour dire qu'à mon avis le problème ne se pose pas, contract-first ou pas. Sauf si, ce qui est possible, je n'ai toujours pas bien compris le coeur de ton problème.

J'espére que mon exemple te permettra de comprendre mon point de vue. Bon sinon je pense qu'il vas falloir que je me pose des questions sur moi même

[manblaizo]

Bonjour,
Tu as regardé un peu le framework Spring Web Services ? http://static.springframework.org/spring-ws/site/.
Ce framework ne supporte que le contract-first comme approche de développement et le wsdl n'est pas exposé sous forme de requête ?wsdl. Cela devrait certainement répondre à tes besoins. Si tu connais déjà Spring, ça ne devrait pas poser trop de problème.

[saaalut]

Salut !
Ca devrait marcher en supprimant la librairie wsdl4j.jar