Porting J2EE apps to WebSphere
So of course everyone who writes in Java is familiar with "write once, run anywhere" and this has really helped Java get in a lot of doors. I guess this might work if you have some console app or something, but in the real world there's a lot of time spent making sure your Java (and especially J2EE applications) run on various OSes, JREs and application servers.

Today I was conducting a dismal interview where I asked about the candidate's experience with porting a J2EE application from WebLogic to WebSphere (which was listed on his resume). The candidate said that it was very easy and he just deployed his application with no problems or changes necessary, he had no changes made for the application to run properly. This was one of many bad signs for the candidate.

I really hate WebSphere and I really hate zOS (MVS). Because of this, the fates conspire to constantly make me port applications to WebSphere (I finished my third port of a J2EE app to WebSphere). Porting to WebSphere isn't the worse thing in the world. I just had to change how we read the JNDI bindings for our EJBs (which will be easier once I remove all the EJBs from the application), redo the data sources, change the JAAS configuration files I was set and the app was up and running. The real challenge came with zOS and its EBCDIC charset.

zOS is bizarre, it costs tons of money, runs slowly, is difficult to administer and gets JVMs and app server releases after everybody else; but companies use it. IBM is trying to sell Linux on the mainframe, but I'm not sure why this is a good thing. Somehow it's better to spend $1MM on a huge mainframe running a bastard form of Linux than 500 Linux servers from Dell? I'd love to see the mangled TCO studies on that one.

Anyway, our customers use zOS and they buy my company's software so we support zOS (and make our app run pretty well actually). Adding character sets to all out File IO is probably a good idea anyway as it makes internationalization easier. This solved about 50% of our problems. We also had a third party app that specifically needed the Sun JCE for some encryption algorithms it uses. The IBM JRE on zOS (and AIX actually) of course doesn't come with the Sun JCE. It comes with the IBM JCE that has pretty much the same algorithms. Usually, I just package BouncyCastle's provider or IAIK's provider but I guess you can also just reference the provider name in your code. At one point I favored modifying the in the JRE to change the provider level, but this caused problems because 1)it confused customers and 2)the provider the customer has doesn't always have the strong algorithms I need (i.e. some wimpy Sun JCEs only have the 128bit AES/Rijndael and stuff like that).

In a nutshell, when porting your app to zOS be careful about character sets and when porting to non-Sun JCEs be careful about JRE differences (like xml support and cryptography support).

I've also had to port to/from OAS/OC4J, Tomcat, JBoss and WebLogic but they usually just boil down to internal security, data sources and JNDI settings.
Technical and personal notes from Brian Lee, technologist/enterprise architect/software developer/soa guy.

February 2005 / March 2005 / April 2005 / May 2005 / June 2005 / July 2005 / August 2005 / September 2005 / October 2005 / November 2005 / December 2005 / January 2006 / February 2006 / March 2006 / April 2006 / May 2006 / June 2006 / August 2006 / September 2006 / October 2006 / November 2006 / December 2006 / January 2007 / May 2007 / June 2007 / August 2007 / September 2007 / October 2007 / April 2008 / July 2008 / January 2009 / May 2009 / June 2009 /
My Photo
Name: Brian Lee
Location: Atlanta, Georgia, United States


Powered by Blogger