As stated, items 2, 3, 4, 5, 7, 10, and 12 are debatable – their validity depends heavily on the nature of the application – you could readily find high-volume apps and highly effective, disciplined developers to make cases for and against them. 11 is a Websphere best practice, not J2EE in general. 1 and 6 are valid for apps of medium or higher complexity in their respective tiers. While I agree with 9, there are plenty of brilliant developers who would respectfully disagree. Really, 8 is the most agreeable of the bunch. 3, if re-explained, has solid validity as well.

Many of the points could have been more valid given less absolute terms. For example, #4 could more properly been stated, “When security is needed, favor the use of J2EE Security.”

We used to use Websphere. We had a very small app that found a bug in Websphere. We paid for a consultant who told us we should have used EJB’s, etc. (follow the 12 rules above). This application had 10 concurrent users and maybe 100 total. It all ran on one box (except the database). We switched the app to tomcat and it worked great and saved us quite a bit of money.

No, my friend, IBM is trying to sell Websphere. Period.

Obviously if you are building a “one page application” the advice is a bit over the top, but if that were the case you likely wouldn’t be reading, nor care, about IBM’s best practices for J2EE application development.

The article was written by some excellent IBMers. The practices offered are a result of seeing countless situations where the offered advice was not followed and customers were sizzling in the fry pan trying to work in the advice after the fact.

Context my friend. You’ve taken much of the article out of context which makes your post closer to flamebait than the article itself.