The context root information are in two files, one is obvious and the one is obscure. However, both must be be sync. The not-so-obvious file is org.eclipse.wst.common.component under .settings folder under the web project. The obvious file is application.xml inside META-INF folder in the EAR project that contains the Web project.

J2EE 1.3 implements WS-Security draft specification while J2EE 1.4 implements WS-Security 1.0 specification. This makes it a challenge WAS 5, which is based on J2EE 1.3, and WAS 6, which is based on J2EE 1.4, to interoperate with each other. Luckly, IBM DeveloperWorks has a 4 part article that tacles this problem:

http://www.ibm.com/developerworks/views/webservices/libraryview.jsp?search_by=tackle+ws-security+specification+interoperability+challenges

soapUI is a great tool for testing web service. However, configuring soapUI to test securied web service have not easy. The only information I can get is this page. Fortuanately, soapUI is an open source tool so I was able to down the code and open it in Eclipse to step through the code. I finally figured out how to make it work:

1. Make sure you installed JCE unlimited strength policy (at the end of this link).
2. soapUI does not import jks or jceks keystores correctly. It needs to be converted to PKCS12 keystore.
3. soapUI failed to recognize the server public key in the keystore (a bug in version 2.02?). Instead, I have to provide it the server private keystore for it to work.

Basically, I configure the keystore in the project level. Create the outgoing and incoming configuration. Then I go to binding to bind the outgoing and incoming WSS configuration.

I have had some fun with the dependency injection feature of the Spring framework. With dependency injection, class does not have to know their collaborators at compile time. Objects are connected to each other at run time via spring configuration file. The result is losely coupled application. Spring makes testing easier since one can inject mock objects by modifying the configuration file. The following is what I learnt:

1. It is easiest to start with singleton objects. Singleton was often implemented with static classes. However, static classes has lots limitations such as static class cannot implement an interface and cannot be inherited. To avoid these limitation, one can go with various factory patterns. People from asp.net background often use Provider pattern. To use provider pattern, once often need to create configuration handler. With spring, once can use a generic configuration file, making spring much easier to use than provider pattern. With spring, one can use any class as singleton without losing any OO features.
2. Code to interface. Create interfaces and then implement them. Code the client to consume the interface instead of the implementation. This way, different implementations can be easily injected.
3. Constructor injection vs property injection. Use constructor to inject required service. Use property to inject optional service.

So much for the theory. Now let us see some code:

1. The following spring configuration define some singleton objects. Each object is identified by an id.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">

<beans>

<bean id="myDataSource" class="org.springframework.jndi.JndiObjectFactoryBean">

<property name="jndiName" value="jdbc/myDataSource" />

</bean>

<bean id="mySessionFactory"

class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">

<property name="dataSource" ref="myDataSource"/>

<property name="mappingResources">

<list>

<value>MyStoredProc.hbm.xml</value>

</list>

</property>

<property name="hibernateProperties">

<value>hibernate.dialect=org.hibernate.dialect.DB2Dialect</value>

</property>

</bean>

<bean id="myHibernateTemplate"

class="org.springframework.orm.hibernate3.HibernateTemplate">

<property name="sessionFactory">

<ref bean="mySessionFactory"/>

</property>

</bean>

</beans>

In the above config file, we use bean element to define bean and use ref attribute to inject one bean into another bean. Spring provides a few helper classes to work with Hibernate.

2. In web applications, the spring configuration file can be loaded using a servlet listener anc context parameters. Spring provides several listeners, such as org.springframework.web.util.Log4jConfigListener and org.springframework.web.context.ContextLoaderListener. One can load the listener with the following snippets from the web.xml file:

<context-param>

<description>

</description>

<param-name>contextConfigLocation</param-name>

<param-value>/WEB-INF/spring-config/spring-*.xml</param-value>

</context-param>

<listener>

<description>

</description>

<display-name>Log4jConfigListener</display-name>

<listener-class>org.springframework.web.util.Log4jConfigListener</listener-class>

</listener>

<listener>

<description>

</description>

<display-name>ContextLoaderListener</display-name>

<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>

</listener>

3. Spring context loader loads the context into the servlet context. One can retrieve the spring context from the servlet context. However, if a class does not have access to servlet context, we can create the following helper class:

