Come faccio ad avere le credenziali di accesso passati al client del servizio JAX-WS con i suoi gruppi di impostazioni associati e legature in Rational / WebSphere utensili

Question

Sono in particolare utilizzando WebSphere Integration Developer V7, ma anche potrebbe utilizzare Rational Software Architect V 7.5.1 (come ho entrambi).

Contesto: Sto cercando di creare un client JAX-WS per chiamare nei servizi Human Task Manager e Business Flow Manager in WebSphere Process Server V7, che sono esposti tramite JAX-WS. Per impostazione predefinita hanno attaccato definisce la politica, e attacchi provider che specificare alcune impostazioni WS-Security (in quanto questi non sono definiti nel WSDL).

ho capito come farlo funzionare con un progetto dinamico Web. Sono stato in grado di generare il codice del client JAX-WS dal WSDL. Sono stato in grado di esportare i set di politiche e di provider e client binding da Process Server e importarli nel mio lavoro. Sono stato in grado di attaccare il gruppo di impostazioni e attacchi client per il servizio al cliente. Sono stato in grado di impostare una pagina e un servlet per invocare il mio servizio web (per testare il client). E sono stato in grado di impostare le impostazioni di protezione dei descrittori di deployment e WebSphere file / estensione vincolante per farlo funzionare.

Questo è tutto meraviglioso, ma in realtà noi non vogliamo un orecchio con una guerra solo per esporre il client di servizi Web per le altre applicazioni che stiamo scrivendo. Vogliamo generare un barattolo client di servizi web e del pacchetto con altre applicazioni.

Data questa linea di pensiero sono stato in grado di capire come utilizzare un progetto regolare Java nel mio IDE e generare il client del servizio Web in esso. Sono stato anche in grado di collegare il set e client binding dei dati al client.

Il mio problema è ora come ho richiamare questo? Ho creato un progetto web dinamico con la mia pagina e servlet come prima per testare il mio cliente. Ho creato il mio progetto client come una dipendenza libreria web in modo che abbia accesso al codice client. Posso anche impostare i descrittori di deployment come prima per forza di login e authenication. L'unico problema ora è che io non riesco a capire come passare le credenziali al mio servizio web ora che è nel proprio "jar". Prima ho avuto accesso a un menu per impostare il TokenGenerator e CallbackHandler. Ora, non ho accesso a tali menu come il client non è nel progetto dinamico web. Così ora ho una "disconnessione" e, naturalmente, non è riuscita quando si tenta di eseguire sul server.

Ci deve essere un modo per farlo. Dovrei essere in grado di generare un vaso cliente e passarlo cosa ha bisogno. Chiunque incontro prima?

Answer 1

Ok. Ho passato molto tempo la ricerca di questo, la lettura Redbook e developerWorks di articoli e battere la testa contro la mia tastiera e ho finalmente ottenuto qualche parte. Non tutto il tragitto, ma quasi. (Vorrei che alcune cose IBM era più facile da trovare ... ma si lavora con quello che si è data. E in tutta onestà, con quello che ho letto ha senso ed è abbastanza potente.)

In ogni caso, ecco il trucco per entrambe le attrezzature razionale e WebSphere: È necessario creare un progetto Java vuoto prima Questa è una delle chiavi per rendere un client di servizi web portatile

Così qui è finora:

1. Crea un progetto Java vuoto nel vostro IDE. Io preferisco usare la prospettiva Java EE sia in Rational Application Developer / Software Architect o in WebSphere Integration Developer.
2. Importa WSDL (s) e lo schema (s) in un altro progetto generico vuoto nel vostro IDE, NON nel progetto Java di recente creazione.
3. pulsante destro del mouse sul WSDL principale e scegliere di generare un client di servizi web.
4. Un'altra chiave qui : Assicurarsi che nella procedura guidata che appare di modificare il progetto client di essere il progetto Java creato nel passaggio uno. Per impostazione predefinita, la procedura guidata tenterà di indirizzare un nuovo o esistente progetto web dinamico, che non è quello che si vuole.
5. Assicurarsi di aver selezionato JAX-WS come l'implementazione. Assicuratevi di scegliere che si desidera che il cliente di essere "portatile" e assicurarsi che si dica la procedura guidata per includere il WSDL nel client Java del progetto.
6. In attesa di avere tutto in ordine (e il vostro server locale in esecuzione), razionale / WebSphere utensili dovrebbe generare il JAX-WS client di servizi web nel Progetto Java.

Meraviglioso! Grande! Ora avete un progetto Java (aka jar) che è possibile utilizzare per renderlo portabile. Ma come si fa a fare la lavorazione con utensili felice IBM e collegare le politiche di sicurezza per il cliente?

Ben prima, ho imparato che è davvero meglio per fissare le politiche di sicurezza nella console di gestione di WebSphere Application Server / Enterprise Service Bus / Process Server. Ci sono troppe cose da provare per conto con la sicurezza per cercare di manualmente il codice tutto, anche se IBM offre l'API per farlo. Fidati di me. E 'più facile definire la sicurezza sul server e poi basta assegnarlo al cliente.

In ogni caso .... al fine di consentire al cliente di essere visibile per la console di amministrazione per il fissaggio di gruppi di impostazioni e le associazioni client per la sicurezza JAX-WS, deve essere al "livello di rete" (per mancanza di una migliore termine) in modo che esso per vedere il vaso come un client web. Ciò significa che il fissaggio del vaso come un vaso J2EE utilità al progetto EAR non funzionerà. L'EAR non è "livello di web", ma è "livello di App". Quindi, per fare questo, è necessario associare il progetto Java con l'EAR nella schermata J2EE modulo Dipendenze, ma non come un vaso di utility. controlla invece la casella che dice "lib". Ciò significa che può essere visibile / montati nella directory lib di un progetto dinamico web / guerra (che si hanno anche a che fare). Sorprendentemente, la console di amministrazione sarà ora vedere il vostro vaso cliente come un vero e JAX-WS client di servizi web! E ora è possibile associare i gruppi delle impostazioni e le associazioni client ad esso, al fine di soddisfare le esigenze di sicurezza!

Questo potrebbe sembrare strano in un primo momento, ma lo fa sorta di senso. Dopo tutto si tratta di un Web servizio e si sta utilizzando protocolli web , così in qualche modo ha senso mettere il cliente nella " Livello web " della vostra applicazione.

  

Modifica Ho rovinato con le politiche di sicurezza e ho scoperto che    questo sviluppatore funziona articolo mi ha aiutato di più. Pay speciale   attenzione alla Listato 2 ClientTest.java . Purtroppo, si deve   codice di tutta la sicurezza nel client per farlo funzionare il più pulito.   E poi ecco un altro Gotcha. IBM permetterà di creare Nome utente   Gettoni da un client che viene eseguito al di fuori di WebSphere, ma non si   consentono di creare LTPA gettoni al di fuori di WebSphere. Quindi, per testare quelli   tipi di gettoni, si hanno per confezionare e distribuire il vostro cliente a livello locale per   provare tutto.