10 Things You Should Know About WebLogic Server 10.3
Those who came to IT a long time ago or very recently have a Pavlovian response to upgrade whenever a new version of anything is released. The old timers have this habit because in the early days you had to upgrade, either to keep from being locked to an early release forever or to fix all the issues from the earlier release (and prepare for the new issues). The newbies tend to upgrade because a) they were taught by the old timers and/or b) they have not been through enough upgrades to know that some are not worth it, and others actually detrimental to the goal.
Those of us who know better still forget sometimes. You have to be optimistic to get into IT, and pragmatic to survive. Sometimes what is new is just too alluring to take the time to evaluate thoroughly. If you are lucky, everything works out. If you are luckier, it becomes mildly painful. Just enough to remind you that it could have been much worse and make you cautious again.
The upgrade we will consider in this article is to WebLogic Server (WLS) 10.3. If the article starts out with reminders why upgrading in general is not always the best decision, it is to temper the enthusiasm that mostly positive points tend to generate. While the benefits are definitely well worth the effort of upgrading for many environments, I cannot begin to imagine all the environments that are out in the wild (at least, without getting dizzy) and what is a huge boom for one application group maybe a headache for another.
1. On Demand Deployment of Internal Applications
This can be a little disconcerting if you aren't
expecting it. The first time you call the web console you
get a notice that it is deploying. Once you get over the
shock and think about it, this actually makes a lot of
sense. The console for a managed server is rarely (if ever)
accessed, so why use up resources deploying it? Also, there
are lots of IT shops where they don't use the console in the
Administration server, either. Instead, they use WLST,
custom JMX, or some combination of those and ANT. WLST gets
a new method in this version, too.
listApplications() makes it even easier for
those who forgo the web UI.
This is one among many changes made in this release to improve performance. In case you are wondering why performance improvements is not in the list of factors to consider for upgrading, it is because they are included in every release.
2. JDK 1.6 Support
There are always developers chomping at the bit to use the latest APIs, so here you go. While the majority of new features since 1.2 have to been to make Java more palatable to developers who are deep in other languages and lower the bar for entry-level developers, Sun has managed to add something valuable to the enterprise in each release, too.
In the case of 1.6, many of the key features are also utilized as part of WLS 10.3, such as improved monitoring and management tools that are easier to attach at run time; greater use of annotations for web services; and JDBC 4.0. On its own, 1.6 adds more interoperability with Microsoft Technologies.
The truth is, the odds are really good that someone on your development team has been building things that need Java 6 support, so now you can find out what it is and if you really need it.
3. FastSwap Deployment
While the points in this article are a distillation of the release notes, something that release notes rarely cover well is the true value of some features. Supporting new APIs and protocols are mostly obvious if you are interested in using them, and you are interested in using them because you have read about them elsewhere. But the huge boon that FastSwap Deployment provides to a developers daily life is not adequately captured in:
"With FastSwap Deployment in WLS, Java classes are redefined in-place without reloading the ClassLoader, thereby having the decided advantage of fast turnaround times. This means that you do not have to wait for an application to redeploy and then navigate back to wherever you were in the Web page flow. Instead, you can make your changes, auto compile, and then see the effects immediately."
The above does not touch on the hundreds of work hours wasted every year on packaging and deploying code to see the change of a single update. It does not touch on the equal (or greater) amount of time spent by testers who find bugs, then document them, discuss them, assign them to developers who in turn must make minor changes because they did not test after every update because they did not want to waste the time doing so during development.
All things being equal, the FastSwap Deployment feature is enough to tip the scales for me.