WS-JP: Revolting JP in WS

Java is a great tool as a language but sucks at some points. Why can't I use two different keystore files in my application? One for my embedded Axis/Jetty server and one for my Axis WS client. I know, when it comes to connection any fools out there whom prefer instant production would suggest using plain HTTP connection. Mind you! I will never let any of my product with that kind of quality. And I would not have my quality time of playing wasted on the overkill productivity such as write yet another WS library. Just leave the SAX and those JAX-RPC, JAX-WS, and WS-* to the right people and Apache is them.

Oh, btw, to have your own keystore just put these lines in the main:

System.setProperty("javax.net.ssl.trustStore", "YOUR_KEYSTORE");
System.setProperty("javax.net.ssl.trustStorePassword", "YOUR_PASSWORD");

I know, you can use the funky way like mentioning it in command lines by adding -Djavax.net.ssl.trustStore=YOUR_KEYSTORE -Djavax.net.ssl.trustStorePassword=YOUR_PASSWORD to the command line. I added that to my Axis AdminClient utility. But, I don't recommend that, especially when using SSL for a server. It could be exposed by a naughty user. If you would like to debug, you could add -Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol -Djavax.net.debug=ssl

Anyway, I don't want to lose in despair of inability to have two different keystore. So, I manage to learn about the keytool command tool provided by Sun's JDK. I just need to store the certificates in one keystore. I know about the way to store the certificates in single command line, but I have to use two command lines because of the forgetfulness. For the sake of laziness, let me show you:

1. Suppose we have generate a Keystore for our server side:
   
   • keytool -genkey -keystore aKeystore.jks -keyalg RSA
2. And we want to merge the other keystore which contain certificates of other server.
   
   • keytool -export -alias keyAlias -keystore yetAnotherKeystore.jks -file outputFile.cert
   • keytool -import -alias keyAlias -keystore aKeystore.jks -trustcacerts -file outputFile.cert
   Btw, if you don't know what is the alias, just see it:
   
   • keytool -list -keystore yetAnotherKeystore.jks
3. But, if you don't get it, just google it.
   

Btw, "encoded" is considered deprecated, SOAP 1.2 add it as optional and WS-Profile prohibit it, but PHP5 just love to abuse that in their own WS implementation. PHP5 implementation is very similar to nuSOAP implementation. Yeah, then again why not using WSO2 for PHP. Hmm.. yet another framework? I myself recommend those PHP programmers to use that, but it seems too cryptic for them to code it. Yeah again, you could just make some wrapper of the creepy part, but, hey, I'm not the PHP guy.

Anyway, as I see the working example of WSO2/PHP, I think the PHP dev guy just not see the example, yet. You don't need to make your own WSDD, WSDL, or the worst: some SOAP messages. I think the poor guy just watch the Download page without seeing the Library page where the tiny description tells about tutorial. Hmm... I guest I just tell him later.

The Debian package of WSO/PHP is not so Debian. It assumes that we have a working Apache server as the front end of PHP. The workaround of that is to create a /etc/php5/apache2/php.ini file. After that, split the file configuration accordingly. For the sake of laziness, I'll just show you:

1. Append these lines in the php.ini:
   
[wsf]
wsf.home="/usr/lib/php5/20060613+lfs/wsf_c"
wsf.log_path="/tmp"
wsf.rm_db_dir="/tmp


2. Put the loading extension in /etc/php5/conf.d/wso.ini:
   
# WSO/2 PHP Extension
extension=wsf.so

You may name the wso.ini as whatever in case you don't like the name. Btw, As I dive, I think the poor PHP dev guy is using MTOM mode for generating the WS. No wonder he is exposed to the cryptic SOAP.

Okay, this is getting lame. I think I will continue about WS later on. Oh, just in case you don't know, WS is abbreviation of Web Service.