Comment obtenir les identifiants de connexion transmis au client de service JAX-WS avec ses jeux de règles et liaisons associés dans l'outil Rational/WebSphere

Question

J'utilise spécifiquement WebSphere Integration Developer V7, mais je pourrais également utiliser Rational Software Architect V 7.5 .1 (comme j'ai les deux).

Contexte: Je tente de créer un client JAX-WS pour appeler les services Human Task Manager et Business Flow Manager dans WebSphere Process Server V7, qui sont exposés via JAX-WS. Par défaut, ils ont des ensembles de règles attachés et des liaisons de fournisseur qui spécifient certains paramètres WS-Security (car ils ne sont pas définis dans le WSDL).

J'ai trouvé comment le faire fonctionner en utilisant un projet Web dynamique. J'ai été capable de générer le code client JAX-WS à partir du WSDL. J'ai pu exporter les ensembles de règles et les liaisons de fournisseur et de client à partir de Process Server et les importer dans mon espace de travail. J'ai été en mesure d'attacher le jeu de règles et les liaisons client au service client. J'ai pu mettre en place une page et une servlet pour appeler mon service web (pour tester le client). Et j'ai pu configurer les paramètres de sécurité dans les descripteurs de déploiement et les fichiers de liaison/extension websphere pour que cela fonctionne.

Tout cela est merveilleux, mais en réalité, nous ne voulons pas une oreille avec une guerre juste pour exposer le client de service Web à nos autres applications que nous écrivons. Nous voulons générer un fichier client de service Web et l'empaqueter avec d'autres applications. Dans cette optique, j'ai été capable de comprendre comment utiliser un projet Java normal dans mon EDI et y générer le client du service Web. J'ai également été en mesure d'attacher le jeu de règles et les liaisons client au client.

Mon problème est maintenant comment invoquer ceci? J'ai créé un projet web dynamique avec ma page et ma servlet comme auparavant pour tester mon client. J'ai configuré mon projet client en tant que dépendance de bibliothèque Web afin qu'il ait accès au code client. Je peux même configurer les descripteurs de déploiement comme auparavant pour forcer la connexion et l'authentification. Le seul problème est maintenant que je ne peux pas comprendre comment passer les informations d'identification à mon service Web maintenant qu'il est dans son propre "pot". Avant j'avais accès à un menu pour configurer le TokenGenerator et CallbackHandler. Maintenant, je n'ai pas accès à ces menus car le client n'est pas dans le projet web dynamique. Alors maintenant j'ai un "déconnecter" et il échoue bien sûr en essayant de l'exécuter sur le serveur.

Il doit y avoir un moyen de le faire. Je devrais être capable de générer un pot de client et le passer ce dont il a besoin. Quelqu'un a-t-il déjà rencontré ça?

Answer 1

Ok. J'ai passé beaucoup de temps à faire des recherches sur ce sujet, en lisant des redbooks et des articles de developerworks et en me cognant la tête contre mon clavier, et finalement je me suis rendu quelque part. Pas tout le chemin, mais presque. (Je souhaite que certaines choses d'IBM soient plus faciles à trouver ... mais vous travaillez avec ce qui vous a été donné.) En toute équité, avec ce que j'ai lu, cela a du sens et est assez puissant. Astuce pour les outils Rational et WebSphere: Vous devez d'abord créer un projet Java vide. Ceci est l'une des clés pour faire un client de service Web portable.

voici donc jusqu'à présent:

1. Créer un vide Java dans votre projet IDE. Je préfère utiliser la perspective Java EE dans Rational Application Developer/Software Architect ou dans WebSphere Integration Developer.
2. Importez les WSDL et les schémas dans un autre projet générique vide dans votre IDE, PAS dans le nouveau projet Java.
3. Cliquez avec le bouton droit sur le fichier WSDL principal et choisissez de générer un client de service Web.
4. Autre clé ici: Assurez-vous que dans l'assistant qui s'affiche, vous modifiez le projet client pour qu'il corresponde au projet Java que vous avez créé à la première étape. Par défaut, l'assistant va tenter de cibler un projet web dynamique nouveau ou existant, ce qui n'est PAS ce que vous voulez.
5. Assurez-vous de sélectionner JAX-WS comme implémentation. Assurez-vous que vous choisissez que vous voulez que le client soit "portable" et assurez-vous de dire à l'assistant d'inclure le WSDL dans le client Java Project.
6. En attendant que tout soit en ordre (et que votre serveur local soit en cours d'exécution), les outils Rational/WebSphere doivent désormais générer le client de service Web JAX-WS dans le projet Java.

Beaucoup d'amour! Génial! Maintenant, vous avez un projet Java (aka jar) que vous pouvez utiliser pour le rendre portable. Mais comment rendre les outils d'IBM heureux et attacher des politiques de sécurité au client? Eh bien d'abord, j'ai appris qu'il est préférable d'attacher les politiques de sécurité dans la console d'administration de WebSphere Application Server/Enterprise Service Bus/Process Server. Il y a trop de choses à essayer de rendre compte avec la sécurité pour essayer de tout coder manuellement, même si IBM vous donne l'API pour le faire. Croyez-moi. Il est plus facile de définir la sécurité sur le serveur, puis de l'assigner au client. Quoi qu'il en soit .... pour permettre au client d'être visible à la console d'administration pour attacher des jeux de règles et des liaisons client pour la sécurité JAX-WS, il doit être au niveau "web" (à défaut d'un meilleur terme) afin qu'il voit le pot en tant que client Web. Cela signifie que l'association du jar en tant que Jar J2EE Utility au projet EAR ne fonctionnera pas. L'EAR n'est PAS un "niveau Web" mais un "niveau d'application". Pour ce faire, vous devez associer le projet Java à l'EAR dans l'écran Dépendances du module J2EE, mais PAS en tant que pot utilitaire. Au lieu de cela, cochez la case "lib". Cela signifie qu'il peut être visible/monté dans le répertoire lib d'un projet/guerre web dynamique (ce que vous devez également faire). Étonnamment, la console d'administration verra maintenant votre client jar comme un vrai client de service Web JAX-WS! Et maintenant vous pouvez y associer des jeux de règles et des liaisons client afin de répondre à vos besoins de sécurité!

Cela peut sembler bizarre au début, mais cela a un sens. Après tout, vous avez un service web et vous utilisez protocoles Web, donc à certains égards, il est logique de placer le client dans le "niveau Web" de votre application.

EDIT: J'ai foiré avec les politiques de sécurité et je l'ai trouvé que this developer works article m'a aidé le plus. Payer spécial attention à la Liste 2 ClientTest.java. Malheureusement, vous devez coder toute la sécurité dans votre client pour le faire fonctionner le plus propre. Et puis voici un autre gotcha. IBM vous permettra de créer le nom d'utilisateur jetons d'un client qui s'exécute en dehors de WebSphere, mais ils ne vous permettront pas de créer des jetons LTPA en dehors de WebSphere. Donc, pour tester ces types de jetons , vous devez package et déployer votre client localement à tester tout cela.