Working at a software company and watching products evolve over the years, "Migrate Early, and Often"is the best advice I can give someone who is trying to stay on the cutting edge of technology. Obviously, if you have an application that's in production with no problems and you aren't planning on adding any new features, then of course keep the same version of the underlying platform. However, if you're developing a new application and are currently in the process of architecting and designing, you should definitely talk with your vendor about what you can expect in upcoming releases. Although you might not target the initial phase of your project to the new release, you can ensure that you have the flexibility to upgrade when that time comes. Keeping your options open will, in the long run, give you a more stable and maintainable product. As one of my friends, Peter Seibel (now at Kenamea), said, "Software gets better."And I think that you can say that almost universally. Some might argue that it should be phrased, "Software gets bigger,"but I take exception to that. This might be true in the world of desktop applications, where new releases inevitably exist only to encourage people to buy the next upgrade; in the enterprise people have support contracts that ensure the next version is available. All the critical aspects of enterprise software increase with each new release: reliability, administration, scalability, and performance. Those are the normal ones, but I'm going to add one more aspect that also gets better with age - one that WebLogic has concentrated on in our newest release: usability. That may not be part of the big four, but it's fast becoming one of the more important measures in the enterprise software world.

So what has WebLogic done in this release to increase usability? Migration is an excellent example and the focus of this issue of WLDJ. One of the big problems that people had moving from previous WebLogic Server versions to the newest release was the changes that had to be made to accommodate J2EE. The move from EJB 1.0 to EJB 1.1 was particularly painful because there were some source changes that had to be made. For people who are migrating from 5.1, the biggest obstacle was often the switch from using the weblogic.properties file to using Web applications (.war files). This was especially true for our ISVs, who had become accustomed to releasing their products in a certain way. In that transition we attempted to solve the problem through documentation and support. Although people got through it, I'm glad that future migrations will be done mostly through effective applications of technology. From WebLogic Server 6.0 and forward we have kept the config.xml file as a backwards-compatible configuration store so new versions of the server can read an old version of the configuration and still understand it. In the process it upgrades that configuration to be perfectly compatible with the new system. WebLogic Server 7.0 helps you migrate to the newest version using a number of tools and built-in functionality.

Inside the server, we again have the capability to read an old config.xml and upgrade it to the newest version. In fact, you might have heard about the new security framework that was released with WebLogic 7.0. This framework can even read your old security properties from 6.1. This gives everyone an easy upgrade path if you're not planning to use many of the features of the new security framework right away. To address the needs of applications, WebLogic Builder will automatically upgrade your old application .ears, EJB .jars, and Web Application .wars to the newest versions of the specifications. You do this by starting up the tool, loading the application in question, adding in any new functionality, validating the configuration with the (possibly) new restrictions, and then saving the configuration files back to the application. This upgrade path for applications makes it much easier for people to test on the new platform to ensure that everything behaves as it did before the upgrade.

Even with these tools, however, the developer still has some responsibility to ensure that the application works properly with the new system. Some changes to the J2EE specification, plus bug fixes that occur between releases, can sometimes cause incompatibilities that must be found prior to going to production with an application. In order to find these differences you must have a proper set of unit, feature, system, and performance tests in place to validate that the new version of the platform software performs as you would expect. If properly implemented, these tests can find any problems well before they are deployed to a customer.

Finally, there's one other selfish reason to upgrade to the next release of the product. You'll be working with the current state of the art. Staying on top of new technologies, like J2EE 1.3 or Web services, is very important for any developer. To sum up what I've said, I will rephrase the tagline: "Migrate as soon as you can."