public class SpringContext implements ApplicationContextAware {
 private static ApplicationContext ctx;
 
 /* (non-Javadoc)
  * @see org.springframework.context.ApplicationContextAware#setApplicationContext(org.springframework.context.ApplicationContext)
  */
 public void setApplicationContext(ApplicationContext appCtx) {
  ctx = appCtx;
 }  public static ApplicationContext getContext() {
  return ctx;
 }
}

Note that class implements ApplicationContextAware interface. This allows spring to automatically inject application context to this class. This can be done with the following configuration:

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">

<beans>

<bean id="springContext" class="acme.SpringContext" />

</beans>



4. Lastly, I will show one example of constructor injection:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">

<beans>

<bean id="jbossCache" class="acme.JBossCache" >

<constructor-arg type="java.lang.String" value="treecache.xml"/>

</bean>

</beans>

Earlier, I posted the interoperability between .net and Java web service. I will continue on how to access secured Java web service from legacy apps created with VB6 COM objects or classic Active Server Pages. Since we have already solved the interoperability issues between .net and securied Java web service, the next challenge is to register the .net proxy as COM object so it is accessible from VB6 and ASP pages.

Not all the .net classes can be registered as COM object. ASP can only work with COM objects that supports OLE automation so the it can work with even more limited .net classes. Proxy classes derived from WSE2 Microsoft.Web.Services2.WebServicesClientProtocol cannot be registered with dual interface. Fortunately, it is possible to define explicit interface for COM clients. The Visual Studio refactor feature made it pretty easy to create an explicit interface. After creating the interface, mark the class itself with [ClassInterface(ClassInterfaceType.None)] attribute. It is important that the explicit interface must be public. Another important step is do not forget to set ComVisible(true) in AssemblyInfo.cs.

