Migrating to WebObjects 4.5 on the Server

4. May. 2000, Tomi Engel

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:

Based heavier on open standards.
All config files are now XML files, making them easy to analyze or postprocess with other tools. Almost everything is controlled using HTTP communication between processes which makes it possible to plug in custom control mechanisms
More dynamic and scalable
Most of the information is gathered dynamically, which keeps the entire system more in sync with reality. The new "load based load balancing" gets a better performance out of your server cluster, and the fact that service instance numbers are now, more or less, random makes it painless to add and move instances on the production system.
Faster and smarter
The webserver adapter has not only been tuned for speed but it also allows tuning of the communication channels (socket time-outs, buffer sizes) and now knows directly about apps which are in a "refuse new sessions" mode so that it will not try contacting them unless it makes sense.
Better failover support.
If apps do not respond the adapter can react on an individual basis, causing specific error pages to occur or redirecting the request to a backup server cluster. And since it is dynamically configured, the crash of one server will automatically be recognized by the adapter and handled properly.
Less error prone
The old system was build around distributed objects (communication channels which had to be kept alive) it was struggling with resources that were not freed the way they should have been or suffered from blocked channels which blocked the entire monitoring. Now that Monitor is just configuring some files and all communication is performed over stateless HTTP and UDP messages all known problems seem to be solved.

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.

** This might not be true in general. WO 4.5 is no longer required to end up in /opt/Apple since it can be installed at any location. So with some "hand tuning and hacking" it might be possible to install 4.0 and 4.5 on the same machine. But you really need to know about library search pathes and how to get both Monitors running on the same machine, which might require renaming the 4.5 Monitor binary. Since we did not test that yet we can not comment if this really will work or not.

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.