The application I manage at work is a client/server application written entirely in java. My company for years has been an IBM shop, so we have a large Websphere presence which is where the server is deployed. The application had been running on Websphere 5.1 for a few years and was fairly recently migrated to Websphere 6.0 to remain on a supported version of Websphere. Because the end of life for Websphere 6.0 is September 2010, we’re starting to plan for another upgrade now (we have major releases in January and June, so we’re targeting the June ’10 release for the upgrade). Websphere 6.1, if IBM holds to it’s pattern of every 2 years or so will remain supported until September 2012, however there’s no current end of life date documented yet (link). To get the longest life possible, I’m looking at Websphere 7.0 as the target platform for our June ’10 upgrade.
We have RAD 7.5 in house and a couple members of my team have installed it. I’ve been working on getting a local WAS 7.0 server up and running and getting our app deployed on it. There are some major differences between Websphere 5.1/6.0 and 7.0. I won’t go into details as those are readily available on IBM’s website, but would like to share some of my observations and pain so far.
Application Background: The server side of our application is effectively broken down into 2 pieces. One component is what we call a provision server that is essentially a cache of configuration data read from DB2. This configuration information contains rules which drive how the second component operates. The second component is the main workhorse app which receives a request, and creates a response based on configuration data retrieved from the provision server (if necessary) and data retrieved from any number of other applications we interface with. We have 2 provision server jvms for load balancing and fail over and roughly 20 app engine jvms spread across 2 data centers (the app engine hosts roughly 3500 end users and we target 200 users per jvm…roughly).
Unsolved Problem 1 – Remote EJB calls across separate local jvm/profiles doesn’t work: Now that you have a high level view of our applications architecture, here’s my first dilema which I haven’t found a solution to. Websphere now has the concept of profiles. Basically a profile equates to a jvm instance. It’s a little more than that, but that’s a good enough understanding for now. So if you want 2 distinct/separate JVMs configured differently, you would need to create 2 profiles and create servers associated with each profile. In all our lifecycles, we have distinct jvms setup for provision and app engine – we don’t cluster the app engine with the provision server because we want our dev/test lifecycles to mirror production, and production is separate because we don’t want a 1:1 correlation of provision server to app engine as the provision server is memory intensive and 2 jvms can handle the entire app engine load very effectively. So I want to replicate that with my RAD 7.5 setup – 1 app engine jvm and 1 provision server jvm running locally within RAD 7.5. That requires 2 separate profiles to be created, then a server defined and associated for each one. No problem. Where I run into problems is at runtime. The app engine makes remote (cross-jvm) EJB calls to the provision server. That requires a JNDI lookup of an EJB remote home object. For some reason, jvm 1 cannot see any JNDI objects that are stored in jvm 2. When I do an initial context and dump out the contents, all I ever get are the local JVM’s name server items. But if I point the local server at one of our test lifecycle provision servers, it sees those just fine. I have no idea why 1 local jvm can’t access another local jvm’s name server. I’m not sure if it’s because of the base version of Websphere that’s running, or some other limitation of the development environment, but that is one hurdle I can’t get over. So my workaround is to just deploy the provision server and app engine in the same jvm as local ejb calls work just fine.
Solved Problem 2 – creating a secure socket for an outbound ssl SOAP request: The app engine is a portal of sorts. It will call any number of external systems to retrieve data and aggregate that data as needed based on the request. There are several system we currently interface and several protocols we use to do so…SOAP over SSL, EJB, JDBD for example. We use apache soap (old, but still works) to call several external systems, one of which is the main system we interface with. In Websphere 5.1 and 6.0, we set our own JKS truststore for the request using the javax.net.ssl.truststore property. This truststore contains the SSL certificates of our target URL. It just worked. Now we move to Websphere 7.0 and the same requests which work in a local WAS 6.o server no longer work. After much digging and reading of documentation, it turns out WAS 6.1 (and 7.0) changed how SSL security was handled. Long story short, when WAS sees a secure socket being created, it assumes responsibility for securing that connection (Big Brother?) instead of letting you do your own thing. Now, there are ways around it, but the point is it is NOT backwards compatible. The quick fix for this was to put the SSL certs in Websphere’s default truststore (go to the admin console, under security and then ssl configuration and you can find a whole bunch of related config). There are several articles on this and I highly recommend reading the Websphere Application Server V7.0 Security Guide for background on this. It is extremely helpful.
These are 2 of the biggest pain points I’ve hit so far, but I have a ways to go before I can say the app is fully certified on Websphere 7.0. If I run into any more issues, I’ll update this post.
Oh, and before I forget to mention, when migrating from RAD 6 to RAD 7+, don’t forget to MIGRATE your JEE projects. There are project metadata differences between the 2 which aren’t compatible. Found this out the hard way.
Hi,
I have a unique problem in RAD7 (WAS 6.1.1). We have two same applications but different versions, running on the same server(deployed two ear’s). When a user logs in both the application simultaneously and tries some action, the functionalitites of older version and newer versions are combined and it behaves randomly. Is it something to do with a single JVM using a common object pool for both application versions or…
I am befuddled..Help
Thanks and regards,
dj
Without knowing more details about your app design and configuration, hard to say. If you’ve got a static back end object cache that both apps are updating, that could be an issue. Or your session management strategy might be an issue if the user is accessing both apps via 1 browser, and both apps are using the same cookie (JSESSIONID) as the session token, there could be some collision there.
Hi,we have a problem with WAS 7.0.0.7 related to SSL HandShake. In WAS 7 we deployed a web service that interface with a EJB that resides on WebLogic through SSL.
In WAS 6.1 we just put the system variable weblogic.security.SSL.trustedCAKeyStore=trust.jks and javax.net.ssl.trustStore=trust.jks and it works but in WAS 7 it does not work. The message exception is com.ibm.websphere.ssl.SSLException: java.lang.IllegalArgumentException: Invalid trust file name of null.
I try to add the certificate to defaulNodeTrustStore trust.p12 but it does not work.
Could somebody help me, i would really apreciate your help.
Being relatively new to WebSphere, most of this was a bouncer. For learning purposes, i needed to know the entire process that is involved for Migrating an Application from say 5.1/6.1 to 7.0. Are there any links you could direct me too.
Check out my latest post. Hopefully it helps.
Thanks Bob. I had come across the developerworks migration guide once. Would be studying it in brief. I am sure your post would also be very helpful. Thanks a lot.
Saludos !! tengo una duda quiero pasa de WAS 6.0 a WAS 7.0 pero las bases de datos estan en oracle 9i y desde la consola de WAS 7.0 no veo que se pueda crear una conexion a oracle 9i solo veo 10 y 11 g hay alguna forma de que funciones WAS 7.0 con esta version de oracle 9i ? si tiene algun manual les quedaria agradecido .)
We have recently our application from WAS6 to WAS7. The WAS6 is still being used.But we have the same application in a test environment in WAS7.A langauge change setting done by setting a cookie ‘languagecode’ works fine for WAS 6 in both Firefox and IE.However, in WAS7 the cookie is set only in IE not in Firefox.Any suggestion on what change should be done
Hi,
I am new to WAS and i got the work on WAS migration from WAS.0 to WAS7.0..what are the initial steps that i have to follow.Could you please guide me on this.
You need to cerate a SSL out bound connection for keystore and trustore and provide key type port url etc.
I am working on a issue. The issue is related to slow EJB look up. After migrating to WAS 7, we found that more than 6 seconds are missed to pass the request to server from client. The client invokes EJB beans and passes the request. We have same ear file which used to be WAS6. Suspect some sort of caching not working in WAS7. Could you please suggest something.
Have you tried tracing end to end (system.out.printlns) to see at what point in the process the delay happens? If it’s within the container’s purview, then you’ll likely need to create a PMR with IBM and have them analyze some additional traces. Without knowing the architecture of your app, really hard to pinpoint. In general, there’s lots of performance best practices documented, for example: http://www.precisejava.com/javaperf/j2ee/EJB.htm
Hi Bob, I took little break from issue and started working for it one week back.
Solution to this issue was, EJB thin client had WAS 6.0.0 libraries to connect to Applicaiton server(v7). I moved the all the jars from RAD 7.5’s base_v6/runtimes/lib(which has 6.0.2 WAS version) and added it to ejbclient classpath. I also removed the WAS 6.0.0 lib claspath from it.
And it worked. Now request gets processed within second( during issue it used to take 6-7 secs)
it seems WAS 6.0.0 is very old and should be avoided
1) Caching local host at JVM
2) Force IPv4 call first
3) TTL(Time to live Value)
check and update the above three things and that will dramatically increase the performance
Hi,
I have few questions
1. Is is possible to migrate webshpere 6.0 to 7.0
2. If yes, Do we have any link which go through the steps of migration and how much time it should take to migrate from 6.0 to 70
Regards
The time and effort involved in migrating applications from 6 to 7 is completely dependent on how complex your apps are. If you have simple war files deployed that don’t really use much Websphere functionality, they most likely can be dropped into 7 with no changes and run just fine. If you have highly complex apps that utilize JMS, JDBC, asynchronous beans, parallel threading, EJB, etc., then it will be take a lot more work to get there. It also depends on how closely you’ve followed the JEE specifications in building your apps. One app I had used parallel threads managed by the application (which was “discouraged” by the spec, but WAS allowed it in 6.0…7.0 enforced the spec a little differently, so we had to convert those to using asynchronous worker threads managed by Websphere). Bottom line answer to this is “it depends”.
HI,
I am very new to WAS and I have to work on WAS 6.0 to WAS 7.0 migration and am finding problem in few jars. can anyone please let me know if any patch is there which resolves these kind of issues.
Below is the error: java.lang.classnotfoundexception com.ibm.ws.transaction.transactionmanagerfactory in WAS 7.0.
There are many such kind of errors. I Know the above error is due to some jar missing in build path.
Please let me know what are the required jars to support WAS 6 in WAS 7.0
Hi Asha,
I am also working on the same, Can you please let me know if you got any solutions regarding above.
Hi Guys,
There is one more update about on WAs6.1 to WAS7 migration.
The OneToMany.orphanRemoval is specified in JPA 2.0, and looks like WebSphere Application Server 7 contains older JPA library, which is loaded before hibernate-jpa-2.0-api-1.0.0.Final.jar. In order to fix this problem place the hibernate-jpa-2.0-api-1.0.0.Final.jar in the WebSphere’s highest priority classloader directory: //WebSphere/AppServer/java/jre/lib/ext.
— Tejendra
hi my just they are shared one theme folder contain all css and images and js and jsp file those theme is deployed in portal server6, and they are intimated to arrange those theme to portal server7. please help me to how we can create theme in portal server7 by using given css and js and images and jsp file please send a mail
HI,
I have to work on migration WAS 6.0 to WAS 7.0 and am finding problem in start application. can anyone please let me know if any patch is there which resolves these kind of error.
Below is the error: java.security.AccessControlException: Access denied (java.util.PropertyPermission * read,write)
at java.security.AccessController.throwACE(AccessController.java:100)
at java.security.AccessController.checkPermission(AccessController.java:174)
Please let me know what are the required to support WAS 7.0