1a) There are (at least) two different topological solutions for placing the ODR, the "standard way" where the ODR is placed between the web- and WAS tiers. The second where the ODR is placed before (or rather replaces) the web server tier. In the first case the was plugin file still needs maintenance whereas in the second the web servers only serve static content and does not need to forward requests to the WAS tier. The second alternative also eliminates one network hop for non-static (WAS) content. Do you agree with these pros and cons and what other do you see in this case?
Yes, you have summarized the two alternatives very well. The one additional consideration relates to network security. We have found that many customers prefer to have webservers in a network DMZ, which is why we are supporting both configurations. If your network security configuration allows it, it is definitely preferrable to run just the ODR in front of the application servers.
1b) The ODR anyway becomes the "heart" of a WAS XD install and thus if it stops working for some reason, more ore less "everything" stops. How do you recommend that we avoid this single point of failure? Should one put two (or more) ODRs on different machines where one is master and the other standby or
You should run with two (or more) ODRs to provide failover for the ODRs. In front of the ODRs, you should use an IP sprayer such as IBM's Network Dispatcher.
2) We will not have time to install and "play" with XD for this study. How modular is XD, i.e. what parts (if any) of an existing WAS ND install will be replaced by WAS XD? Is it possible to do a minimal install and what part(s) are installed in that case? Is it possible to "undo" a WAS XD install without having to reinstall WAS ND parts?
You can install XD on top of an existing ND install and then uninstall it without needing to re-install ND. To make full use of XD's features, you should migrate applications that are installed to static clusters onto dynamic clusters. If you uninstall XD, the dynamic clusters will revert back to static clusters. As a matter of general practice, I would make a backup copy of your config tree (
3) About Edition Mgmt (http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp)
The function that initially looks most interesting is the ability to deploy new applications (or versions of) applications with 24x7 reqs. As we understand it WAS XD Application Edition Mgmt does just that for you. It even lets you pretest a new edition on a dynamically/automatically created clone and lets you specify a group of users that should be able to validate the new edition/version. The documentation has a disclaimer that talks about that the differences between the old/current and the new edition must not be too big for this to work. Could you describe more exactly how big differences are allowed for this to work. What happens if the differences are "too big"?
For example, changes that required DB schemas to be updated would be impossible to slip stream since the old version of the application and the new version of the application would need to be accessing the database tables simultanesouly. In general, application changes that require changes to existing resource definitions would probably be a change that is "too big".
4) What does the release plans for WAS XD look like (with refresh packs, new releases etc.)?
We are preparing to release XD 6.0.1 in the first quarter of 2006, and we will most likely have another release (XD 6.1) in 2006
5) It has been hard to find extensive information (documentation, Redbooks, forums) about WAS XD on the web. Do you have any ideas about where we could find more information? Perhaps you have some useful documentation you could send over?
We are getting ready to release a new Redbook and we are trying to make more information available on our blog (http://www-128.ibm.com/developerworks/blogs/dw_blog.jspa?blog=779&ca=drs-bl) and you can ask questions directly to the developers in our forum (http://www-128.ibm.com/developerworks/forums/dw_forum.jsp?forum=778&cat=9)