Porting Applications from WebSphere to WebLogic?

JFP queries: "I work for a division of a manufacturing company. We're currently running IBM WebSphere 3.5. We are considering a switch to BEA WebLogic 6./7. Has anyone had luck with IBM's upgrade path? Has anyone else ported a WebSphere 3.5 application to WebLogic? If so, how much of code did you have to rewrite? Are there any 'gotcha!'s that you ran into that you would care to pass along?"

Comments

Two pieces of advice

[tony clifton]

Is your Websphere app unit tested? Use JUnit, and potentially add-ons like Cactus and HttpUnit so you've got some way of verifying your port.

If you decide you need a consultant, remember that the only thing worse than an expensive consultant is a cheap one.

Re:Advice On Moving From JBoss to WebLogic

[Gaijin42]

JBoss will be a relitively easy upgrade, since JBoss does not include any vendor extentions to Java. Therefore your app should be "vanilla" The websphere to weblogic upgrade could be more difficult, because there are vendor extentions. Any code which used that vendor extention will most likely need to be re-written.

Java is write once run anywhere, but only if you stick to the standard. The standard doesn't do everything (yet) so the vendors have pushed the envelope (Just like the browser war)

If you write to the standard you are fine. If you need/want the advanced features, be prepared for migration re-writes.

Silverstream - WebSphere

[AnalogBoy]

Funny i should read this right now. My company is moving from Silverstream to WebSphere. I'm having the joyous experience of learning the application, and my company is trying to decide which platform is best (UltraSparc II Vs. RS/6000 vs. UltraSPARC III). Seeing people want to move is making me want to know how badly Websphere sucks..

Re:Silverstream - WebSphere

[JohnA]

RUN AWAY! RUN AWAY!

WebSphere 3.5x is one of the most painful, convoluted, and just plain evil products ever developed. First off, you are out of luck if you need to use any JDK1.3 or higher features, as WS 3.5x ONLY run's on a specially enhanced version of the IBM JDK 1.2x. While this may not seem like a huge deal, it eliminates the possibilities of using proxy objects in your J2EE apps, which in my experience makes things much more difficult.

Additionally, you will have a hard time maintaining deployment procedures since WS 3.5 uses its own deployment tools and descriptors.

Finally, there are more "undocumented" features in the J2EE support than IBM cares to admit. The best piece of advice I can give regarding that is to first assume the problem is with the app server, then your code. Google will be your best friend during debugging.

If you are stuck with WS3.5, good luck.

Of course, I'm an unemployed Java architect, so what would I know? :-)

Re:Silverstream - WebSphere

[AnalogBoy]

We're stuck with it, apparently. And i can't hate it worse than i hated broadvision.

But we're using 4.0.3 - and possibly moving to 5 when it is released here soon [tm].

Java Hype

[wdr1]

Aren't porting and java supposed to be oxymoronic? ;-)

-Bill

TheServerSide.com

[adamy]

THey have a bunch of discussions about the various App Server platforms and porting between them.

My question is wrt the form processing: How much of your code is written using IBMs custom libraries. This is the point that is going to burn you. And BEA has there own, different solution to the same problem. You may want to look into Struts or Velocity instead, to avoid being locked in to the Vendor.

Why are you switching away from IBM?

Cacheon

[dmorin]

Check out Cacheon, who does exactly this. Their product offering is a Java/JSP rules engine + converter for going from one application server to another. The idea is that you port via an incremental method -- run the converter, see what didn't convert, modify the rules, repeat.

Disclaimer: Don't work for them, but my company is evaluating their product.

My experience

[felipeal]

Has anyone else ported a WebSphere 3.5 application to WebLogic?

I haven't done that, but I did the opposite: migrating from welogic to websphere (and also jboss/tomcat)

Besides some minor problems (easily solvable) on the jsp tags, the main difference between the app servers are the features that are not defined in the J2EE specification yet, and so are implemented in different ways by each app server. In particular:

