![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
From the IBM WebSphere Developer Technical Journal.
The good, the bad, and the worst
Remember back in grade school, wanting to make up the latest hot catchphrase ("gnarly" comes to mind), hoping it would spread and become world famous so you could boast that you were the one that started it all? Well, never one to give up easily (I'm still trying), I have one that I'm hoping will catch on...
Just about everyone has heard the term "best practice". It's a phrase that's been used and abused to the point where whole conferences are themed around it. As such, it has established itself in the IT Overused Phrase Hall of Fame -- admittedly, a place that likely exists only in my own mind. Unfortunately, fewer folks are familiar with the term "anti-pattern".
A pattern is an abstract, repeatable, and reusable design construct, such as architectures or algorithms. In contrast, the term "anti-pattern," is now often used to represent anything that is a bad idea, or, if you will, a "bad practice". For this reason, I believe a proper name for this thing is not anti-pattern, but an "anti-practice" -- as in the antithesis of a "best practice."
As an IBM Software Services for WebSphere® (ISSW) consultant, I visit with customers of all shapes and sizes, all over the U.S., and so I get to observe firsthand the practices that tend to make customers successful, those that tend to cause problems, and others that just tend waste time and money. These range from technical things, like WebSphere product configuration issues, to logistical things, like how prepared a company is for consultants to be on site. Oh, the stories we could tell! Instead, though, after helping to write a pretty successful book and several technical articles over the years, I thought I would take this opportunity to put together something really useful: an informal handful of technical and logistical suggestions for customers that really could make everyone's life easier. Like my fellow ISSW colleagues, I really believe in IBM and our products, and want to do as much as I can to help our customers be successful. With that in mind, here is my list. The ideas expressed here are solely my own and not those of my employer, friends, relatives, alter egos, or imaginary companions.
I often see applications that have been architected or developed to use home-grown "replacement" code for parts of the WebSphere Application Server/J2EE™ infrastructure. The code might have implemented its own threading, caching, connection pooling, or even (heaven forbid) security infrastructure. If the reason I am called on site is a critical situation (crit-sit), it is very often because of some complex interaction between this kind of custom code and the WebSphere Application Server runtime that is trying to do the same thing.
To be fair, sometimes the custom code was written before J2EE and WebSphere Application Server matured, when there was probably a need for it. But that time has passed, and such code is rarely as solid, reliable, well-tested, and as performant as the code in the product that the customer has purchased. In fact, custom code written for authentication or authorization is generally pretty easy to find or hack holes in. So, no matter what you hear from in-house gurus or code wizards, stay clear of writing this type of code -- and hold your ground! I regularly and consistently urge customers to wean themselves off the ongoing cost of maintaining this "systems" type of code, primarily because they are spending extra money on something that is already right in the box.
Leave the systems code to your products, and focus those expensive development dollars on business logic.
No, not the musicians with the painted faces -- I've heard they can't code their way out of a paper bag. You know what this means: "Keep It Simple" is the only part of the acronym we need to talk about here. Again, to be fair, there is a certain level of complexity that is justified in most cases (the Model-View-Controller pattern comes to mind), but few enterprise applications require much of the overly-complex architectures we frequently see in the field. Just because a PhD or famous technical expert published a paper in the Journals of the ACM doesn't always make it a legitimate basis for your "real world" design. The same thing goes for cool techniques that are posted in internet forums or industry journals. Some are great, sure, but many others are invitations to disaster. Patterns such as splitting servlet and EJB tiers, running load balancers between Web servers and the WebSphere Application Server servlet container, and pseudo-synchronous messaging are not only overly complex and unnecessary for most requirements, they are a performance and configuration nightmare.
Evaluate each proposal on its own merit -- and in context -- with your goals and environment in mind, and make sure the architectures and techniques you want to try are justified and a good fit. Many of my fellow blues harp players are obsessed with playing with the same "sound" as the late Little Walter, and buy expensive, complicated digital effects processors or stuff based on endorsements from pro players to achieve that sound. What they don't understand is that what Walter had came from the soul and often played whatever junk was laying around, and that the pro players often use old junk when you go see them at live venues!
Work with what you have and what you are comfortable with. Never accept a design that doesn't seem "right" based on someone else's insistence out-of-context. Incorporate peer reviews, and if you don't have the right people on staff, contract with IBM to get someone from ISSW to review it for you and give you feedback.
3. Share the love, expose your code
Many customers do not have code or architecture review processes. Taking the time to perform these reviews has many benefits, such as faster advancement of junior programmers, enhanced reuse, snagging malicious code, catching bugs and anti-patterns before the code gets into production, and so on. In environments where stringent code review processes are in place (that is, no code gets into a production build without having been reviewed by multiple parties), the overhead of using Java™ 2 security can often be avoided.
When you do incorporate reviews of this nature, it is critical that whoever does run the reviews be able to ensure the environment is as friendly and non-critical as possible; egos need to be checked at the door. Nobody is above a code review. Code reviews foster "programming with a conscience" -- many developers wouldn't do half the things they do under duress if they knew someone else was going to be looking at their code at the end of the week!
As a first step, employ static code analyzers that will go through your code and search for anti-patterns to ensure that good coding practices have been followed. With some tools, such as that built into IBM Rational® Application Developer V6, you can even build in your own rules.
Many problems I've seen in the field are related to "classloader hell" -- complex and hard-to-debug problems caused by the wrong classes being pulled in at run time due to JAR files having been sprinkled around the infrastructure. One of the founding principals of J2EE is that applications should be fully self-contained within the Enterprise Archive (EAR) file. But yet, due to concerns about disk space and other strange reasons, many shops put JAR files that applications might share into system classpath directories or shared libraries, thus complicating their deployments, administration, and run time environment. This would be justified for something like a database driver, which really is part of the infrastructure and all applications use, but not for much else.
Disk space is pretty cheap these-a-days, so in most cases you should just stick it all in your EAR.
(For more on this subject, read Keys Botzum's excellent J2EE packaging and common code diatribe -- I mean, article -- right here on developerWorks.)
A common cause of serious problems is the use/abuse of the HTTP session for all kinds of garbage. It all starts when one programmer decides to throw a little something in there, then another, and another, until your poor session looks like one of those polluted ponds filled with old tires and washing machines.
Stuffing something into the session is a very common shortcut taken under duress of an impending deadline. The effect on JVM heap sizes and performance (particularly when using persistent sessions) is dramatic. Doing code reviews (see #3) can help to prevent this. Session sizes should be from 2-4K, and there are several ways to measure them; the Tivoli® Performance Monitor that comes with WebSphere Application Server, for example, will show you session sizes.
Programmers aren't the only guilty ones, though. From a topology/architecture point of view, we often also see network demilitarized zones (DMZ, you have one of those, right?) that have become "polluted" due to quick fixes for firewall/port issues, or other problems. The DMZ should be a "naked" -- and thus hostile -- environment for any potential intruder or hacker. WebSphere Application Server instances, databases, messaging servers, mail servers, or other complex processes should not be running there. The DMZ should consist of processes like Web servers or proxy servers that will terminate the user's connection before it reaches the backend "trusted" zone.
Keep it clean. The more complexity in the DMZ, the more potential targets of attack and compromise you present for the hungry and salivating hacker.
Read Those Fabulous Manuals. (What did you think it meant?) Let's just say that many problems could be resolved by referencing documentation or searching the Internet. Organizations should be diligent about maintaining a good library and giving developers time to read. After all, our Redbooks are free for download in PDF form (you can order hardcopy), and there are many excellent books out there specific to WebSphere products, thanks to the new IBM Press imprint. Web resources such as developerWorks and the WebSphere Developer Technical Journal are also free and contain a wealth of frequently updated information. Questions can often be answered quickly by IBM consultants or even other customers on the developerWorks discussion forums and on the Internet usenet newsgroups dedicated to WebSphere (ibm.software.websphere.*).
In terms of educational bang for the buck, these are all inexpensive and indispensable. Of course, this assumes you have the type of staff that is motivated to do some research. To foster this kind of environment, consider weekly developer meetings or "lunch 'n learn" sessions where participants are required (or asked) to discuss something they've read and found to be of use. Don't get me wrong, I do love visiting with customers, but the cost of an unnecessary consulting visit would be better spent on our products -- which I don't want to have the unfair (and inaccurate) reputation of requiring consulting help just to configure and use properly.
Really Try to Fix the Mess.
Many times, the problems we see in the field could have been avoided by just following even a hint of a reasonable test plan. Testing is by far the Number One shortcut taken, and in the absence of any other best practice, decent testing could usually have caught any resulting disaster before it became public. Yes, testing is expensive, but production outages can be more so. Pay me now or pay me later, don't rob Peter to pay Paul, and so on, you've heard it all before. Chapter 16 in our book presents our recommended environments and processes for testing. Also, make sure someone on your staff is responsible for acquiring and reading Performance Analysis for Java Web Sites by Stacy Joines, Ruth Willenborg, and Ken Hygh. These are some of our brightest minds on the subject, and it is the best IT book I have ever read.
Test. Just do it.
...for your consultant visit, that is. Naturally, customers want the most for their money, and we in ISSW want to provide our customers the most we can and leave them with smiles on their faces. That is all more likely to happen when a customer is really prepared for consultants to be on-site. The absence of a suitable work area, Internet access, the ability to search important internal databases for important documents, or any way to communicate with internal development and lab teams, can severely restrict a consultant's ability to solve problems fast.
Here's a small but essential checklist of deceptively obvious items to help you prepare for your next site visit so the consultants can hit the ground running:
- Arrange for the consultants you are expecting to have appropriate credentials for entering your facility so that time is not spent every day trying to get in the building.
- Make sure that the appropriate people on your staff are aware of the consultants' scheduled visit, and that they have cleared their schedule to be able to abundantly interact with them.
- Ask to communicate with the consultant(s) who will be visiting you before they come out, and make sure they are aware of the problem(s) they need to address so they can properly prepare.
- Above all: keep them busy while they are on-site!
Time is money. Make sure it's all spent wisely.
Well, I'm about out of space, and I've rambled enough. That's my list and I'm sticking to it. I'm sure I'll think about (and hear about) many more anti-practices that should be added, but let's all work on these first. When it comes time for a revision, let's hope it's a whole new list -- at least that will seem like progress!
- IBM WebSphere Deployment and Advanced Configuration, by Roland Barcia, Bill Hines, Tom Alcott, Keys Botzum
- J2EE packaging and common code, by Keys Botzum
- Performance Analysis for Java Web Sites, by Stacy Joines, Ruth Willenborg, and Ken Hygh
- Get involved in the developerWorks community, participate in developerWorks blogs.
- Browse for books on these and other technical topics.
