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
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
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
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.
4. (Improved) EJB 3.0 Support
BEA was more reliable than most product companies in releasing robust .0 versions. Still, we all get better with time and practice and 10.0 was the first version to support EJB 3.0 without a plug-in. And it was pretty good. Now it is better, with a great deal of effort focused on performance, reliability, and flexibility in management.
5. JDBC Updates
In case you have missed the news, WebLogic is owned by Oracle now, so it is no surprise that there are some major enhancements related to JDBC. To start with, most of the type 4 drivers have been updated. Improved support for Oracle RAC is a given.
JDBC 4.0 support is also introduced in this release of WLS, and JDBC 4.0 provides some major enhancements, such as:
- Auto-loading of JDBC Driver
- Improved connection management
- RowId Support
- Annotation-based SQL Queries
- Improved exception handling
The three major bottlenecks of web-based applications are code, network, and data. If data has been a pain point in your applications, these are benefits that should at least be tested out in a POC environment.
6. Spring Console
If you had any doubt about the popularity of Spring, the inclusion of an out-of-the-box management console in the most popular commercial EJB server should remove it. There is also full integration with Spring security.
There are many Spring-based applications deployed on earlier versions of WebLogic Server. Some of these deployments have had maintenance challenges. In many cases, those challenges have become manageable through a combination of updates and patches. In other cases, they are upgrade candidates just waiting to happen.
7. SAML 2.0 Support
There is actually a long list of new and improved Web Service support features in WLS 10.3. In the world of Web Services, the challenges are performance, reliability and security. For the first two there are many contributing factors, such as vendor platforms, code implementation, architecture, hardware, etc. For security, the highest hurdle is often the complexity. SAML 2.0 provides a simpler method of securing web services.
8. Easier Look And Feel Changes
At first glance, this doesn’t seem like all that impressive of a feature. But if you search for articles on WLS LnF customization, you will find that it didn’t use to be all that easy, and there is a really good use case for wanting it to be. The most recent real-life scenario I dealt with where this would have been really useful was where I had to administer seven different environments (development, integration, performance testing, configuration testing, functional testing, acceptance testing and production) during the pre-launch phase of the project. It would have made my life much easier to have color-coded the different consoles for each environment as it was more the rule than the exception to do updates to multiple environments at the same time, and almost always very late in a long day when someone had to have the changes done immediately.
9. Deprecated Functionality
Just like there is no fighting city hall, there is no use discussing whether deprecating a feature is a good idea. While I may personally become annoyed by a feature missing that I used all the time, there is almost always a better way that will be just as useful once I read up on it. And it is much more likely that I never even knew the feature was there in the first place and won’t even know that it changed. I have web applications that I wrote in 2000 that deploy seamlessly to the last servlet containers. I have also consulted on projects where everything came to a screeching halt in a dot release upgrade, which is why it is a good idea to have your development team review the deprecated list if you are not strongly compelled to upgrade. While every WebLogic Server administrators I have met has been both brilliant and charming, they generally have no need to know what low-level APIs the application development team relied on to get into production on a tight schedule.
10. Support End of Life for Your Version
This does not necessitate upgrading to 10.3. You have the option to not upgrade at all if your current version serves all of your needs. Or you could upgrade to a version lower than 10.3. If your current version is at EOL and none of the first eight items have you the least big excited, staying where you are would make the most sense. Sure, there is 99% chance that you will eventually have to upgrade, but at this point in your application’s you may end up upgrading twice if you do not have any great incentive to do so now.
If you are considering upgrading just to continue receiving support, I would highly recommend reviewing your application roadmap to determine if it makes more sense to go for the latest version or just far enough up the version tree so that support and application retirement coincide. While support retirement, once published, rarely gets postponed, the planned decommissioning or upgrading of a custom application deployed to a J2EE application server frequently does get put off. Be careful that a stop-gap upgrade does not cause you to do more of the same each time a version comes to EOL or you will feel like you are bailing out a boat with a Hula Hoop.
Every upgrade of every application promises to be better, cheaper and faster than the version before. My original title for this article was “10 Reasons to Upgrade to WebLogic Server 10.3”. Then I started thinking about an operating system upgrade I did not long ago, and remembered that not all decisions are that simple, and what is definitely a compelling argument for upgrading in one case (or even most cases) is never a reason for every case.
I am not a proponent of upgrading for the sake of upgrading, though I do believe that we are still in a period of Information Technology history where the need to upgrade is a fact of life. The important thing is choosing when to upgrade, because the bottom line is ROI, especially in the current economic climate. Most of the ten points discussed in this article could be the deciding factor to upgrade singly for some applications. For other applications, even a 9 out of 10 may not be enough reason to upgrade yet.
About the Author
Scott Nelson provides optimization services designing, developing, and maintaining web-based applications for manufacturing, pharmaceutical, financial services, non- profits and real estate agencies for use by employees, customers, vendors, franchise’s, executive management and others who use a browser. For information on how he can help with your web applications, please visit http://www.fywservices .com/. He also blogs all of the humorous emails forwarded to him at Frequently Unasked Questions and web technology blurbs at Head in the Web.