Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
IBM

Porting Applications from WebSphere to WebLogic? 33

Posted by Cliff from the getting-comfortable-with-a-replacement-framework dept.
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?"
This discussion has been archived. No new comments can be posted.

Porting Applications from WebSphere to WebLogic? More

Porting Applications from WebSphere to WebLogic?

Comments Filter:
  • Is your Websphere app unit tested? Use JUnit [junit.org], 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.
  • In addition to moving from WebSphere to WebLogic, does anyone know about moving from JBoss to WebLogic. We're deploying applications on JBoss now (since it's free) but the corporation is looking at moving to WebLogic. Is Java truly the Write Once. Run Anywhere platform Sun was once pushing?
    • 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.
    • Its not an issue of whether Java is portable, but how your app conforms to the various web application standards and how well those standards are implemented on the various server platforms.

      AFAIK, most app-server vendors provide different levels of support, and even when they support the same standards they have differing interpretations or tools to work with. Sounds like a pain at best. At least for J2EE components. My guess is that simple WAR files will be easily transportable.
  • 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..

    • 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? :-)

  • Java Hype (Score:2, Redundant)

    by wdr1 ( 31310 )
    Aren't porting and java supposed to be oxymoronic? ;-)

    -Bill

  • TheServerSide.com (Score:4, Insightful)

    by adamy ( 78406 ) on Friday July 19, 2002 @03:38PM (#3919022) Homepage Journal
    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?
  • WebSphere stinks in my opinion. We had IBM come in and help set it up on my Sparcs. It runs dooooog slooooow no matter what they did to tweak it. Mebbe IBM didn't optimize it for Sun SparcII, but that was like 2 or 3 years ago.

    The fact that I am not a fan of Java or JSP in the first place didn't help that I was taunting the professional support the whole time.

    But from what I saw and heard the developers said it was trivial to go from ASP to JSP though.

  • Check out Cacheon [cacheon.com], 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 (Score:4, Insightful)

    by felipeal ( 177452 ) on Friday July 19, 2002 @06:16PM (#3919897) Homepage
    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
    • 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 (Score:2, Informative)

    by alayne ( 125070 )
    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 [cacheon.com] 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.
    • 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.
  • Porting to BEA?!?! How funny... my company is currently porting from BEA to Tomcat/JBoss. We are running everything from WLS5.1-WLS7, Commerce server and WLI.

    BEA is so kind as to put there own interpertation of standards (M$ anyone?) inside of their app servers. The custering configuration is awkward and limiting (try restarting a VM if you are serving real traffic. The listener starts before the VM is ready oops.) They don't allow a component architecture, the JMS implementation is dog slow (not to mention that it will only run on one VM).

    I think it's a great product for $10K a CPU. But then again we're serving 2 million transactions a day on a pair of Tomcat servers.

    Why not do a real port and go to c#?

    Beware....
  • Has anyone considered moving to Oracle 9iAS? What do you think about it?
  • 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.
  • My experience is that upgrading without a very good reason can be more trouble than it is worth.
  • Watch out for issues due to classloading. Whilst you may not have this problem (if you are lucky) it is one problem that can be quite complex to solve when having to alter an existing application.

    J2EE Classloading [theserverside.com]

    Will give you a good overview of the issue. Note that there are different MODES for Websphere that means it works differently for classloading between versions. I think that the Websphere 3.51 version is different to most servers in classloading.

    You will get ClassDefNotFound errors in most situations that this problem is seen.

    We support 8 J2EE servers with our product and we find that server configuration is the biggest headache when getting the same application working on all the servers.

Slashdot Top Deals

Swap read error. You lose your mind.

Close