2009-10-15 5 views
2

Actuellement, chaque service Web pour notre application a un paramètre utilisateur qui est ajouté pour chaque méthode. Par exemple:Comment spécifier un paramètre dans le cadre de chaque appel de service Web?

@WebService 
public interface FooWebService { 
    @WebMethod 
    public Foo getFoo(@WebParam(name="alwaysHere",header=true,partName="alwaysHere") String user, @WebParam(name="fooId") Long fooId); 

@WebMethod 
    public Result deletetFoo(@WebParam(name="alwaysHere",header=true,partName="alwaysHere") String user, @WebParam(name="fooId") Long fooId); 

    // ... 
} 

Il peut y avoir vingt méthodes dans un service, chacune avec le premier paramètre en tant qu'utilisateur. Et il pourrait y avoir vingt services Web. Nous n'utilisons pas vraiment l'argument 'user' dans les implémentations - en fait, je ne sais pas pourquoi c'est là - mais je n'étais pas impliqué dans le design, et la personne qui l'a mis là avait un raison (j'espère).

De toute façon, j'essaie de redresser cette grosse boule de boue.

J'ai déjà parcouru un long chemin en enveloppant les services web par un proxy Spring, ce qui me permet de faire du traitement avant-après dans un intercepteur (avant qu'il y ait au moins 20 lignes de plaque de chaudière par méthode). Je me demande s'il existe une sorte d '"en-tête de message" que je peux appliquer à la méthode ou au paquet et auquel un type de gestionnaire ou quelque chose en dehors de chaque méthode de service Web peut avoir accès.

Merci à l'avance pour les conseils, LES

Répondre

0

Qui ou quoi s'attend le message user être lié à SOAP headers? Vos services Web sont-ils sécurisés? Est-ce une sorte d'en-tête d'authentification? Cela aurait pu être l'intention originale. En fait, quelqu'un devrait avoir la réponse à ces questions. Trouver qui. Et si vous découvrez que vous n'en aurez jamais besoin, arrêtez de le passer. Mais si vous en avez besoin, je pense qu'il est préférable de l'ajouter (même si vous ne l'utilisez pas pour l'instant) sauf si la modification du WSDL n'est pas un problème (surtout du côté client). PS: Je ne sais pas comment éviter d'ajouter un paramètre avec @WebParam(header=true) aux méthodes Java afin de générer un WSDL avec des opérations ayant un <soap:header> dans leur entrée. Autant dire que JAX-WS fonctionne à partir de Java.

+0

Je pense qu'il est censé être utilisé pour l'authentification à l'avenir, mais actuellement, personne ne fait rien avec elle. Cela m'agace que cela ne puisse apparemment pas se faire SÉCHER. :( – les2

+0

WS-Security avec le profil UsernameToken peut être le moyen DRY de le faire mais, eh bien, vous ne l'utilisez pas (et en fait, je ne sais pas comment il peut être utilisé avec une première approche Java) –

0

S'il n'y a aucune raison pour laquelle vous avez besoin de cette variable comme paramètre, vous pouvez demander à chacun de vos services d'étendre une super classe. Dans cette super classe, injectez le MessageContext, le ServletContext, le ServletRequest, le HttpHeaders ou tout ce qui est approprié (probablement MessageContext pour JAXWS) en utilisant l'annotation @Context ou l'annotation @Resource. Puis, fournissez quelques méthodes dans cette super classe pour extraire les informations de l'utilisateur de la requête.

+0

Le point est d'avoir un '' pour cette opération dans le WSDL généré.Héritage ne aide pas ici. –

0

Si l'authentification est ce que vous essayez d'accomplir, vous pouvez manipuler des contextes à partir de gestionnaires prédéfinis tels que le protocole ou les gestionnaires logiques. Par exemple. Implémentez l'interface SoapHanlder (qui est un gestionnaire de protocole), à ​​partir de là, ajoutez cette classe à la chaîne de gestionnaires de chaque service que vous offrez. Très simple et puissant. Ce monsieur a le meilleur tutorial là sur ce sujet.

Questions connexes