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.
More Here
Courtesy:http://bairdblog.wordpress.com/