I've been having trouble understanding why the security tab of my web service client's properties window says "Project not supported". Eventually I figured out that Java 1.4 web projects let you configure security for your web service client, but not Java 1.5 web projects. I spent all kinds of time trying to configure a 1.4 web project properly, then manually copy settings from the deployment descriptor over to my Java 1.5 project with no success. Part of the problem is that Java 1.4 uses the JAX-RPC library for web services, and Java 1.5 uses JAX-WS. You can't use configs for a JAX-RPC client to make a JAX-WS client work.

I posted messages on the nbusers mailing list and those who replied told me that security features have not yet been added for Java 1.5 projects! I could not believe it so I bought a NetBeans developer support contract. $250 for 12 months, unlimited issues. First thing this morning a Sun employee responded suggesting that I try what I had already tried, or look into something new called Tango and Web Services Interoperability Technology (WSIT). I briefly looked into it. It is a library built on top of JAX-WS to provide extra features such as WS-Reliability, WS-Security, some special things for .NET web services, etc... I wasn't ready to switch over to a new beta web service client technology just yet.

Near the end of the day a Sun employee found the answer for me. In Java 5 deployment descriptors aren't used as much, and meta data is described by annotations in your code. Because my deployment descriptor mentions nothing about the web service client, the IDE does not display the settings on the security tab. To get it to work for my Java 5 project, I had to let it know that I'm using the web service client by using the @WebServiceRef annotation anywhere in my code. In the project pane, expand the web service client down to the method you want to call. Drag/drop the method into a code window. It will create some sample code to execute the method. If you drag/drop it into a servlet class, it will also add the @WebServiceRef annotation for you at the top of the class. Copy/paste that reference into whichever class uses the web service client. Once I was done that, I deleted the servlet because I'm using JSF.

Tomorrow I'll look into finalizing the web service security settings, and will figure out how to make my program discover the location of the web service. My program runs on a different computer than the web service. I don't want to hard code the URL into my program or deployment descriptor during development, then change it again when deployed. I believe the proper way to do this is to use a registry such as UDDI or ebXML. There's an ebXML registry available for Sun Application Server 9 that I might look into. Someone else told me that the Liberty standard also supports discovery. I think I'll need Sun Access Manager to help with some security things too. I don't know much about it yet. Luckily I have a Sun Federation Architect on my Skype contact list. He works on the Access Manager product and OpenSSO, the source base. Federation is a term used when talking about multiple systems from different companies that all use the same identity server for authentication to enable single signon. There's a whole bunch of standards that make this happen, such as Liberty.