Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link
Hello...I just got back from a heated design review for a new application that my team is creating using Websphere. My team is fairly new using the J2EE architecture. What I was hoping for was that some experienced J2EE developers will be able to provide me with information as to what is a larger performace hit...having a Message Driven bean call individual LOCAL interface (say 3) sequentially, or having the MDB call a new() for each request on 3 helper classes. Any ideas/info/benchmarks would be greatly appeciated. [ January 10, 2003: Message edited by: roy ]
My answer: it probably doesn't matter. First Rule in Performance Tuning - Don't do it. In the grand scheme of your application the question you pose will probably have very little effect on overall performance. Program first for clarity of code and maintainability. If performance is not adequate then, and only then, should you worry about performance tuning. I am not saying program for poor performance, just don't optimize too early. Remember, your system bottlenecks will likely be in a very small percentage of your code. It is better to focus on optimizing this small bit of code (relatively speaking) then to try and optimize everything all the time. Furthermore, if you focus on writing well organized and maintainable code then it will be that much easier when you have to performance tune.
The question really should be, why do you care? You make something an EJB because it NEEDS to be, not because it's the cool thing to do. Not every object should be an EJB. If your decision is between using session beans that will ONLY be called from the MDB or session beans that will also be called from other external clients through a remote or local interface, then I would say that you should only use a session bean in the second case. Also, why must it be either or -- again you should probably only use Session beans as Session Facades anyway -- that means that the choice of using a helper class underlying the Session bean or the Session bean can be deferred as far as you need it -- the only time you would add a Session bean would be in those cases where you need to specify different or additional transactional or security attributes. Now, if the decision is whether to do DAO's vs. Entity beans -- well, that's another discussion entirely... Kyle
roy, Thanks for joining JavaRanch, but could you just take a quick look at the naming policy and edit your profile. Also, only members with valid names will be eligible for the book giveaways. Thanks Simon Bartender (moderator) of "J2EE and EJB" forum
I’m tired of walking, and will rest for a minute and grow some wheels. This is the promise of this tiny ad:
Free, earth friendly heat - from the CodeRanch trailboss