- authentication mechanism (this is a PITA if you are implementing your own authentication, like we do :)
- custom services (jboss supports MBeans, which might be the standard in the future, but websphere and weblogic have their own way to do that)
- how to start/stop/restart the app server
- how/where to define JNDI objects (like user transacation and data sources)

Overall, I think moving from websphere to weblogic would be easier than the opposite way (websphere is a powerfull tool, but in my opinion it is pretty hard to configure/mantain).

Felipe

Re:My experience

[alext]

I would have thought it well nigh impossible to fail to see that WebLogic 6.0 upwards uses and supports MBeans extensively, i.e. the JMX specification.

So... take this as a lesson on not taking anything at face value in the world of J2EE product comparisons!

upgrade problems

[alayne]

The biggest problem with upgrading from WebSphere 3.5 to anything is that it is pre J2EE 1.2 so it isn't very compliant. The deployment descriptors are not proprietary and the configuration is locked away in the Websphere Admin Database.

Upgrading from 3.5 to 4.0 is not a great process, The server config comes across okay and most of your DDs will come over, but you are required to make sure all your code is supported on the new platform. if you've got old JSPs (.91 or lower) or use EJB 1.0 you will need to hand edit them, the upgrade will fail. Also, if you are using deprecated IBM APIs you need to figure out which ones those are and stop using them. In the end when all is said and done, you are now stuck on websphere 4.0. Its fairly stable, but a beast to administer.

Upgrading to BEA is pretty good. I haven't worked with 7.0 but 6.1 works like a champ. Its really standards compliant. As long as you've got to do some rework I would reccomend this option.

Also, you may wish to check out Cacheon I saw their demo at Java One and I was pretty impressed. I don't know if they handle your particular problem, but they definitely do automated J2EE Migration.

Re:upgrade problems

[Oates]

I recently converted a project from WebSphere 4.0 to Weblogic 6.1. A few things I ran into included:
- WebSphere defines classloaders differently than Weblogic
- Weblogic 6.1 (non-J2EE 1.3 version, or prior to SP2) does not interpret or load EAR files properly
- WebSphere lets you get away with bad deployment descriptors if you change the classloader visibility to "Application"--the other developers has been using Together/J and it took me a few days to clean up the deployment descriptors
- And the custom realm was definitely a PITA. I have to agree with Alayne on that.

I actually had about 13 issues on the list, but most dealt specifically with the way the project was architected. Deployment and installation of the app was easier under Weblogic, simply because ant included tasks to deploy to Weblogic, and I didn't have to write several Tcl scripts like I did for WebSphere. Scripting batch files on Win2K sucks. Installing the app into a clean Weblogic installation was also easier, as I could take the Weblogic config file, load it into a DOM tree, and rewrite the file with the application settings.

(Please note that Tcl is only available in WebSphere 4.0 Advanced Edition--not the one you download for free.)

In the 3.5 installations I've seen, there aren't that many issues unles you're using some of the vendor-specific features of WebSphere. Clean those out, make sure your JSPs are 1.0+ compatible, and that you have properly configured WAR files. If you've done that, your WAR should deploy without any real issues. WS 3.5 is a real pain to keep up, though some clients still insist on using it. I would expect that you'll enjoy being able to use JDBC 2 data sources in Weblogic 6.1+.

Remember, it could be worse: you could have all your developers writing and testing against JRun, while trying to deploy to ATG or Weblogic. And be forced to do development in Windows 95. On old hardware. That crashes all the time.

How is this for ports.

[Frank of Earth]

Same site:

1) Perl
2) ATG Dynamo
3) MS .NET

All in about 2.5 years.

I think the site would best be served from Perl creating static web pages, sorta how Salon does it. Oh well.

Why the upgrade?

[mcwop]

My experience is that upgrading without a very good reason can be more trouble than it is worth.