From the IBM WebSphere Developer Technical Journal.
At the recently concluded WebSphere Technical Exchange, I was privileged to run a session with the same title as this article (and its three predecessors). The attendance at my session leads me to believe that the observations I have been providing here have been valid, well received, and enormously helpful to colleagues and customers. I suppose it's possible that attendees were simply looking for a comfortable place to sit down, but my ego prevents me from entertaining that likelihood. Therefore, I offer this fourth installment of questions I am asked repeatedly, along with the answers that I give repeatedly. As before, my most frequent response will be "it depends" -- which will come as no surprise to many of you who attended the WebSphere Performance "Ask the Experts" session at the WebSphere Technical Exchange, where all three "experts" used that response -- sometimes in unison! Of course, I know you won't let me off the hook if I use that answer for everything, so the following offers guidance on what you need to consider to determine the best answer for your specific situation, plus some definitive answers to a few common questions.
A: Yes, WebSphere Application Server Network Deployment (and WebSphere Extended Deployment) supports mixed version cells, but this is intended as an interim measure, meaning a few weeks to a few months. This accommodation enables you to move from one version to another without requiring you to do so in one weekend (or less), but this is not a long term measure. IBM certainly supports customers who encounter problems when running mixed environments, in most cases, but the "supported" and "recommended" do not mean the same thing.
My personal recommendation is not to run mixed version cells for an extended period, since the longer you run with two (or more) versions of anything, the greater your chance of encountering problems. (Do you encounter problems when running identical nodes in a cell?) When moving from one version of WebSphere Application Server to another, I usually recommend simply installing the new version on the same machine where the current version is already installed (which is referred to as co-existence), run two cells (one is the old version, one is the new version) on the same hardware, and then adjust the WebSphere Application Server instances in each cell as they migrate; for example, subtract one WebSphere Application Server V5.x, add one WebSphere Application Server V6.x.
Specific to Version 6.1, there is a new security infrastructure in that is "secure by default," and includes certificate generation (with host names). If you migrate cells when migrating to Version 6.1, the migrated cells will remain insecure by default -- unless you had gone to the effort of securing your previous WebSphere Application Server environment. This isn't to say you can't run pre- Version 6.1 cells with Version 6.1 (or that they won't be supported), but there are additional steps to consider.
Again, I recommend that you do not run mixed version cells. And, again, this does not mean that mixed versions cells don't work (they do), or that you will not be supported if you choose to do so (you will). When asked about this by customers, my typical response is "yes, IBM will support you if you have a problem, but I would prefer that you not have a problem in the first place." Most people agree with this logic and that ends the discussion.
A: As with the discussion above on mixed version cells, I'm going to recommend that you not use WebSphere Application Server to manage your HTTP servers, even though WebSphere Application Server does provide functionality for doing so, and even though IBM will provide support should you choose to do so. My reason for recommending against this is because an HTTP server should be hardened for functioning in the DMZ. While WebSphere Application Server offers a secure and supported solution for remote management of IBM HTTP Server, not using this function leaves one less avenue of attack.
It's no coincidence that this is the very first item mentioned in WebSphere Application Server advanced security hardening, which states, "Put the Web server in the DMZ without WebSphere Application Server." (In this context, "WebSphere Application Server" includes all WebSphere Application Server components, including deployment manager, node agent, application server, and so on.)
Having made this recommendation, I will mention that if your infrastructure includes a reverse proxy security server in the DMZ, and, as a result, your HTTP servers are not located in the DMZ, then I would be less concerned about using WebSphere Application Server for HTTP server management. However, I'm not sure that the minimal time savings gained in doing so would be sufficient justification.
Q: What version of <some open source implementation> is shipped with WebSphere Application Server?
A: I am often asked "what version of Xerces (or Xalan) is shipped with WebSphere Application Server?", usually because someone is concerned about conflicts between the version(s) used by the WebSphere Application Server runtime and those used by their own applications. In reality this doesn't matter, since the classloader in WebSphere Application Server (V5 and above) enables you to package a version you want to use with your application, and then specify the version of a class (or classes) that you want to use. The version you want (instead of the version used by the runtime) is then loaded. This is accomplished by specifying "PARENT_LAST" for the classloading mode for either the application or the Web application. Doing so insures that your application uses the implementation in the EAR (or shared library) and prevents possible breakage when WebSphere Application Server maintenance changes versions. There's further discussion of this in Integrating Jakarta Commons Logging.
Of course, if you're just naturally curious, there is a relatively easy mechanism for determining the version shipped in WebSphere Application Server. There is a "Version" class that is included in each of the JARs. The execution and output of this class for WebSphere Application Server V6.1.0 is shown here:
C:\WAS61\AppServer\java\jre\bin>java -cp .\lib\xml.jar org.apache.xalan.Version XSLT4J Java 2.7.4 C:\WAS61\AppServer\java\jre\bin>java -cp .\lib\xml.jar org.apache.xerces.impl.Version XML4J 4.4.5 |
Q: Should I use blade servers with WebSphere Application Server?
A: This is one of those "it depends" situations. (You knew that I would work that in at some point, right?) Basically, a blade strategy can work very well if you have lots of smallm easily replicated things. Blades work very badly if you have very large things that are hard to partition into small chunks. I don't like to see blades used with databases, since databases typically use more than two CPUs, and I worry about blades being used for very large WebSphere Application Server applications that don't fit well into two CPU machines. To be clear, blades are a fine idea if you have sized your applications and have shown they will fit. If you haven't done that, the lower risk approach of larger machines is probably a safer bet. So, depending on the applications, deployment, and size of the hardware (CPUs, memory, and so on), this may or may not be something to consider further.
Q: Should I move from 32-bit WebSphere Application Server to 64-bit WebSphere Application Server?
A: Again, it depends: 64-bit does not automatically provide better performance; in fact, most applications will see little benefit. Applications that experience the greatest benefit are:
- Memory constrained -- The extra memory provided by 64-bit supports a better caching strategy, enabling the application to avoid expensive queries, and so on.
- Computationally expensive code, such as numerical analysis, algorithms, and so on. These can, by virtue of 64-bit registers, perform computations with fewer instructions than with 32-bit registers.
If your applications meet the criteria above, then you might want to consider testing your applications in a 64-bit environment to see if there is value for you. Keep in mind that those moving from 32-bit to 64-bit often see no performance benefit, and instead simply experience a larger memory footprint; this, because 64-bit addresses are twice the size of 32 bit addressesfootprint. The larger memory footprint also fills up L2/L3 caching more quickly, which can have a negative impact on performance.
It's time again for me to wrap up. Hopefully, these thoughts on some of my most often-asked questions have given you something to think about.
- Setting up a remote Web server
- WebSphere Application Server advanced security hardening, Part 1: Overview and approach to security hardening
- Integrating Jakarta Commons Logging
Tom Alcott is consulting IT specialist for IBM in the United States. He has been a member of the Worldwide WebSphere Technical Sales Support team since its inception in 1998. In this role, he spends most of his time trying to stay one page ahead of customers in the manual. Before he started working with WebSphere, he was a systems engineer for IBM's Transarc Lab supporting TXSeries. His background includes over 20 years of application design and development on both mainframe-based and distributed systems. He has written and presented extensively on a number of WebSphere run time issues.
Comments (Undergoing maintenance)
Next steps from IBM
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
