IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Services Web Java Discussion :

Désactivé le ?WSDL


Sujet :

Services Web Java

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éclairé Avatar de dockurt2k
    Inscrit en
    Juillet 2006
    Messages
    91
    Détails du profil
    Informations personnelles :
    Âge : 40

    Informations forums :
    Inscription : Juillet 2006
    Messages : 91
    Par défaut Désactivé le ?WSDL
    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

  2. #2
    Membre Expert
    Avatar de alexismp
    Homme Profil pro
    Inscrit en
    Janvier 2005
    Messages
    1 503
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Janvier 2005
    Messages : 1 503
    Par défaut
    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....

  3. #3
    Membre éclairé Avatar de dockurt2k
    Inscrit en
    Juillet 2006
    Messages
    91
    Détails du profil
    Informations personnelles :
    Âge : 40

    Informations forums :
    Inscription : Juillet 2006
    Messages : 91
    Par défaut
    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.

  4. #4
    Membre Expert
    Avatar de alexismp
    Homme Profil pro
    Inscrit en
    Janvier 2005
    Messages
    1 503
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Janvier 2005
    Messages : 1 503
    Par défaut
    Citation Envoyé par 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.
    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.

    Citation Envoyé par dockurt2k
    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).

    Citation Envoyé par dockurt2k
    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.

  5. #5
    Membre chevronné
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    365
    Détails du profil
    Informations personnelles :
    Localisation : Maroc

    Informations forums :
    Inscription : Janvier 2006
    Messages : 365
    Par défaut
    Citation Envoyé par 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.
    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.

  6. #6
    Membre éclairé Avatar de dockurt2k
    Inscrit en
    Juillet 2006
    Messages
    91
    Détails du profil
    Informations personnelles :
    Âge : 40

    Informations forums :
    Inscription : Juillet 2006
    Messages : 91
    Par défaut
    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.

Discussions similaires

  1. Comment désactiver Ctrl+Alt+Del sous Windows XP
    Par ETOKA dans le forum API, COM et SDKs
    Réponses: 6
    Dernier message: 04/06/2003, 13h34
  2. Désactivation de la souris
    Par mika dans le forum API, COM et SDKs
    Réponses: 6
    Dernier message: 13/03/2003, 13h15
  3. Désactiver les touches F1, F2, F3, F4, F5 dans IE
    Par ZiZouJH dans le forum Flash
    Réponses: 7
    Dernier message: 17/02/2003, 09h59
  4. [Kylix] Kylix 3 & WSDL
    Par cpu dans le forum EDI
    Réponses: 2
    Dernier message: 10/10/2002, 12h39
  5. Réponses: 8
    Dernier message: 17/05/2002, 09h08

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo