IBM Best Practices: Fish In a Barrel

IBM has posted a flamebait article detailing “best practices for J2EE application development”. Lists such as this can be helpful, but they’ve forgotten the simple complexity of the number of layers and complexity matching the complexity of the app. Many of the practices are good starting points, but by no means should they be rules.

The best practices

   1. Always use MVC.
   2. Apply automated unit tests and test harnesses at every layer.
   3. Develop to the specifications, not the application server.
   4. Plan for using J2EE security from Day One.
   5. Build what you know.
   6. Always use Session Facades whenever you use EJB components.
   7. Use stateless session beans instead of stateful session beans.
   8. Use container-managed transactions.
   9. Prefer JSPs as your first choice of presentation technology.
  10. When using HttpSessions, store only as much state as you need
      for the current business transaction and no more.
  11. In WebSphere, turn on dynamic caching and use the WebSphere servlet
      caching mechanism.
  12. Prefer CMP Entity beans as a first-pass solution for O/R mapping
      due to the programmer productivity benefits.

1. Always? What if I’m writing a one page app? What if all I want is a page that displays the time? There are such things as apps too simple for MVC.

2. Units tests at every layer? I’ve challenged for some time the degree to which some people suggest that you test your data access layer. Suppose you want to test a simple DAO class that retrieves an object by its id from a database using Hibernate. If that method simply calls Session.load(Class c, Object id), what are you really testing there? Hibernate? Your configuration? What database do you test against, and which values do you compare to determine success? The value/effort ratio is pretty low here.

3. The point is not to get into app server specific configuration and coding. The problem is that they use the example of J2EE security. What’s the issue? Well, in order to use J2EE security, you have to configure JAAS in a way that is app server proprietary. A good general principle, but it can’t be strictly followed.

4. A topic near and dear to my heart, security. Turn it on always? What if your app doesn’t need security? What if you need 2 factor authentication, which isn’t supported by J2EE security? Favor the use of J2EE security, yes. Always turn it on? No way.

5. Build what you know – an okay philosophy, I suppose. Basically, build your app a layer at a time instead of building it all at once. I’d say to at least fire a tracer bullet first.

6. ALWAYS use session facades with EJB components? Even if your app only has two stateless session beans? Overengineered. Refactor the session facade in later when complexity justifies it.

7. Avoid stateful session beans when possible. Fair enough – they’ve given some wiggle room here, which makes it reasonable.

8. Use container managed transactions. Fine.

9. Prefer JSPs. I actually generally agree with this. This step actually suggests that developers fight the urge to get fancy with XML/XSL when the requirements don’t justify it. Tapestry users get a pass here – though I personally find Tapestry to be a bit cumbersome, it can’t be equated with the whole XSLT to generate HTML crowd.

10. Use the HttpSession only for what you immediately need for this business transaction. The goal is noble – keep the session small so you can persist sessions and improve performance. Saying to only put info for the current transaction is a bit limiting. It seems plausible to also store general into about the application, or data about another transaction recently completed. Keeping the session small should be the actual suggestion.

11. In websphere… … turn on caching. Maybe – don’t know enough about their caching implementation to comment.

12. Prefer CMP Entity Beans for the productivity benefits. Although EJB 2.0 has made great strides, the Entity Bean model is already so cumbersome and has some limitations that make it a questionable choice at best. This is typical vendor-speak.


6 thoughts on “IBM Best Practices: Fish In a Barrel

  1. You have to understand the intended audience of that article. IBM sells primarily to large organizations. The advice is geared to those companies building complex solutions that scale to hundreds of transactions per second and thousands of simultaneous users. For systems like that the advice is generally spot on.

    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.

  2. I don’t agree with Anonymous. IBM sells to large organizations, yes. 90% of them don’t build complex solutions that scale to hundres of transactions per second….

    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.

  3. I’m in with “No one” on this – the average Websphere implementation probably doesn’t have thousands of simulataneous users.

    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.”

  4. Most interesting is how specific #7 is to WebSphere’s crap implementation of stateful session beans! On a decent appserver, #7 is simply not true, since stateful session bean failover and loadbalancing is no more difficult to implement than HttpSession failover and loadbalancing. In this case, the “J2EE Best Practice” == “WebSphere-specific workaround”.


  5. Amen. They are just trying to sell WebSphere. The article is flawed even if they had complex solutions in mind when writing it.

  6. The article is targeted at juniors. Experienced people should not follow the advice.

Comments are closed.