This article was written for the stepwise publication.
Migrating to WebObjects 4.5 on the Server
The latest release of WebObjects has delivered many new features into developers hands. But to those who need to operate an application server the deployment changes might be even more valuable, because it makes the entire setup more stable and easier to control and monitor.
Getting a new license is the easiest step. This is "only" a money issue and if your management was smart, they got that annual upgrade subscription and it is just a matter of calling their Apple Enterprise sales contact.
For developers the move is still easy. Usually a recompile of old sources will be enough to enter the 4.5 world. But developers can only migrate to 4.5 if their customers and production servers are also upgraded, because 4.5 apps will not run on a 4.0 server. So the core questions are: Why? and How? to migrate to 4.5 on the server.
Radical cure for simple setups
In small environments you might just have one or two servers and just one or two applications running on them. The developers are in-house or easy to reach and all apps are recompiled and tested within a few days (weeks) making it possible to stop the servers on a sunday, install WO 4.5 and then get online with a completely upgraded system.
While this can be "dangerous" if testing gets skipped or is reduced to "lets see if the sources compile and the binary launches", it still will be a common scenario for those installations which are small enough or not that important after all.
Phase me in ... Scotty
Since WebObjects is very often running critical services and living on server clusters where downtime costs lots of money, and system software updates need to be organized and agreed upon by multiple hierarchies of managers, it is not that easy to migrate to a new software release after all.
First we need to find the killer arguments so that management or the sysadmin will agree, that migrating to 4.5 is a good thing from the deployment perspective. These arguments are easy to find if you check Apple web pages or the release notes:
With so many major changes it becomes clear that 4.0 and 4.5 will not coexist as peacefully as 4.0 and 4.01 services. If you want to take advantage of the new monitoring and administration tools, you do not only need killer arguments but a smooth migration plan too.
With only one server there is not way to migrate, so you have to switch**, and even if you have more servers the migration needs to be prepared so that the new system can be slowly phased into production.
Step 1: Get adapted
If you know WebObjects then you know about the main blocks a typical service is build from: your webserver of choice, the WebObjects adapter, the monitoring tools, your applications, your database and backend system of choice.
The application is usually easy to port and the backend and database are not affected anyway. If you run the service using your own monitoring scripts and access it directly at its port you can stop reading this article, because you are not affected by any deployment changes at all. Otherwise the adapter will be the first component that needs to be replaced.
Luckily the WO 4.5 adapter still contains code that knows how to read a WebObjects.conf file. This makes it trivial to test the new adapters stability. Get the new CGI on your webserver, make it point to the old conf-file and sit and watch for a couple of days.
If it is all as stable as it should be, you are ready for the next modification. Now that you have the new adapter you can take advantage of its new features, if you are able to provide it the necessary information .... which means creating the new WebObjects.xml file.
A public domain tool called farmersWO4taskd is doing exactly this. It is a WebObjects 4.0 application which will take your WebObjects.conf file and convert it to the new XML format, either writing it to your disc or making it accessible by HTTP in a way which is compatible to the new wotaskd from 4.5. Details about this tools capabilities can be found in its documentation.
Looking at the features of the new CGI-adaptor you might recognise that "step 1" of this migration will be benefitial to those who will keep 100% WO 4.0 on the application servers as well. You do get some of the new goodies after all.
Step 2: Plug 4.5 in
Once you have established the new CGI-adaptor and got it integrated with your 4.0 services things are straight forward again, because the adapor will be able to detect 4.5 services. Just do a fresh install of WebObjects 4.5 on your server, get the new binaries from your developers and add the machine to the adaptor config:
WebObjectsConfig http://wo40server.my.com:1085,http://newwo45.my.com:1085 10
The only gotcha will be that during the transition you will have to deal with two Monitor applications. Because of the way they perform their monitoring is so different, they will not interfer with each other, but they will not see the other services as well. As long as you run both Monitors on different machines and access them via different webservers you are safe; otherwise you get in trouble at the adaptor level. Since you can access a WebObjects process directly through its port, working around this problem is possible and fairly easy.
Maybe in the future the farmersWO4taskd will be able to fully replace Monitor(Proxy) so that you could shut down the 4.0 monitoring tools by the time you introduce the new ones, but right now this is not possible.
Step 3: There is a "step 3"?
As soon as WebObjects 4.5 is part of the deployment all that is left is to slowly shut down the 4.0 servers and migrate every service to 4.5 ... so basically there is no "step 3".
Since WebObjects 4.5 is based on undocumented but easy to analyze protocols there might be even more advanced ways of integrating 4.0 with 4.5 which just have not be discovered or implemented yet.
However ... as of today I do not have "industrial strength" experience with deployment under 4.5 and while the concepts described above do work in a small test setup the real world tests are still head of us. Please keep that in mind.