How do I get the login creditials passed to the JAX-WS service client with its associated policy sets and bindings in Rational/WebSphere tooling

Question

I am specifically using WebSphere Integration Developer V7, but I also could be using Rational Software Architect V 7.5.1 (as I have both).

Context: I am trying to create a JAX-WS client to call into the Human Task Manager and Business Flow Manager services in WebSphere Process Server V7, that are exposed via JAX-WS. By default they have attached Policy sets, and provider bindings that specify some WS-Security settings (as these are not defined in the WSDL).

I have figured out how to make it work using a Dynamic Web Project. I have been able to generate the JAX-WS client code from the WSDL. I have been able to export the policy sets and provider and client bindings from Process Server and import them into my workspace. I have been able to attach the policy set and client bindings to the client service. I have been able to set up a page and a servlet to invoke my web service (to test the client). And I have been able to set up the security settings in the deployment descriptors and websphere binding/extension files to get it work.

This is all wonderful, but in reality we don't want an ear with a war just to expose the web service client to our other applications we are writing. We want to generate a web service client jar and package it with other applications.

Given this line of thought I have been able to figure out how to use a regular Java Project in my IDE and generate the web service client into it. I have also been able to attach the policy set and client bindings to the client.

My problem is now how to I invoke this? I have created a dynamic web project with my page and servlet as before to test my client. I set up my client project as a web library dependency so it has access to the client code. I can even set up the deployment descriptors as before to force login and authenication. Only problem now is that I can't figure out how to pass the credentials to my web service now that it is in its own "jar". Before I had access to a menu to set up the TokenGenerator and CallbackHandler. Now, I don't have access to those menus as the client is not in the dynamic web project. So now I have a "disconnect" and it of course fails when trying to run it on the server.

There has to be a way to do this. I should be able to generate a client jar and pass it what it needs. Anyone encounter this before?

Answer 1

Ok. I've spent a long time researching this, reading redbooks and developerworks articles and pounding my head against my keyboard and I've finally gotten somewhere. Not all the way there, but almost. (Wish some IBM stuff was easier to find...but you work with what you are given. And in all fairness, with what I've read it makes sense and is pretty powerful.)

Anyway, here is the trick to both the Rational and WebSphere tooling: You have to create an empty Java Project first. This is one of the keys to making a portable web service client.

So here it is so far:

1. Create an empty Java Project in your IDE. I prefer to use the Java EE perspective in either Rational Application Developer/Software Architect or in WebSphere Integration Developer.
2. Import the WSDL(s) and schema(s) into another empty generic project in your IDE, NOT into the newly created Java Project.
3. Right-click on the main WSDL and choose to generate a web service client.
4. Another key here: Make sure that in the wizard that appears that you change the client project to be the Java Project you created in step one. By default the wizard will attempt to target a new or existing dynamic web project, which is NOT what you want.
5. Make sure that you select JAX-WS as your implementation. Make sure you pick that you want the client to be "portable" and make sure that you tell the wizard to include the WSDL in the Java Project client.
6. Pending you have everything in order (and your local server running), Rational/WebSphere tooling should now generate the JAX-WS web service client into the Java Project.

Wonderful! Great! Now you have a Java Project (aka jar) that you can use to make it portable. But how do you make the IBM tooling happy and attach security policies to the client?

Well first, i've learned that it really is best to attach the security policies in the administrative console of WebSphere Application Server/Enterprise Service Bus/Process Server. There are too many things to try to account for with security to try to manually code it all, even though IBM gives you the API's to do it. Trust me. It is easier to define the security on the server and then just assign it to the client.

Anyway....in order to allow the client to be visible to the Admin console for attaching policy sets and client bindings for JAX-WS security, it has to be at the "web level" (for lack of a better term) in order for it to see the jar as a web client. This means that attaching the jar as a J2EE Utility Jar to the EAR project won't work. The EAR is NOT "web level" but is "App level". So to do this, you need to associate the Java Project with the EAR in the J2EE Module Dependencies screen, but NOT as a Utility Jar. Instead check the box that says "lib". This means it can be visible/mounted into the lib directory of a dynamic web project/war (which you also have to do). Amazingly, the admin console will now see your client jar as a true JAX-WS web service client! And now you can associate policy sets and client bindings to it in order to meet your security needs!

This might appear weird at first but it does kind of make sense. After all you are dealing with a web service and you are using web protocols, so in some ways it makes sense to place the client in the "web level" of your application.

EDIT: I've messed with the security policies and I've found that this developer works article helped me the most. Pay special attention to the Listing 2 ClientTest.java. Sadly, you have to code all the security into your client to get it to work the cleanest. And then here's another gotcha. IBM will allow you to create Username Tokens from a client that runs outside of WebSphere, but they will NOT allow you to create LTPA tokens outside of WebSphere. So to test those kinds of tokens, you have to package and deploy your client locally to test it all.