The next step is to register the .net assembly as COM using "regasm myassembly.dll" or unregister with "regasm /u myassembly.dll". If we do private assembly deployment (that is, not registering the assembly into the global assembly catch with gacutil", the dll and the config files need to be copied into the directory of the exe that hosts the assembly. That means, for VB6 development, they need to go into the directory where VB6 resides. Furthermore, we need to rename myassembly.dll.config into HostExeName.exe.config.

With this technique, we can access fairly complicated, securied web services from our legacy apps.

Earlier, I posted that WSE 3.0 does not interoperate with Websphere web service. It turns out that WSE 2.0 would work just fine because different algorithm used to generate the keyid. Here are the procedures:

1. Import the keys into the Windows key store: Import the key as mentioned in this post. For testing purpose, I imported both certificates into Current User store. I imported the client private key/certificate into the Personal store. I imported the server key into the Other People store.
2. Create the client proxy. What made it a bit more complicated is that I use .Net framework 2.0 and Visual Studio 2005. While WSE2 works with .Net 2.0 runtime, the tools do not integrate with Visual Studio 2005. So I have to do things manually. From the Visual Studio 2005 Command Prompt, I changed to my project directory, and then ran "wsdl UrlToMyWSDL". This will generate a proxy class.
3. Change the base class of the generated proxy: change the base class to Microsoft.Web.Services2.WebServicesClientProtocol. This allows the proxy to support WSE.
4. Configurate app.config with Configuration Editor: Run WSE2 Configuration Editor. Open my project app.config file. Enable the project for WSE. Then under security tab, select CurrentUser for store location. Also check "Use RFC3280". This will allow the keyid algorithm with to be compatible with Websphere.
5. Add a policy file: From the Policy tab of Configuration Editor, select "Enable Policy". Add a policy for <DefaultEndPoint>. In the wizard, select "Secure a client application" and click Next. In our test case, we encrypt the message but do not sign the message. So just select Required Encryption under Request Message and click Next. Then add the service certificate and click Next and then click finish.
6. WSE2 by default uses different encryption algorithm as Websphere. So we need to add the following XML inside the security element in app.config:
<binarySecurityTokenManager valueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"> <sessionKeyAlgorithm name="TripleDES" />

</binarySecurityTokenManager>

7. Add usernameToken: in our test case, we send username token in cleartext. So we need to add the following code:

I have been trying to make my .net 2.0 WSE 3.0 client to interop with my Web Service running on Websophere 6.0 server. I have pretty much concluded that they will not interop. My web service requires a usernameToken in clear text and the body encrypted with an X509 certificate. This is not one of the turn key scenarios in WSE 3.0. However, with a custom policy and some configuration work, I was able to move fairly close. Basically, the output filter will generate the UsernameToken, X509SecurityToken and Encrypt the body. Here is how the code look like:

In the Java world, keys are generated with keytool that comes with JDK. The keys are stored in keystores in either JKS or JCEKS format. In Windows world, the keys are stored in the Windows key store. Windows key stored can be managed by running the Cetificates MMC. The first step of Java/Windows WS-Security interoperability is be able to exchange keys between Java keystore and windows key store. In this blog, I will show how to export keys from Java keystore to Windows key store.

keytool can export certificates but cannot export private key. To export private key, one need a tool like KeyTool IUI. KeyTool IUI will export a private key entry into two files: one for the private key and one for the certificate. Windows key store cannot import these files so it is necessary to convert them with tools like OpenSSL. The following is the procedure to export a private key from Java key store:

1. Use KeyTool IUI to export the private key. Select PEM as file format for both private key and the certificate file.
2. Use notepad to append the two PEM files into a single file because this is required by OpenSSL.
3. Run the following OpenSSL command: openssl pkcs12  -export -out mykey.pfx -in mykey.pem
4. From Certificate MMC, import the mykey.pfx file.

Added 1/7/2008: An alternative to step 2 and 3 is to run KeyTool IUI in Plus mode. Run run_ktl_plus.bat. Create a pkcs12 keystore. Import a private key into the keystore. The UI allows us to import both the private key file and the certificate file so we do not need to append them as discussed in step 2.

We implemented WS-Security recently. The web services were developed using Rational Application Developer (RAD) and hosted on Websphere. RAD does not support WS-Security on the client-side unless the client is hosted in the Websphere Environment. If the client is not running on a Websphere server, the best one can do is to hosted in a Websphere J2EE client application. For portability, I decided to give it a try to use open source apache Axis and WSS4J to access the web service.

The WS-Security that we implemented is fairly straightforward. We use UsernameToken for authentication and also encrypt the soap body. The procedure to do it in RAD is well documented and only requires configuration. Unfortunately, the WSS4J is not well document. With a little bit Googling and looking into the source code, I am able to piece it together and make it work.

The following is my client_deploy.wsdd file:

1. In WSDoAllSender, user parameter contains the user name in the usernameToken. The encryptionUser parameter contains the alias in the key store. Use SKIKeyIdentifier for encryptionKeyIdentifier (The default is X509KeyIdentifier).
2. By default, WSS4J uses aes128-cbc encryptiion algorithm. We used tripledes-cbc. So we added encryptionSymAlgorithm and encryptionKeyIndentifier parameters.
3. We uses paswordCallbackClass for both request and response. For request, this is the password for UsernameToken. For response, this is the password for our decryption key entry in the keystore.

In addition, the following are the jars we need to include to make it work:

• axis.jar
• bcprov.jar
• commons-discovery.jar
• jaxrpc.jar
• saaj.jar
• wsdl4j.jar
• wss4j.jar
• xalan.jar
• xmlsec.jar

The following is the contents of request.properties:

The following is the contents of request.properties:

JSF is the latest offering for the Java web application development. JSF is an MVC framework, similar to Struts. JSF is an enhancement to Struts:

1. The action is now mapped to a method of a bean instead of a servlet. Components can now have events. This is much more like code-behind in ASP.NET. This reduces the number of files one has to work with.
2. More custom tags and richer controls, such as Data Tables.

Here is how JSF compares with ASP.NET 2.0:

1. ASP.NET 2.0 is the mainstream development framework in .net world. JSF is still considered as unproven. Only a quarter or less Java web developer jobs requires JSF.
2. JSF is a specification instead of implementation. Depending on the implementation used, one may get more or less rich components. So evaluating implementation itself is a major task.

In conclusion, projects using ASP.NET 2.0 should expect stable and well behaved frameworks. Developers should find it much easier to develop web applications with richer functionality and to work with AJAX.