Interview with Rod Johnson on J2EE Design and Development

Home

News: Interview with Rod Johnson on J2EE Design and Development

  1. In this interview Rod Johnson looks at some of the deficiencies of the J2EE spec, how the spec has been hindered and helped by Sun, and the importance of third-party and open source frameworks to the advancement of the J2EE community. He gives his opinion on everything from EJB to .NET, and provides his thoughts on J2EE 1.4 and Aspect Oriented Programming (AOP).

    Click here to read 'An Interview with Rod Johnson'

    A chapter excerpt from Rod Johnson's book, 'Expert One-on-One J2EE Design and Development' has also been provided:

    'Chapter 4 Design Techniques and Coding Standards for J2EE Projects'

    Threaded Messages (124)

  2. The book[ Go to top ]

    Rod, I've seriously considered buying your book, but it's not any longer available in Germany. Maybe they will produce new copies. Sorry ...
  3. Availability of book[ Go to top ]

    Lars, Thanks for the info. I've made Wrox aware of the problem. Hopefully they will be able to sort it out.

    Regards,
    Rod
  4. EBook?[ Go to top ]

    I find the book helpful but carrying the bulky book is not an option for me.

    I look forward to the day when I can have rights to a softcopy version of the book that I own.

    I wish this book shipped with a CD that contained the e-book version of it. This is something many authors ignore it for their own benefit.

    Just like you have rights to rip the audio CD's you own and carry it with you.

    Is there a e-book version available for this one?
  5. Availability of book[ Go to top ]

    Hi Rod,

    That's the same case in India too.
    There are many J2EE developers, architects who would like to read your book seriously.
    Kindly have a look on the availabilty of the book in India too.

    Regards,
    -ShriKant
  6. Availability of book in India[ Go to top ]

    ShriKant,

    Will raise this with Wrox and let you know their plans.

    Regards,
    Rod
  7. Bought the book - hope it helps[ Go to top ]

    Over here in the UK, we are only just getting into J2EE on an Enterprise scale. I've been looking at this book, wondering if I should buy it for the company library. The sample chapter convinced me and I now await its arrival from Amazon.
    I hope it'll help us in our quest for a J2EE solution that will work, perform, be scalable etc etc etc.
    Perhaps I'll let you know in a few months !!

    PJ
  8. Bought the book - hope it helps[ Go to top ]

    Over here in the UK, we are only just getting into J2EE

    > on an Enterprise scale.

    Really?
  9. Bought the book - hope it helps[ Go to top ]

    Trust me, it will be worth it...
    It an easy to read book, full of helpful info, advance J2EE programmers will see a lot of ideas that they already use, but new J2EE programmers will learn to do things the right way...
    Its a great book to have at a company, sometimes to proof that what your doing is backup by J2EE author....
  10. Bought the book - hope it helps[ Go to top ]

    <quote>
    Over here in the UK, we are only just getting into J2EE on an Enterprise scale.
    </quote>

    Speak for yourself.
    We've been doing it on an enterprise scale (in the UK) for quite a while now...
  11. ok ok ok[ Go to top ]

    More.... compared to the U.S., I suspect that the UK is behind in its adaption of J2EE for Enterprise applications. The vast majority still don't use it, but its getting there. It's a generalisation, theres not a "massive" amount of J2EE work going on the UK when compared to everything else. Anyway, back to the technical discussion.....
  12. UK adoption[ Go to top ]

    Actually, I gained a lot of the experience behind the book in the UK, working with the latest J2EE specifications at the time.

    Rod
  13. EJB = FUBAR[ Go to top ]

    You can read some other threads and find that EJB should not be used in J2EE for persistance (EJB should only be used for Corba).
    DAO are much better, clients that use EJB go to m$ .NET.
    Note Sun going to $2 range, big part of it is EJB.

    Also design patterns are over rated.


    If I can save one client to not go to .NET via EJB, here is what you can find on google on EJB, to make you void them
    Please use J2EE! Please use DAO:

    http://www.freeroller.net/page/ara_e/20021214

    http://www.softwarereality.com/programming/ejb/EJB_101Damnations.pdf

    http://radio.weblogs.com/0107789/stories/2002/05/24/isEjbAlwaysNecessary.html

    http://www.tallsoftware.com/dotnet/Java%20to%20J2EE%20to%20oblivion.pdf

    http://www.mail-archive.com/general%40jakarta.apache.org/msg03376.html

    .V
  14. EJB = FUBAR[ Go to top ]

    Is there any opensource, production-ready DAO implementations ?

    I havent seen any.

    For EJB there is an excellent choice - JBoss.
  15. DAO Opensource[ Go to top ]

    Maris Orbidans,

    Ibatis.com,
    basicPortal.sf.net
    www.jlco.org

    and usefull to write one w/ is Jakarta's CommonsSQL.

    All above have Open Source DAO, but there is no Standard DAO interfaces.
    It would be usefull, so one could switch from JDO, to EJB, to RowSet, to etc.

    .V
  16. fantastic interview[ Go to top ]

    Thanks for your insightful comments, Rod. I don't work in J2EE anymore but if I did I'd pick up your book in a heartbeat, and will definitely recommend it to friends. This interview displayed a clarity of thought uncommon on TheServerSide.com (no offense to anyone), more like an Artima interview.

    Rod, do you have a weblog?
  17. Rod,

    I am a developer of over 11 years and have been developing OO systems for the past 8. I am relatively new the J2EE community and I am taken back the number of perspectives in the community of those who think in the box provided to them by design patterns and the J2EE specification. I am further amazed how this can be talked about with an attitude of superiority.

    Every problem is not resolved by a boxed solution and many solutions for a problem could be improved for a specific scenario or requirement. Design patterns are good but they do not fit every requirement. In some cases a Design Pattern can also be applied as an inspiration. The real goal should be to look at the problem at hand and develop the best solution based on the requirements. Find the patterns that fit and adapt those that do not. The focus should be on loose coupling, modularity and performance however that is achieved.

    You seem to have an understanding of this and do not get caught up with an in the box thinking. You show some practical intelligence, which is rare in this world. Hats off to you.

    My only disagreement, or it might be a misunderstanding, is on your comments on over engineering. If by this you mean using EJB or Entity Beans when they are not needed I agree. If by this you mean a complex system to solve complex problems I disagree.

    Loose coupling, modularity and performance require a more complex solution to effectively work. It is my experience that complex solutions require a lot of engineering to allow adaptability. The reality is that change is a constant. When this is ignored the life cycle is cut short. We are here to solve business problem and so many lose site of that.

    I agree that most systems should not be database independent. I only think this is true at the persistence layer. The domain and business logic certainly should be independent of any persistence. Segregation is crucial to allow this and it always takes more work. Extreme programming seems to focus on short-term goals. I have spent a lot of time on project where the simple solution for now is chosen and that has always caused me big headaches later on. Especially when the software is becoming a ball of mud it is over 500,000 lines of code and needs to be redesigned and the managers do not want to pay for it (they never do).

    Over all I would say that you have a fan and I will be sure to purchase your book.

    Best regards,

    Jason Sacks
  18. Jason,

    Thanks for the kind words.

    "My only disagreement, or it might be a misunderstanding, is on your comments on over engineering. If by this you mean using EJB or Entity Beans when they are not needed I agree. If by this you mean a complex system to solve complex problems I disagree."

    Sure, I accept that complex problems aren't always amenable to simple solutions. (I'm working on one now.) But I think we should strive to find the simplest possible solution. A lot of J2EE projects begin with developers assuming that the problem is a lot more complex than it really is.

    Einstein put it better than I can: "Make everything as simple as possible, but not simpler". While I'm not an XP zealot, I think the XP approach of doing "the simplest thing that can possibly work" is extremely valuable in J2EE.

    Regards,
    Rod
  19. Persistent State Service[ Go to top ]

    Hi,
        Some years ago , OMG has defined a CorbaService called Persistent State Service. This service defines a specific language to describe persistent structures called PSDL. More details in specification at http://www.omg.org/cgi-bin/doc?formal/2002-09-06.
        I think that this is a interesting approach to the persistence problem : a way to define how objects will persist independant from programming language, datastore and implementation .


    Leonardo
  20. Persistent State Service[ Go to top ]

    OMG has defined a big bunch of services (CORBA has a lot of them)
    However almost noone uses all that stuff.

    J2EE has a tendency to steer in the same direction a bit.

    Real world needs cost effective, practical solutions.
  21. Since a lot of discussions about why Rod is right, which I agree with the most. Here I throw my 1 cent opinions about why Rod is not right, or is not accurate on some aspects of J2EE.

    As an arechect of J2EE project and have been developed quite a few big projects using J2EE, I definitly would echo Rod's point regarding to Entity Bean if it was a year ago when I was using BMP, and did not quite exactly get what Entity Bean meant to be used. A lot of frustrations about Entity Bean came from the BMP which has by nature bad performance (By the way, I agree with Rod, Fat Key patten is a hack, reason being that a pattern should work on all J2EE container and a hack may not work due to some implemetations of J2EE container, and Fat Key pattern is the latter) and using commit option B or C. The accurate assesment of Entity Bean, I believe, is that instead of throwing Entity Bean out of window, it is a good choice to use Entity Bean (CMP of course) if you repeatively access them and the update only comes from container (using commit option A) to take full advantage of caching.

    Also, we should not view EJB container as only a distributed computing platform. First, it an application server. Remote calls are the only one way to invoke EJB. As matter of fact, for all J2EE web applications which account most of the J2EE projects, only local inteface should be used and hence all parameters are passed by reference. That should be the most use cases for EJB envocation, Not RMI. That is why I don't necessarily agree Rod's point that web service is the way to go 'cuase that is only for remote calls and that should not be the primary usage of EJB container and I don't think distributed computing model is a model for performance anyway, rather a model for robustness.

    Regards,

    Xiaolong Hao
  22. Thanks for your comments. I agree that if you want to use entity beans, CMP is the only way to go. With rare exceptions, BMP is bad. Bad for maintainability, bad for performance.

    Yes, CMP will perform well if you get a lot of mileage out of caching. But so will JDO, TopLink or any other O/R mapping solution. This is an argument for O/R mapping, not specifically for CMP entity beans. And it's dangerous to assume that you always *will* be able to benefit significantly from caching.

    Sure, EJBs with local interfaces are a big advance in EJB 2.0. In chapter 1 I advocate using them for session beans as well as entity beans, where distribution isn't an issue.

    My reservations about EJB usage is that when you take away the necessity of remote access, the EJB value proposition doesn't look so attractive. I would much rather use an AOP approach (when a production-quality one is available) than local EJBs in such cases, as it will be much lighter weight. A lot of the complexity of EJB--such as class loading complexity, greater complexity of testing--remains even with local interfaces.

    Regards,
    Rod
  23. Rod,
    The interview made good read and you showed
    the guts to come out in open and say there
    are some obvious "J2EE WORST PRACTICES" which, the
    developer community needs to shrug off ! I really
    appreciate that bold move.
     It's a common notion among developers that without EJBs ,a J2EE application is not complete ! Having developed numerous J2EE applications over the past 4 years,
    I can definitely say that it has mostly been a 'trend' to use EJBs in projects rather than the need for using them driven by business reasons. It's definitely an overused technology.

      Having said this , I cannot fully agree with you saying that EJB doesn't offer much value proposition when the "remote" aspect of that is taken off . It does offer
     the advantages of leveraging the out of the box services offered by the EJB containers when used in the "right way" and for the "right reason". So ,the bottom line is that
    the rationale behind the usage of EJBs (for that matter, any technology) should be "business(requirement) driven" than "trend driven". Also, a true architect should be
    open and accommodative enough to suggest and stand with
    the "simple and best way of doing things" than bringing
    in unnecessary complexity in an attempt to showcase his/her
    grasp of the so-called cutting-edge technologies.

    Sony.
  24. Sony,

    We agree about the importance of being business, rather than technology, driven. This is a point I really try to bring out in the book.

    Regarding EJB, I said that the value proposition of EJB is "less attractive", not nonexistent, when you take remoting out of the equation. You're left with a set of tradeoffs to evaluate case by case. For example:

    On the positive side:
    - "out of the box services offered by the EJB container" such as CMT, declarative security, thread management. Yes, these are valuable. But they're not always all needed--for example, EJB security isn't used that often (although it's good that it's an option). Also, the EJB approach to multithreading--maintain a pool and lock the entire instance--is a bit heavyhanded. Sometimes it's better just to synchronize methods if necessary. After all that's what we need to do in Servlets/struts actions etc.

    CMT is the biggest value proposition of EJB at present, besides remoting, as I say in the book. This is where I see AOP offering value. An AOP interceptor could provide declarative tx management. In fact it could be more flexible than EJB provides. (E.g. don't like having to call setRollbackOnly() on an application exception and would like the EJB container to rollback automatically on MyVeryBadException? Sorry, can't do it with EJB.)

    On the negative side, EJBs bring:
    - greater class loading complexity
    - application is harder to test
    - deployment is more complex
    - home/local/ejb implementation class
    - having to look the bean up via JNDI
    - EJB programming restrictions
    ...

    I discuss this tradeoff in Chapter 1.

    Regards,
    Rod
  25. Rod,
    Thanks for your comments.I do agree with you on that.
    Let me check the availability of your book in India
    and I'm determined to dig deep into AOP and other areas
    mentioned in the book.

    Sony.
  26. Rod,

    Great book and thanks for inspiring the most interesting discussion thread that I have seen here on the ServerSide.

    <Rod>
    Sure, EJBs with local interfaces are a big advance in EJB 2.0. In chapter 1 I advocate using them for session beans as well as entity beans, where distribution isn't an issue.
    </Rod>

    To me the local interfaces are a hack to get any kind of decent performance out of a EJB system, and I am wondering how this will be looked upon a year from now. I think we will look back at 2-3 years of J2EE/EJB development, and I fear that we will start rewriting the majority of these applications for a new AOP based or webservices based framework. With the evolution of the specifications and the patterns, there certainly has not been a single strategy for developing J2EE system that has had a life span of more than a year or so yet. These are enterprise level systems and whoever pays for this development will most likely start questioning the choice of J2EE based on this.

    In my opinion the only EJB architecture solution that has a chance to survive more than a few years is one based on Statless Session Beans with either remote interfaces or a webservices front. EJBs are part of a distributed architecture and that is how we should use them. Avoid what does not perform well - Entity Beans. Also avoid local intefaces since - like you said <
    Just my 2 cents.

    Regards,

    Thomas Risberg
  27. The last part of my previous post seems to be missing:

    - like you said "My reservations about EJB usage is that when you take away the necessity of remote access, the EJB value proposition doesn't look so attractive. " The only usage of local interfaces that I think makes sense is if you already have a system built using EJBs, and you have to make it perform better without rewriting the entire system.

    Thomas Risberg
  28. <thomas>
    I think we will look back at 2-3 years of J2EE/EJB development, and I fear that we will start rewriting the majority of these applications for a new AOP based or webservices based framework.
    </thomas>

    I'm afraid you're right. However, as you say, those systems built with SLSBs will probably survive for the foreseeable future. I predict that in 5 years, at the most, EJB will be a "legacy" technology, unless EJB radically reinvents itself. Local interfaces and web service endpoints (2.1 spec) are substantial changes, but most of the negatives still remain and I don't think Sun will be prepared for a more radical rethink.

    I'm not sure I agree that local interfaces are a hack, though. They were a hack when applied to entity beans, which really shouldn't be EJBs at all in most cases, but they can make sense to leverage container services in session beans in collocated applications.

    Regards,
    Rod
  29. <Rod>
    I predict that in 5 years, at the most, EJB will be a "legacy" technology, unless EJB radically reinvents itself. Local interfaces and web service endpoints (2.1 spec) are substantial changes, but most of the negatives still remain and I don't think Sun will be prepared for a more radical rethink.
    </Rod>

    How do you see this whole thing to evolve and play out in the next several years? Currently I see the following counter-balancing forces in the EJB/JDO/O-R mapping space:

    1. Sun has no intention to deprecate the EJB spec and incorporate JDO into J2EE anytime soon.
    2. Oracle and IBM have publically stated they would not implement the JDO spec.
    3. We haven't heard any plan from BEA or JBoss to support JDO.
    4. The JDO vendors and traditional O-R mapping vendors don't see eye-to-eye with each other.
    5. Commercial and OpenSource O-R vendors don't agree with each other either.

    EJB remains the only universally-accepted spec, albeit all the performance problems associated with entity beans. However, I do see a lot of recent interest on OSS O-R frameworks like Hibernate, for small to medium scale J2EE projects. Maybe this is the force that would eventually topple entity beans? Only time can tell.
  30. Hi PPL,

    Most people I've spoken to (even the ones that have never used EJB CMP2.0 entities at all!?!) complain that EJB CMP 2.0 entities are slow (because I guess that is the most "fashionable" stance to take nowadays...). I don't have any experience with EJB CMP 2.0 Entities in production (just a few prototypes apps on my dev box as I am currently learning/experimenting with the technology). So I pose a question:

    Has anybody used EJB CMP2.0 Entities, with CMR, etc(properly - if you like i.e. local interfaces behind a session facade, etc) in "production" where the performance has been so "unbearably" slow (i.e. didn't meet sponsor requirements) that they had to be abandoned? If so why do you think they weren't up to scratch and what did you use to replace them?

    Remember I'm not really asking the question about their "complexity", and the other problems; JVM co-location, etc (just speed) as most mordern IDEs help us to manage this to a large extent.


    Cheers in advance

    Smythe
  31. IDEs help us manage the complexity i meant...
  32. Eric,

    OK, this is taxing my crystal ball but here's my best guess.

    Firstly, I wasn't purely referring to entity beans vs JDO, but EJB as a whole. Whether or not JDO succeeds is another question: it's just one challenger to the EJB persistence solution.

    I think there's now an opportunity for successful open source projects (such as Hibernate) to make an impression. I think the days when Sun handed down specs from on high are past, because some of the specs are failing to meet real business needs. Also, disasters like the Pet Store performance fiasco and the challenge from .NET will prompt a rethink in the J2EE community, if not at Sun. So I see more community input--not necessarily through the JCP--into how the technology evolves in practice.

    I think the big question is whether one or more viable AOP solutions emerge from the community (or commercial vendors, although I think they'll try to push EJB as long as it makes business sense). If AOP solutions deliver the kind of value I believe they can, people will choose to use them for an increasing number of applications in place of EJB. Ideally a standard may emerge, with agreement on a few basics such as a common Interceptor interface. Standardization is good, but I think there is a value in standards emerging from successful solutions, rather than standards being defined before any road-tested implementations, as tends to happen with the JCP. Otherwise there's a danger that standard solutions don't work well in practice, or that they are a lowest common denominator that stifles innovation and superior existing solutions. (Consider data access in WebObjects vs entity beans, for example.)

    JSR-175 (metadata attributes) will provide a superior way forward for many things that EJB deployment descriptors currently address. While it's unlikely that the EJB spec will be modified to recognize this, the community will recognize it. .NET already uses this approach successfully. Other J2SE enhancements such as better threading libraries will also encroach onto the territory of EJB, offering more choice.

    This leaves a whole range of things in which J2EE standardization will continue to be invaluable: JTA, JNDI etc.

    Regards,
    Rod
  33. AOP and your Spring Framework[ Go to top ]

    Rod, thanks for the valuable insight. AOP has been the latest hot terminology and I am very curious about it. Can you provide a hyperlink for an introduction to AOP with respect to server-side Java? Also, you just started the new SpringFramework project at SourceForge. Part of it is a JDBC abstraction layer. Are you trying to provide a 3rd alternative to entity beans beside JDO and O-R mapping tools?
  34. AOP and your Spring Framework[ Go to top ]

    I wish I know of a good site for an overview of AOP, but I don't.

    The AspectJ web site has a good overview of AOP goals, although of course AspectJ is a different approach to the dynamic proxy based approach I prefer. It is really interesting to download and play with AspectJ, though.

    Richard Oberg's log had some excellent stuff on AOP late last year, although he's spent more time discussing international politics lately.

    Jon Tirsen's Nanning project on SourceForge is an AOP implementation.

    Spring also has some experimental AOP packages you might want to check out. Currently the goal is to get to a 1.0 release ASAP, but after that a lightweight AOP implementation will be a major focus.

    Regards,
    Rod
  35. Spring Framework[ Go to top ]

    The Spring Framework on SourceForge contains the infrastructure code discussed in the book. Lots of readers were keen to use this in production, and several volunteered to contribute, so it's now a true open source project under the Apache license.

    Spring includes a JavaBeans-based configuration mechanism which I discuss in the book and which I've found to be very powerful in practice. Also convenience classes for implementing and accessing EJBs, and an MVC web application framework. The infrastructure is layered, so it's possible to choose which bits to use without pulling in the whole thing.

    As you say it also includes the lightweight JDBC abstraction layer discussed in chapter 9 of the book. This abstracts away the try/catch/finally nightmare (connections etc will always be closed) and replaces SQLException with a meaningful hierarchy of exceptions such as CouldNotConnectException and DataIntegrityViolationException. The exception hierarchy is not JDBC-specific (although there are JDBC-specific subclasses). Translation from SQLExceptions to this hierarchy is performed by a pluggable implementation of a simple SqlExceptionTranslator interface. For example, an Oracle implementation can look at the vendor error code: no more need to check SQLState codes.

    The aim of this framework is to ensure that, in those cases where it's appropriate to use JDBC, using JDBC isn't error-prone and is more elegant than using the API directly. It is not an O/R mapping layer, and so not directly a competitor to JDO or comparable solutions. It just helps to make JDBC a viable solution in the many cases when O/R mapping isn't appropriate.

    After the 1.0 release, a major focus of Spring will be a very lightweight AOP solution. This will attempt to address common problems such as declarative transaction management without the need for a monolithic container.

    We're currently looking for contributors: TSS readers who want to contribute, please check out the SourceForge spring-developer list, check out CVS and mail the list if you would like to help!

    Regards,
    Rod
  36. Checked exceptions[ Go to top ]

    Hi,
    On page 127 in your book you have a list of guidelines for choosing between checked and unchecked exceptions. The first one mentions to throw a checked exception if the exception is essentially a second return value for the method.

    My question is wether it is wise to throw an exception in this case at all? Since the exception handling mechanism in Java is known to have a significant overhead, many developers believe that it should only be thrown when something that should not have occured did occur (something horrible wrong as you state it) and that in other cases it is better to detect the error in other ways.

    I know you wrote about this in your book, but I was wondering what you think about the overhead for using exceptions (for performance reasons) when it really is just another business rule you are implementing when you catch the exception.

    Thanks for sharing your knowledge in this thread.
  37. Checked exceptions[ Go to top ]

    I think an alternative return value is an idiomatic use of checked exceptions in Java. This allows the effective return of a completely different object in scenarios that must be handled by business logic in the caller.

    The overhead of catching exceptions will vary with JVM. In some JVMs, it's as cheap to catch an ArrayIndexOutOfBoundsException as to use a proper loop (although of course this is not good programming practice).

    But in cases where business logic is involved, performance isn't normally a consideration. As I stress in the book, it's important to avoid unnecessary optimizations. In a deeply nested loop, it might make sense to be wary of exception handling. In the signature of a business method, the performance of the necessary exception handling is a non-issue.

    Regards,
    Rod
  38. J2EE Design and Development book[ Go to top ]

    Rod,

    Excellent book. I agree with you about 99% of the time--especially your passages about unnecessary complexity in J2EE design patterns (entity beans in particular), checked exceptions, and over-optimization. And I'm in complete accord with your observation that good OOP principles should generally trump implementing "cool" J2EE technologies.

    My company has completely bought into applying the entity bean model for just about every project--in the name of "consistency". The trite quotation "A foolish consistency is the hobgoblin of little minds" leaps to my mind...

    Anyway, I'm really enjoying reading your book. Hopefully I'll be able to avoid some of the bad patterns you lay out in your book.

    -Jeff
  39. Everyone,

    All I can say is that Rod's book brings much more than any other J2EE book there is currently. Definitely the best book around in the area. One of the first books that looks at J2EE from the real-life business requirements viewpoint, dispassionate, with a fair criticism of J2EE's failures, usual bad habits and constructive comments about how to use J2EE effectively to build quality applications that work, that are performant, that are maintainable.

    And the accompanying framework is simply fantastic. I can only strongly suggest that every serious programmer around gets into it (you can download it from the Wrox site starting from http://p2p.wrox.com/list.asp?list=expertj2ee_with_rodjohnson). Rod's approach to JDBC, MVC and JavaBeans is really a step forward in terms of development comfort. Just go for it (good for programmers, designers, architects), the book and the framework are invaluable...

    All in my opinion of course, but seriously, trust me... I rarely recommend things so wholeheartedly. It's actually the only time. :)

                    Yann
  40. I absolutely agree with Yann - Rod's book is the best book on J2EE book that I know of! I have read it cover to cover in just a couple of days. The clean and unbiased approach is amazing. I have already shared many of Rod's views before reading the book, but it has unquestionably deepened my understanding of many J2EE issues. I consider it a the best effort of consolidation yet, in terms of the uncontrolled growth of J2EE hypes and propaganda. It's not a technology showcase but a practical handbook, and not tied to any current hype.

    Now concerning the most interesting part of it: Rod's framework, currently dubbed "I21 framework" but probably soon to become "Spring framework" at the time of its open source release. More info on these plans is available at the Wrox discussion forum for the book, Yann has already mentioned the URL. A really slick and sophisticated framework with well thought out design decisions, this has to be emphasized in the face of some mediocre but very popular frameworks around. I guess nothing is perfect, but IMHO the J2EE world has not seen that kind of application framework yet.

    To paraphrase Yann: There are few things in the Java/J2EE world that I recommend so wholeheartedly, just... IntelliJ IDEA, Caucho's Resin, Bruce Eckel's "Thinking in Java", and Rod's book and framework :-)

    Juergen
  41. Rod's JDBC Framework[ Go to top ]

    Rod,
        I brought the book 2 months back. I have not read all the chapters. But I have read the Several Chapters serval times !! It's a great book.

        I have adapted the callbackhandler and ExceptionTranslator into my current project. And I loved them.

        But I also felt that some of the API signitures could made even simpler, i.e. instead of using
        
    void query(PreparedStatementCreator psc, RowCallBackHandler callBackHandler) throws DataAccessException;

    One can use

    void query(String sql, Object[] parameters, RowCallBackHandler callBackHandler) throws DataAccessException;

    The parameters are simply values to be bind.

    For example:
    if
      String sql = "SELECT login from USER where last_name = ? and first_name = ? ";

      Object[] parameters = new Object[] { 'chen', 'chester' };

    In this way, the code that performs query would not even need to bind the variable at all. query() would use PreparedStatment's setObject() API to bind the parameters.

    Similarly for

    update(String sql, Object[] parameters) throws DataAccessException;


    I would not use update() function for multiple sqls as suggested in the book.

    I would use BatchUpdate instead of Update as it would help to reduce network traffic and reduce number of commits (which help performance in Oracle as well).

    I fact, I adopted some ideas from Floyd's Data Access Pattern (but not use Java Bean) and a lot of ideas from Rod's book and mixed them up.

    So I have a BaseQueryCommand, BaseUpdateCommand, BaseBatchUpdateCommand,and BaseStoredProcQueryCmd and BaseStoredProcBatchUpdateCmd.


    Just my two cents.


    Chester
  42. Rod's JDBC Framework[ Go to top ]

    Chester,

    If you are interested in making Rod's framework better, please join Wrox' site and do not hesitate to contribute. His framework is about to be open-sourced (the "Spring Framework" so far) and any contribution is welcome!

    Simply go to http://p2p.wrox.com/list.asp?list=expertj2ee_with_rodjohnson

                    Yann
  43. In just a couple of days ?[ Go to top ]

    Juergen,

    "I have read it cover to cover in just a couple of days."

    Get a life! :)

                    Yann
  44. AOP is the future...[ Go to top ]

    Rod,

    I wholeheartedly agree with you that AOP is a very exciting prospect, especially for server-side development. IMHO AOP frameworks with plug-in style services such as transaction management, security, persistence, etc. provided as aspects are definitely the way forward.

    <Rod>
    However, this doesn't mean that it will be widely adopted. ... I find that people get very worried and defensive when I suggest that there is very little that can be done with EJB that couldn't be done better with AOP.
    </Rod>

    This is one of many articles I have read where there has been an air of pessimism about the potential take-up of AOP. I have also heard a few potential barriers to adoption touted:
    1. None of the major app server vendors have plans (that they have publicised) to go the AOP framework route any time in the near future and the vast majority of large companies seem disinclined to source products from anyone else.
    2. J2EE has gathered a lot of momentum with lots of app server installations out there. Companies will be reluctant to move to something new and unproven.
    3. Fear of the unknown – just the name “AOP” seems enough to inspire fear in some developers, perhaps because AOP sounds like it will require the same sort of paradigm shift that moving from procedural programming to OO involved.
    4. EJB (and the app servers they run on) required a fair amount of effort to learn. There will understandably be reluctance among some developers to ditch this and have to expend more effort learning something new.

    However, I am inclined to think that if these AOP frameworks can deliver the kind of productivity and maintenance improvements that they promise then these technologies will prove irresistible to companies and developers alike. If there is sufficient demand the major app server vendors will be forced to adapt their products to include an AOP interface into their services. As far as developers are concerned it has been my experience that the best developers have an innate curiosity and love to learn the latest and most exciting technologies, especially if they feel it will make them more productive and allow them to program more elegantly...

    Regards,
    Gavin
  45. AOP is the future...[ Go to top ]

    <gavin>
    1. None of the major app server vendors have plans (that they have publicised) to go the AOP framework route any time in the near future and the vast majority of large companies seem disinclined to source products from anyone else.
    </gavin>

    Hi Gavin - you're comment is somewhat inaccurate, JBoss is going heavily in the AOP direction, _and_ they are publicising it.
    How are you defining "major"?
  46. AOP is the future...[ Go to top ]

    Tim,

    No disrespect to Jboss (in fact I think it is a great product and I am keenly anticipating the release of JBoss 4), but it is my impression from the various market share reports and job-site advertisement breakdowns that I have seen that JBoss doesn't yet seem to have the mainstream acceptance it deserves...

    Regards,
    Gavin
  47. Stored Procedures[ Go to top ]

    Rod,

    <Rod>
    Many J2EE developers are too inflexible in pursuing what they regard as being prescribed design patterns, even if they produce poor outcomes. For example, many J2EE developers won't consider using stored procedures, regardless of their potential benefits in a particular case. ... We need to approach problems with an open mind, and should be prepared to use the simplest and most efficient approach.
    </Rod>

    Whilst I agree that stored procedures can be useful in some situations, I would certainly want to think carefully about the implications before using them. For a start they either require Java developers to be proficient in an additional language (PL-SQL, Transact-SQL, etc), or for DBAs to take on a development role. Secondly, using stored procedures means that you have business logic code outside the middle-tier, which will complicate code management and maintenance. Finally, there is also the issue of portability (although I grant you that I have yet to see a database port in the real world...). I think you are right that we need to approach problems with an open mind and that we should be prepared to use the simplest and most efficient approach, however, I would add that this should not be at the expense of maintainability.

    Regards,
    Gavin
  48. Stored Procedures[ Go to top ]

    Having read some of Rob's book (haven't read the whole thing yet but so far its fantastic), he states, i believe, in using stored procedures NOT for business logic, but rather use them to fully utilize the power of a moderm database system which complements an application in the best way possible. I think most people would agree that as well and in the real world is what makes sense.
  49. Stored Procedures[ Go to top ]

    John,

    I was not suggesting that stored procedures should never be used. I was just advising caution to those that haven't yet read Rod's book and might get the wrong impression from comments he made in his interview. As you say Rod quite clearly states in his book that stored procedures should not be used for business logic.

    I agree with Rod and you - I see no problem in using stored procedures or views to provide access to data. However, I would suggest that there is a fairly blurred line between where persistence/data manipulation ends and business logic begins. If you retrieve a value via a stored procedure from a database, and this value is the result of a series of complex calculations on data from base tables, would you consider this "business logic"? I think many people would.

    I agree with Rod that if you are pulling numerous items of data from the database just to perform aggregate functions on it in the J2EE server point then you are probably much better of performing this aggregation on the database. However, I would be a lot more wary about using stored procedures to perform further calculations on this aggregated data - I feel this would more correectly be performed on the middle tier.

    Also, I am not so sure I agree with Rod's point "Stored procedures can handle updates spanning multiple database tables. Such updates are problematic with O/R mapping" - I would say try your damnedest to find an O/R mapping tool that can accommodate your requirements before going down this road. It seems strange to me that Rod has a problem with "using EJB with remote interfaces" because it "may hamper practicing OO design” but then suggests this totally non-OO persistence approach...

    I have to agree with you that Rod's book makes for a very interesting read even though I have found myself disagreeing with him occasionally!

    Regards,
    Gavin
  50. Stored Procedures[ Go to top ]

    Gavin,

    Agreed. There is a fine line like you so stated. And that line I find is where experience and a good relationship with the DBA come into play in order to create a solution that fullfills the business and application needs and hopefulyl takes advantage of what a database engine can offer.

    John
  51. You stated on page 156 of the book (page 46 of PDF) that using a StringBuffer is more efficient than concatenating Strings. This is only true when dealing with loops. One big concatenation of a bunch of String's is just as fast as using a StringBuffer, because it's automatically converted by Java to a StringBuffer.

    In fact, in your particular example, using a StringBuffer is slower, because you were concatenating Strings within your calls to append().

    Chris McMahon
  52. Stored Procedures[ Go to top ]

    <Rod>
    For example, many J2EE developers won't consider using stored procedures, regardless of their potential benefits in a particular case. ... We need to approach problems with an open mind, and should be prepared to use the simplest and most efficient approach.
    </Rod>

    A product I worked with had a lot of logic built into stored procedured and triggers. And it was written in 7.x.x something and the product vendor got stuck with that version. The stored procedures and triggers would have to be re-written and tested with later versions of the database. They were finally migrated the product to 8.x when oracle stopped supporting the database version they were using. i don't call myself a j2ee developer but I would use stored procedures only as last resort.


    -Aditya
  53. Stored Procedures[ Go to top ]

    <Rod>
    For example, many J2EE developers won't consider using stored procedures, regardless of their potential benefits in a particular case. ... We need to approach problems with an open mind, and should be prepared to use the simplest and most efficient approach.
    </Rod>

    On the other hand, I have seen software where all business logic is written in PLSQL.

    Data changes and migration screwed up all stored procedures very often. With error message like "Exact fetch returns more than requested rows".

    Maris
  54. Stored Procedures[ Go to top ]

    Maris,

    I know an actual example of such a PL/SQL-intense system, too... quite a large project, with quite frustrated developers that have to maintain it. But that's the other extreme, and extremes are never ideal. I agree with Rod that considering stored procedures for certain cases is fine, although I tend stick to standard SQL as far as possible.

    BTW, the above mentioned system is an Oracle Portal installation serving the corporate group portal of a major Austrian company. Guess who decided to buy Oracle Portal, the management or the developers that have to work with it?

    Juergen
  55. Practical intelligence[ Go to top ]

    This is the first, nay, the *only* time I have seen such an unanimous praise for a book here in TSS which normally can not agree on the color of an Orange..Can only congratulate..

    I have not read the whole book (I will as soon as possible), but I read the sample Chapter, the interview and other posts you have made, and I feel like somebody coming out in the sun after hundreds of years in the shadow. For a while I thought am I was totally nuts. Now I know that it was not me who was temporally blocked.

    Jason Said:
    "You show some practical intelligence, which is rare in this world. Hats off to you, you have a fan"

    Count me in too.

    Regards
    Rolf Tollerud
  56. Use of EJBs[ Go to top ]

    <Rod>
    There seems to have been a real backlash against EJB in the last year. In my book, I've tried to get past the rhetoric of the "EJBs are great" and "EJBs are evil" schools of thought and take a dispassionate look at the strengths and weaknesses of EJBs.
    </Rod>

    When I read the book I thought I detected a quite strong anti-EJB bias... I take Rod's point that not every application needs to be “distributed” (BTW it would have been nice to have had a clear definition of what Rod meant by a distributed application at the beginning of the book - but my understanding is that by “distributed” he means any application where the business components are not co-located with the web-app). However, I think it is slightly unfair to say that “using EJB with remote interfaces may hamper practicing OO design”, and that many J2EE patterns (e.g. Session Façade, EJB Command, Data Transfer Object) “are workarounds for problems that are introduced by using EJB with remote interfaces”. The problem of standard OO design being hampered is inherent with distributed applications whatever technology they use, not EJB in particular, and the design patterns mentioned solve issues that are common to all distributed object technologies, not EJB in particular. I understand the fundamental point Rod is making – don’t use EJB with remote interfaces if you don’t need a distributed application – but I think some people may get the idea that he is suggesting that a new and improved distributed object/component technology could overcome these “EJB” issues...

    Regards,
    Gavin
  57. Use of EJBs[ Go to top ]

    <quote>and that many J2EE patterns (e.g. Session Façade, EJB Command, Data Transfer Object) “are workarounds for problems that are introduced by using EJB</quote>

    I think its a fairly valid argument that many of todays EJB patterns are anti-patterns (to borrow from the Bitter Java fellow). I think he was mostly referring to entity beans. Why do so many developers map persistent objects to high overhead remoteable objects (which are never exposed)? For every proper use of an entity bean, I think I've seen 100 overkill situations. Sun provides these tools promoting their simplicity, and yet most implementations are needlessly complex in using patterns (Session Facade a blatant example) to overcome problems introduced by entity bean's kitchen sink philosophy.

    For most developers, there are better solutions than using entity beans and complex patterns. For example, most developers can get by remoting applications and using Session Beans wrapped around JDO/TopLink/etc. That way developers can properly use all the other great Java/OOP practives such as inheritance, complex object models, etc. without using the crazy hacks in pattern clothing I think we've all used.

    J2EE is great, and has something to offer most everyone. But just because you need one thing such as CMT, doesn't mean you have to use every little piece.
  58. Use of EJBs[ Go to top ]

    Steve,

    I am in total agreement with you (and Rod) about entity beans.

    My point was that three of the patterns that Rod lists in his book as being "workarounds for problems that are introduced by EJB" are in fact perfectly valid patterns for distributed applications, IF you really need a distributed application. They are not EJB workarounds, they are solutions to common problems with using any distributed components technology.

    Whilst I agree with Rod that you should only use distributed components (and therefore EJB) when they are a true requirement, it worries me that I now see people mentioning "distributed application" and "design pattern" as if they are dirty words. I have already seen postings on other forums by developers complaining about the use of design patterns (even GoF patterns) in their projects (usually, it would appear, due to ignorance about them). Design patterns are a very useful tool and I think care must be taken lest uninformed developers get the mistaken impression that their use in general is a bad thing. Like any other technology they just need to be used appropriately.

    Regards,
    Gavin
  59. AOP and EJB[ Go to top ]

    Two quick comments:

    * EJB's and remote interfaces

    Apparently, Rod says in his book (I haven't read it -- but I will as soon as possible) that remote interfaces are one of the major weaknesses of EJB's. There might be some truth to that but this statement ignores another one, which I think is much more important: the fact that sophisticated EJB containers will allow you to cut down considerably the number of round-trips to your database. And this gain in performance will most likely dwarf the few remote calls that your application will have to make.

    * AOP and application servers

    To me, telling your customers that your application server is using Aspect-Oriented Programming is similar to telling them that you used the Command and the Memento patterns to implement your EJB container. First of all, they will probably wonder what you are talking about at all, and second, they simply don't care. The only thing that matters to them is what your product does. Simple questions such as: Does it respect the standards? Does it work as advertised?

    If Aspect-Oriented Programming can help you develop an EJB container or some other piece of technology more efficiently, then more power to you, but touting this as a strength when talking to end users is showing a preoccupying lack of understanding of your customers. Ignore what they need at your own risk.

    Once again, it's important to differentiate a technology from a product. Trying to sell one for the other is a guaranteed path to failure.

    --
    Cedric
  60. Remote interfaces[ Go to top ]

    <cedric>
    Apparently, Rod says in his book (I haven't read it -- but I will as soon as possible) that remote interfaces are one of the major weaknesses of EJB's
    </cedric>

    No, I don't say this. I argue that we shouldn't use business objects with remote interfaces unless it adds value, but that if we do need to go down that route, EJB offers a good way of handling remote clients. I also discuss the alternative use of web services to support remote clients for some applications.

    Chapter 1 is available online on the Wrox site, as well as Chapter 4 from here.

    Regards,
    Rod
  61. AOP and EJB[ Go to top ]

    Cedric,

    <quote>
    ...the fact that sophisticated EJB containers will allow you to cut down considerably the number of round-trips to your database. And this gain in performance will most likely dwarf the few remote calls that your application will have to make.
    </quote>

    I guess you're talking about Entity Beans caching. Of course, that is only applicable if you use Entity Beans at all. And I consider Entity Beans with remote interfaces deprecated as of EJB 2.0, at least de facto. I think the rule of thumb is: Don't use remote interfaces if you don't need to. And if you don't want Entity Beans (e.g. because you choose a POJO persistence toolkit), don't need CMT, and don't need remote access - then don't choose EJB at all.

    Concerning AOP: Sure such terms don't mean anything to your end customers, but that includes terms like EJB or even J2EE. Customers want working business solutions, not certain technology, at least in my experience. Of course, if we're talking about application developers as customers of middleware products, then your customers care about such terms, be it EJB or AOP, as they have to work with the respective programming model.

    So I'm not sure if I got your point. Maybe you're used to major projects where the management listens to app server sales guys that insist on the importance of a certain app server as basis for a project, often ignoring the developers that later have to work with it. In such a case, standard buzzwords count (EJB - yes, fine, that's important, we need that), although managers usually don't know any meaning behind them. But when talking about developers, then ease of use and ease of programming counts.

    Juergen
  62. AOP and EJB[ Go to top ]

    <Cedric>
    * AOP and application servers
    To me, telling your customers that your application server is using Aspect-Oriented Programming is similar to telling them that you used the Command and the Memento patterns to implement your EJB container. First of all, they will probably wonder what you are talking about at all, and second, they simply don't care.
    </Cedric>

    Sorry, perhaps I should have been more specific here...

    There are two aspects (sorry!) to the potential use of AOP in server-side frameworks:

    The first possible use of AOP is to allow for better organised code within an app server. This is internal to the app server and not exposed to the customer. Fair enough, I take your point that this is of little interest to the customer.

    The second use of AOP, however, is to expose the services that app servers currently offer (transaction management, security, persistence, etc) as part of a server-side AOP framework. Thus, instead of programming to EJB interfaces and setting deployment descriptors in order to use app server services, the customer will be able to simply add aspects to their business objects which provide these services. This is the route that JBoss and others are going
    and speaking for myself I can say that this is of intense interest to customers!

    Fair enough, there are no real standards in this area at the moment - even some of the fundamentals of AOP are hotly debated - but there is no denying that even a proprietary solution will be keenly accepted by a large proportion of the market if it appears to solve EJB's shortcomings.

    You surely can't have failed to sense the growing air of disillusionment with EJBs within the J2EE community? If this disillusionment manifests itself with a decline in EJB usage, then there will obviously be a corresponding decline in demand for EJB container based app servers. IMHO adding AOP framework style features to existing EJB-focused app servers sounds like a potential lifeline for the major app server vendors - why the resistance?

    Regards,
    Gavin
  63. AOP and EJB[ Go to top ]

    More on cedric's comment:

    <Cedric>
    * AOP and application servers
    To me, telling your customers that your application server is using Aspect-Oriented Programming is similar to telling them that you used the Command and the Memento patterns to implement your EJB container. First of all, they will probably wonder what you are talking about at all, and second, they simply don't care.
    </Cedric>

    Not so.

    If the appserver is using AOP simply in the app server's own internal design and that is transparent to the customers (us techies) then you are correct.

    But that is not what is generally meant, when an appserver says when it supports AOP. (I can only think of JBoss as an example here).

    My understanding is, that when an appserver supports "AOP", I can do things like deploy POJOs, and then depending on what config. of aspects I choose, I either get an "EJB" system, or JDO or whatever.

    Thus it directly affects the development of the project, and consequently the customers (us) care a great deal indeed.

    Bottom line - AOP is not just an implementation detail of server construction - if you think that you are missing the point. (Or I am, and I will gracefully retreat - although I don't think that is the case)
  64. AOP and EJB[ Go to top ]

    <tim>
    But that is not what is generally meant, when an appserver says when it supports AOP. (I can only think of JBoss as an example here).
    </tim>

    The AOP work on JBoss is only at the forum stage right now. If you are referring to the interceptor architecture, you are welcome to call it AOP but that's not what the whole thing is about, and a lot of application servers have had this for a hilw (including WebLogic, check out Bob's neat hack with jAdvise at

    http://crazybob.org/roller/page/crazybob/20021205
    )

    And I don't believe this hack qualifies as AOP either.

    To me, something that would start looking like AOP support would be a description file that I can deploy at runtime in the server that allows me to specify pointcuts in any application currently running there.

    No application server supports this as of today, AFAIK, they all require you to write extensive pieces of Java code to reach that result.

    --
    Cedric
    http://beust.com/weblog
  65. AOP and EJB[ Go to top ]

    <cedric>
    To me, something that would start looking like AOP support would be a description file that I can deploy at runtime in the server that allows me to specify pointcuts in any application currently running there.
    </cedric>

    Exactly. You deploy your POJOs. Then choose your aspects to make them act as entity beans/jdo/dao etc. etc.
    I would envisage app servers would come with some preconfigured "aspects" for common situations, but you could of course write your own for your own purposes.
    This is what I would call "AOP".
    You're right - no app server currently does this - I hope I didn't give the impression that I though JBoss currently does - although I think this is their aim in v4+.
    The point I was making is that AOP (using the definition both you and I share) is not simply an implementation detail of server construction if done in this way.
    If not done this way, then we're not talking about "the big" AOP, we're talking about the "little AOP".
    I think we're reading from the same page :)
  66. AOP and EJB[ Go to top ]

    Good article on this subject
    Component Models and Aspect-Oriented Programming
  67. AOP and EJB[ Go to top ]

    Cédric,

    "... the fact that sophisticated EJB containers will allow you to cut down considerably the number of round-trips to your database. And this gain in performance will most likely dwarf the few remote calls that your application will have to make."

    Well, 'gain in performance' is not exactly how I would word it myself but anyway... It probably depends on what you compare it to. I suppose that even though WLS got rid of CMP's 'n+1' problem for finder methods really early last year (AFAIK), the overhead of managing the cache, the pool, the passivation/activation, the complexity in writing CMPs with CMR, the possibility to have several instances of the same CMP in the cache, just defeat any other optimisation... But only IMO.

    Seriously, what gain in performance ? Under which circumstances ? Does WebLogic read all SQL statements and tries to optimise them into less round-trips or seriously, do you just mention the fact that within one transaction it is possible for a CMP to optimise finder queries, relationship traversal and getter methods into one DB call with the finders-load-bean element ? If that is all there is, I would not call that a gain in performance compared to other non-entity bean solutions. But I may be wrong... It may be that the CMPs are more maintainable. Only joking! ;)

                    Yann
  68. AOP and EJB[ Go to top ]

    <Yann>
    Well, 'gain in performance' is not exactly how I would word it myself but anyway... It probably depends on what you compare it to. I suppose that even though WLS got rid of CMP's 'n+1' problem for finder methods really early last year (AFAIK), the overhead of managing the cache, the pool, the passivation/activation, the complexity in writing CMPs with CMR, the possibility to have several instances of the same CMP in the cache, just defeat any other optimisation... But only IMO.
    </Yann>

    Oh, the n+1 problem is so 90's :-)

    I am indeed referring to all the other optimizations you enumerate. I find the phrasing "overhead of managing the cache" a tad ironic. If there is one thing that EJB's have taught us, it's that caching is what makes or breaks a scalable J2EE application (I believe that Cameron or even Marc will wholeheartedly agree). I would much rather have some extra bytecode computation to manage that cache if it can save me remote calls and round-trips to the database. We are talking orders of magnitude of difference, here.

    Of course, you can write your own relationship traversal caching code yourself, but if you are busy trying to meet a deadline, it's probably not a very smart move.

    --
    Cedric
    http://beust.com/weblog
  69. AOP and EJB[ Go to top ]

    Cedric, while I agree with most of this I just had to laugh about Cameron's agreement.

    Also a "tad ironic." A guy who writes J2EE Caching software had better agree with you, or get into another business.

    Jason McKerr
    Northwest Alliance for Computational Science and Engineering
  70. agreement[ Go to top ]

    Cedric: "If there is one thing that EJB's have taught us, it's that caching is what makes or breaks a scalable J2EE application (I believe that Cameron or even Marc will wholeheartedly agree)."

    Jason: "Cedric, while I agree with most of this I just had to laugh about Cameron's agreement. Also a "tad ironic." A guy who writes J2EE Caching software had better agree with you, or get into another business."

    I'd have to agree with Cedric on this one.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  71. AOP and EJB[ Go to top ]

    Cédric,

    "If there is one thing that EJB's have taught us, it's that caching is what makes or breaks a scalable J2EE application (I believe that Cameron or even Marc will wholeheartedly agree). I would much rather have some extra bytecode computation to manage that cache if it can save me remote calls and round-trips to the database. We are talking orders of magnitude of difference, here."

    I did not mean that caching is bad (even though I realise that it sounded this way)! What I meant is that there is very little to gain from caching or pooling mammoths. And the overhead comes when you think you could use memory more effectively. That's the kind of overhead I was thinking of. If for some reason, the cache is no longer big enough, then you enter the dreaded activation/passivation cycle and the gain in performance you mention just goes down the drain. If the way to make CMP fast is to cache the entire database, I think there is something wrong with it (and that only applies when noone else is using it, db-is-shared descriptor). Especially knowing that it is possible to have several instances of your CMP in the cache, you potentially end up with caching your DB several times (OK I'm being extreme there).

    I have written and run a few benchmarks for different design patterns on WebLogic 7.0 SP1 and on another application server (JSP-DAO, JSP-SLSB-CMP so far, JSP-SLSB-DAO, JSP-SLSB-BMP to be benchmarked, JSP-DAO-JDO to be implemented, in the Rubis spirit but better actually) and the results so far do not plead in favor of CMPs. We have an order of magnitude of difference indeed, but unfortunately CMPs do not stand on the right side, which is the reason why I reacted to your 'gain in performance' post.

    Now, you could argue that my code is probably bad. I could argue that there is a slight chance the technology may be a bit too complex too. And I have spent so much time dedicatedly learning EJBs that I would be very disappointed at this stage to have had it all wrong after all this time. :)

    Seriously, your 'gain in performance' statement is marketing, isn't it ? :)

                    Yann
  72. AOP and EJB[ Go to top ]

    <Yann>
    Now, you could argue that my code is probably bad. I could argue that there is a slight chance the technology may be a bit too complex too.
    </Yann>

    Fair enough.

    You made an interesting comment about activation and passivation, though. Well, passivation actually.

    I have been a long-time proponent of getting rid of passivation altogether, considering the current hardware costs and how my empirical observations tend to show that passivation pretty much never occurs. This is a totally personal opinion, but if you think that passivation is one reason why CMP is performing so bad, you might want to investigate this area further: tune your server to never passivate and see if makes any difference.

    Another occurrence of the old space/time trade-off.

    --
    Cedric
    http://beust.com/weblog
  73. AOP and EJB[ Go to top ]

    Cédric,

    "This is a totally personal opinion, but if you think that passivation is one reason why CMP is performing so bad, you might want to investigate this area further."

    You're certainly in a much better position than me to investigate why CMP is performing so bad. :) But I'll promise, I'll investigate further... even though I'm not sure I want to spend time trying to understand why they're so much slower, I'd better do something useful.

    I don't believe it has to do with any container implementation... but my empirical observations (correlated with that of fellow developers/architects) tend to show that CMPs and entity beans in general are crippling for performance (I think Rod won't disagree).

    Are there many people around here that would actually *use* CMPs for performance reasons ???

                    Yann
  74. CMP Performance !!![ Go to top ]

    I used CMP 1.1 in 1999 for a voice network management system and had no problems. One of the rules on the project was that anybody caught writing SQL would be fired. Yes, I was left to build the system on my own. But hey what a system.....

    A DBA friend of mine once said "A good DBA does nothing".

    My translation
    "A good J2EE developer aims to do as little as possible".

    The problem is developers want control and J2EE is about delegation. Of course if you delegate to an idiot you are a bigger idiot.

    The problem with CMP today is that many developers adopted early when the technology's maturity was not consistent across all application servers. Some developers had good experiences while the majority had very poor ones. That said CMP 2.0 has a lot of potential for typical EJB applications and I am sure vendors this time around have done their homework and provided fairly sophisticated CMP engines.

    I do a lot of performance work and the majority of the time I am called into projects its to fix up persistence issues not in CMP Beans but in the customers homegrown DAO framework, followed by their homegrown cache, homegrown HomeLookupFactory, and last but not least all those logging calls. Excessive logging usually indicates they just do not know what they are doing, what their beans are doing and what the container's doing.

    In all my years troubleshooting J2EE performance problems I have asked each development team have they read the J2EE/EJB specifications. The answer is always NO. When I leave, I am normally presented with

    "William, is this the worst project you have reviewd?"

    Answer: "No, there's always next week"


    Regards,


    William Louth
    CTO / Product Architecta
    Inspired
  75. AOP and EJB[ Go to top ]

    Fact of the matter is that most developers have gone down the path you just mentioned, e.g. using CMP for caching improvements, and then were surprised to find the cost of managing heavyweight objects, remoteable objects, complex finders, slow to non-existent relational optimizations, etc. had offset most of those gains.

    Fact of the matter is that now, most OR/RAD platforms provide cacheing in a much more sophisticated manner, with caches that can be distributed, context-sensitive, asynchronous, user managed, etc. In addition, these frameworks are far more streamlined: the management of ligherweight persistent objects that only use remoting when necessary (such as with Session Beans wrappers).
  76. AOP and EJB[ Go to top ]

    <Steve Lee>
    ... most OR/RAD platforms provide cacheing in a much more sophisticated manner...
    </Steve Lee>

    Can you provide some examples of these "platforms"? Do you have some numbers to compare them against entity beans? I am currently using WebLogic's ReadOnly CMP entity beans for caching. I'd love to consider a superior alternative though.
  77. AOP and EJB[ Go to top ]

    ReadOnly CMPs are a perfect example again of flawed patterns specifically used to overcome flaws in the spec. Why should you have to maintain TWO enterprise objects to represent ONE object?

    JDO (such as Kodo and Lido) and TopLink, the two that I am most familiar with are two of many platforms with better caching. While I can't quote hard numbers, in my experience the speed gained are large, not only from cache improvements (which are substantial, with multiple schemes per vendor), but also due to the fact that each business object is substantially less expensive to maintain.

    As Weblogic's own 7.0 documentation says:
    "Do not attempt to model every object in your system as an entity EJB... the trade-off in network resources is unacceptable."
  78. ReadOnly entity beans[ Go to top ]

    Maybe Cedric Beust, WebLogic EJB container tech lead, can shed some light on what kind of overhead is involved in using ReadOnly entity beans, and show us what kind of further enhancement can be done.

    Assuming the performance penalty is not orders of magnitude different, for ease of use, I would still choose entity beans. I can just write a single abstract class containing XDoclet tags, and don't have to do anything else (let Ant takes care of the rest). With JDO, I have to run the bytecode enhancer, and create a .jdo mapping file. With TopLink, I have to use a proprietary API and its own toolset. Neither of which is as productive as using CMP entity beans IMHO.
  79. Productivity with entity beans[ Go to top ]

    <Eric>
    I can just write a single abstract class containing XDoclet tags, and don't have to do anything else (let Ant takes care of the rest). With JDO, I have to run the bytecode enhancer, and create a .jdo mapping file. With TopLink, I have to use a proprietary API and its own toolset. Neither of which is as productive as using CMP entity beans IMHO.
    </Eric>
    Ant can also conceal the JDO enhancement step. Authoring the JDO mapping file is straightforward, compared to the entity bean deployment decriptors. I share your reservations about having to use "mapping workbench" style tools, although the TopLink toolset does provide support for some complex tasks.

    With JDO you don't have to implement any special interfaces to make classes persistent: they can be plain Java classes. You can even make existing classes persistent (although obviously there's a danger of inefficiency in any such approach).

    Nevertheless it's a matter of preference. If you find you're highly productive with CMP and that the performance meets your requirements, I wouldn't try to talk you out of it.

    Rod
  80. Productivity with entity beans[ Go to top ]

    Hi Rod,


    I have not read the book in full (just chapters on web) but I intend to do so over the coming weeks. Based on what I have read (pdfs) and your thread responses it would appear that you have a big distaste of CMP and Entity Beans. Could I ask


    1. What applications servers you have used and how have they contributed to your view/assessment of J2EE and EJB?
    2. Do you have any associations with a JDO vendor (books, products and consultancy)?
    3. What sorts of J2EE projects have you worked on?


    Please do not take offence to the above questions as I consider them important when I consider your arguments.


    Regards,


    William Louth
    CTO / Product Architect
    Inspired
    www.jinspired.com
  81. Productivity with entity beans[ Go to top ]

    Fair questions, no offence taken.

    1. I've used CMP principally in WebLogic 5.1/6.x/7.0. Also JRun, JBoss and Orion. My criticisms are based both on what is possible in the specs and my experience of the efficiency of real implementations.
    2. I have no commercial association with any vendor, JDO, app server or otherwise.
    3. A mixture of J2EE projects including very high throughput public web applications, in-house web applications, heavily transactional financial applications without web interfaces, in-house Swing applications, and applications exposing web services to a variety of clients. I've also worked as a troubleshooter on a variety of applications whose design I wasn't involved in. These applications have varied in the complexity of their data models, but I've seldom seen either BMP or CMP deliver real value. In one case, for example, a BMP 1.1 approach (late 2000) delivered adequate performance for most use cases (although far from impressive on the hardware available), but failed spectacularly where large result sets where involved. As I implemented what would now be called the Fast Lane Reader pattern in a fraction of the time the BMP implementation had taken to write and debug, for an order of magnitude increase in performance, I had my first doubts about the value of entity beans.

    While working on the book I also built a number of experimental applications with different persistence strategies. Again these, like every public benchmark I've seen, indicated poor performance for entity beans with BMP and adequate or poor performance for CMP unless the scenario resulted in heavy caching. And JDO or any other O/R mapping approach will also provide good caching.

    I should also say that at JavaOne 2000 I listened enthusiastically to the unveiling of EJB 2.0. I was a reluctant convert to entity bean scepticism. I wanted to believe!

    Regards,
    Rod
  82. Productivity with entity beans[ Go to top ]

    Also, although I like to have hands-on experience before passing judgment (as I've described), I have spoken to at least 20 architects and developers about their experience in J2EE projects. Not one said "we used entity beans in production and it was brilliant." A high proportion said "we threw out entity beans because of the problems we had" or "our project failed because of performance problems with entity beans."

    By contrast, no one said "SLSBs didn't work for us" or "servlets didn't work for us". The fact that so many people are experiencing problems with one particular facet of J2EE surely indicates something.

    Btw, anyone who would like to tell me their experiences--whether or not it tallies with mine--is most welcome to do so to the email address published in the book.

    Rod
  83. ReadOnly entity beans[ Go to top ]

    The orders of performance and difficulty *are* orders of magnitude different. Consider the remote round tripping that occurs when you realize your read-only bean needs to be dirtied. Or the fact that even in read-only mode, read-only beans do not hold a candle to cached TopLink or JDO objects (they don't have any excess remote calls, etc). Or the cost of constant JNDI hits and calls across the wire.

    "what kind of further enhancement can be done"
    Why should *you* have to do this? The whole point of CMP was supposed to be seamless scalability and security. And yet every day, developers keep banging their heads on the wall when they find this isn't true.

    For most developers, each entity bean in this strategy is a disaster. 6 source files, 4 deployment files (two of which is vendor-locked), and in many deploments, 2 jars. Combine this with funkiness like DTOs and the pain doesn't end there. If you want to compare XDoclet and Ant, XDoclet 1.2 will provide JDO metadata tags built into your source code and most vendors integrate seamlessly with Ant for their enhancement.

    The point is, there are many, many, easier and faster solutions out there that don't require you to spend hundreds of dollars going to every seminar and buying every book to achieve marginal results. Having built enterprise applications using all 3 (actually, several more in non-Java) persistence mechanisms, I can attest to this from experience.

    There are a few reasons for using entity beans. However, enterprise-level persistence is *not* one of them. They were designed from the ground up to be secure, not fast.
  84. ReadOnly entity beans[ Go to top ]

    <Steve Lee>
    ...Consider the remote round tripping that occurs...
    </Steve Lee>

    Is this still true if my web tier is colocated with my EJB's, and the only way the web tier accesses entity beans is through a Session facade, which in turn uses only local interfaces to call ReadOnly entity beans? Also, my JNDI lookups are done through a singleton Service Locator.

    I don't doubt JDO has certain technical merits, but are they that much better than entity beans in handling cache expiration and transparent object persistence? I am also concerned about the fragmented nature of the current implementations. Stated intentions by O/R mapping vendors (at least TopLink) not to support the JDO spec in the near future do not increase my level of confidence either.
  85. ReadOnly entity beans[ Go to top ]

    TopLink's implementation (using reflection) is incompatible with JDO's state modelling. And their company's fluctuating state doesn't help (with Oracle pushing them as a sales tool for their app container, and in turn CMP).

    Think about your first paragraph. Doesn't that sound needlessly complex and horribly limiting? A 100% read-only system will only get you so far. And you've lost all the things EJBs were supposed to be in the first place: remoteable (local interfacs), portable (deployment descriptors), clusterable, transactional (read-only).

    JDO is much more efficent than entity beans. Relationships are maintained and managed (in a variety of schemes including lazy, scrolling, complex fetch gorups, etc.) in a much more sophisticated manner. You can use all the OOP you've learned such as complex mappings, inheritance, etc. without killing yourself building another framework on top of Entity Beans. There are a variety of caching mechanisms supported by different vendors, at the very least context sensitive (PersistenceManager), and most have JVM and multi-JVM caching. Since JDO objects are so much less CPU and memory intensive than an entity bean, caching expiration is far less important (though most vendors again support complex cache management as well) (and instead of 100s objects, you can store 1000s in a smaller footprint).

    And even if you really wanted entity beans, the power of entity beans can still be used to wrap JDO objects (though even then, Session Beans are a better alternative). Then you can rapidly prototype in JDO without starting up a 300MB monster, then write simple Session/Entity wrappers and deploy to your appserver.
  86. Entity beans vs. JDO[ Go to top ]

    OK, you just twisted my arm enough that I wanted to give JDO a try. If I can borrow your crystal ball - which JDO implementation is the most technologically advanced and has the best chance to thrive in the future?
  87. Entity beans vs. JDO[ Go to top ]

    I've personally used Kodo in one system I reworked, but there are a variety of others listed at JDOCentral.com.
  88. Don't Believe Everything You Hear[ Go to top ]

    Toplink Datasheet claims "Based on open interfaces and industry-standards, including SQL, XML, JDBC, JTS, JDO, EJB 1.1 and EJB 2.0..." What is it? Oracle reps make statements disclaiming support for JDO but leaves a foot in the camp just in case in their marketing material.
  89. AOP and EJB[ Go to top ]

    <cedric>
    To me, telling your customers that your application server is using Aspect-Oriented Programming is similar to telling them that you used the Command and the Memento patterns to implement your EJB container.
    </cedric>

    That depends what you are providing, and how smart your customer is.

    Our last client reviewed our design and said "our enterprise standard is that rollbacks caused by database deadlocks should be retried at least once". If I could put pointcuts before and after each transaction that'd be easy.

    Our current client said "We want an audit trail of every access to the application - who is doing it, and what operation they are calling". With a decent pointcut mechanism that's about 10 lines of code total. Without that it requires a method call from each remote method (and if a remote method calls another remote EJB then.... ) Annoying to build, easy to miss one, a maintenance hassle.

    Another client wants an audit trail kept of who has changed what data object. Think about how a been developer combines that with CMP set-methods. Easily done, but again a trivial piece of code that needs to go into hundreds of places spread across the application... Oh, I wish I could just shove a pointcut into each of them.
    (The same client now wants an audit trail kept of who has *read* what data objects of a certain type.)

    We now have permission to use AspectJ to generate performance data on a real application - thank god, because profiling code spreads into every component (at least on our projects - which is why we perform). That'll be my first paid AspectJ programming, coming 3 years after I first started playing with Aspects. I expect almost all of our performance check code to be at at component boundaries, ie at places where EJB local or remote interfaces are called.

    99% of the places a developer would want pointcuts in an EJB container are actually quite limited and predictable. They're almost always places where the app server is already shoving code in - transaction boundaries, remote call boundaries, access to components, access to persisted fields. So I think you could provide a limited form of AOP to bean developers very easily, and it would make some of the fiddly requirements that real-world enterprise applications have a lot easier.

    Sean
  90. Aspect-enabled servers[ Go to top ]

    <sean>
    Our last client reviewed our design and said "our enterprise standard is that rollbacks caused by database deadlocks should be retried at least once". If I could put pointcuts before and after each transaction that'd be easy.
    </sean>

    I am not disputing this, but you are missing my point. Your client couldn't care less *how* you do it, they just want you to do it. Period.

    If your application server is aspect-oriented (or rather, aspect-enabled, which is a better way to describe it IMO), then more power to you, but it's a technicality that your client probably doesn't care for.

    However, you will indeed impress them if you can address their need quickly, and I agree that aspect-enabled servers might be a big help there.

    --
    Cedric
    http://beust.com/weblog
  91. Aspect-enabled servers[ Go to top ]

    Cedric,

    I understand your point but I don't agree with it.

    Unfortunately, the client often cares about *how* things are done. So with the big branding behind EJB they actually want EJB because they think they should have it, and it impacts their requirements. I've seen this time and time again.

    Try saying "we can't do that with our open source persistence framework" and they'll say "use another approach to do it properly". Say "CMP entity beans are an industry standard but don't let us do that" and they may consider relaxing their requirements.

    So I think that, as EJB is still the default choice for semi-technical decision makers, something like AOP will need a lot more publicity to help change that.

    An interesting case in point: my current client just had a report from BEA professional services saying they'd used too many fine-grained EJBs, and that some things they've modelled as EJB should be POJOs. Good, common-sense advice. But they aren't really listening, as they have a belief that (despite what BEA may tell them about how to use their own product) more EJBs mean more true enterprise standards applied in their project.

    Regards,
    Rod
  92. <Rod Johnson>

    (despite what BEA may tell them about how to use their own product)
    "more EJBs mean more true enterprise standards applied in their project"

    </Rod Johnson>

    The best summing up I've seen about this sad state of affairs..

    Regards
    Rolf T
  93. what semi-technical decision makers think[ Go to top ]

    <Rod>
     So with the big branding behind EJB they actually want EJB because they think they should have it, and it impacts their requirements. I've seen this time and time again.
    </Rod>
    That's my main reservation and skepticism against this whole J2EE standards bandwagon and claiming it as cure-all for enterprise solutions.


    The clients I worked with in the past have dictated a particular implementation .i.e use this appserver and use EJBs. It takes lot of convincing these days to use something other than EJBs.

    May be this is due to their past experience seeing projects fail because of technology choices made previously and they want something that is stamped fail-proof. If that could be an easy thing, we'll all be doing something else.
  94. Use of EJBs[ Go to top ]

    Gavin,

    Thanks for your thoughtful comments in this thread.

    I agree--these patterns/workarounds address the challenges of distributed applications in general, not just distributed applications with EJB. I make the point on the same page that " ...when we genuinely need distributed semantics...EJB isn't the cause of the problem but an excellent infrastructure for distributed applications". I'm cautioning against letting a decision to use EJB lead to the use of remote interfaces without good reason, rather than bashing EJB.

    I'm an enthusiastic advocate of GoF patterns where appropriate--Chapter 4 discusses several. I hope I don't give the impression I'm a pattern skeptic. I try to make the point that there's a difference between GoF patterns, which aren't tied to specific technologies, and "J2EE patterns". In my experience, GoF patterns are found in any well-written application. However, like anything else, patterns can be abused.

    Regards,
    Rod
  95. hi

     I havent yet purchased the book as it is not released in India. What i want to know is that does the book have anything about webservices what i mean is topics like J2ee & web services.
  96. How to do MVC in ASP.NET[ Go to top ]

    <quote>
    However, it doesn't give as complete conceptual separation between control code and presentation that you can get using an MVC framework with J2EE. So I think the Servlet API is still a richer model. In ASP.NET, the request goes first to the page, which may then forward it elsewhere. I think this is the wrong way around: a control component should forward to pages, not the reverse.
    </quote>
    As far as I know, you can do that in ASP.NET, you just need to write a custom IHttpHandler(this is similar to a servlet in J2EE, there is also a IHttpModule which is similar to Filter in the Servlet API) to be the controller and dispatch to the relevant aspx view page.
    It will probably look something like the following:

    using System.Web;
    namespace HandlerExample
    {
       public class MyHttpHandler : IHttpHandler
       {
          // Override the ProcessRequest method.
          public void ProcessRequest(HttpContext context)
          {
             String q = (String)context.Request.Params["q"];
             HttpServerUtility server = context.Server;
             // here check the parameters
             // interact with your model
             ....
             //
             // finally dispatch to the relevant aspx view page
             if(q!=null && server!=null)
    {
                if(q=="a")
                  server.Transfer("/a.aspx");
                else
                if(q=="b")
                  server.Transfer("/b.aspx");
                else
                  server.Transfer("/"+q+".aspx");
             }
             
              
          }

          // Override the IsReusable property.
          public bool IsReusable
          {
             get { return true; }
          }
       }
    }
    Complie it into a library file and put in the bin directory of your application (csc /t:library HandlerText.aspx)
    And put this following in your application web.config xml file.
    <configuration>
       <system.web>
          <httpHandlers>
             <add verb="*" path="handler.aspx" type="HandlerExample.MyHttpHandler,HandlerTest"/>
          </httpHandlers>
       </system.web>
    </configuration>

    Then , send request to the server by issuing
    http://myserver/app/handler.aspx?q=a in the browser

    Regards,
    Hun Boon Teo
  97. How to do MVC in ASP.NET[ Go to top ]

    Thanks for this. It looks good. I'll check it out and be more cautious about criticizing the web interaction model in .NET in future!

    Regards,
    Rod
  98. How to do MVC in ASP.NET[ Go to top ]

    To be fair, to my knowledge MS never actually talks about how to do MVC in ASP.NET, you need to do a bit of reading and "digging" and write some code to see how this thing work.
    This is a article http://www.15seconds.com/issue/020417.htm (HTTP Handlers and HTTP Modules in ASP.NET) if you are interested to know how the pipeline model work in ASP.NET

    Regards,
    Hun Boon Teo
  99. How to do MVC in ASP.NET[ Go to top ]

    It is ironic that while in ASP.NET one has to jump through hoops to do MVC, in the Java camp we have a long-standing JSR for JavaServer Faces, which is almost exactly a carbon-copy of ASP.NET as far as I am concerned, i.e, using postbacks, server controls, codebehinds, etc. Do we really need MVC for simple web projects, the type Microsoft technology targets?
  100. How to do MVC in ASP.NET[ Go to top ]

    http://mavnet.sourceforge.net/
    Above is .NET mvc, and Open Source.

    C# has CLR run time that run on BSD and Mac

    .V
  101. old persistence discussion[ Go to top ]

    Hi,
    As always the discussion is about CMP vs JDO vs JDBC.
    And as always there is no RESULT !!! (see the follwing thread to be sure http://www.theserverside.com/discussion/thread.jsp?thread_id=771 )
    What is the problem with JDBC that motivated JCP to introduce a new technology ?
    Isn't it true that DAO solves problems ? (or it lacks something !!!)
    If the developement time is our concern, we can use code generators like sql2java - a jdbc code generator that can produce 95% of our daily jdbc codes without a line of programming .
    These is a BIG problem with JDO and CMP : we have to learn a new API !!!
    Every one knows that jdbc is much more faster that CMP and JDO, so what is the problem with java community ???

    Thanks,
    Bye
  102. How do you dare say it?[ Go to top ]

    Ali, don’t you know that you should not swear in church. They have just lost their beloved EJB's and already you are questioning the O/R? You are absolutely hopeless!

    Regards
    Rolf Tollerud
  103. Old persistence discussion[ Go to top ]

    Rolf,
    Can't you see how any discussions about EJB yields to the question : CMP vs JDO vs JDBC (and as always no RESULT)
    I want to know what is the problem with JDBC ????

    Regards
    Ali Salehi
  104. SAP with 10000+ tables using O/R tools?[ Go to top ]

    The point is that there is nothing wrong with JDBC at all. O/R mapping is a tool that speeds up the development process and as such therefore mostly has its value in contract programming situations. Moreover, the conditions most be fairly simple.

    Both parameterized and dynamic SQL will always be faster.

    Things are different when you are making a product. Consider for example that Siebel have decided to put their complex CRM system on Websphere. There are complicated queries (a la Joe Celko) and updates which span over many tables. The user can construct his own dynamic queries, or he can set filtering conditions and even (if he have permission) add columns to the database. O/R tools falls short fast under this conditions.

    If you really want quality in your app, consider using something like Rods DAO framework in his book!

    Regards
    Rolf Tollerud
  105. SAP with 10000+ tables using O/R tools?[ Go to top ]

    SAP is more or like a database on top of a conventional database. It's a product and it makes some sense if they decided to use plain JDBC and SQL instead of O/R mapping.
    That does not mean everybody else should use JDBC and SQL.

    O/R mapping is for increasing productivity and maintainability of an application in corporate environments where the business depends upon the enterprise software application to maintain its competitive edge.

    I think performance is also over-stressed in enterprise apps. The first focus is developing easily maintainable systems if that means using say for argument sake enity beans or whatever.

    If a technology makes it possible for fast development and maintainability of a system then IMHO it should be preferred over a complex well performing system.

    Enterprises find it easier to buy hardware and through at performance problems than adding people to make a complex technology work for them.

    Make your app so that it does not depend upon which persistence mechanism (JDO, EB, SQLJ or JDBC) your using as pointed out by the Rolf above.

    Enough said.
  106. What is this![ Go to top ]

    Rajnikant,

    It seems that we are more or less on the same track.
     
    I have to admit that it is quite a relief to actually agree with someone!

    Regards
    Rolf Tollerud
  107. SAP with 10000+ tables using O/R tools?[ Go to top ]

    I would clarify the comment that CMP fails fast under these conditions.

    I agree with you, for some applications JDBC is the best choice. I wouldn't want to implement Google for example using OR. However, I think people need to be aware that there are products which provide all the features you mentioned, such as complex queries, large updates, etc. at a very small performance price (unlike CMP which demands multi-CPU, gigabyte memory servers).

    And contrary to what you mentioned with contract situation, I think most developers on this site would argue we use Java and J2EE so we -dont- have to reinvent the wheel every project. With my last company, on the order of 4 developers, we couldn't have accomplished all we did without a large amount of structural support. Otherwise, we'd have been in the RAD/OR ourselves!
  108. EJB Components[ Go to top ]

    After following this thread I am starting to feel like everybody is building Objects and not Components. A Session Bean class when viewed simply at the code level is an object and not a component. Components are much more than Java bytecode - or as one CORBA expert once said - silly little beans.


    Maybe componentization is not really needed at the layer above the database, ;-(. It sure looks like developers on this thread are simply building data holders.


    When I built J2EE applications the configuration was as much apart of the component as the Java code. CMP was one important aspect but environment configuration (execution logic configuration) and resource association (references) were also important to my design. DAO's do not help here...or do they?


    Maybe I over did it in terms of strategies and policies but when you attempt to build a generic banking solution such is life.


    Regards,


    William Louth
    CTO / Product Architect
    Inspired
  109. EJB Components[ Go to top ]

    <william>
    After following this thread I am starting to feel like everybody is building Objects and not Components.... Components are much more than Java bytecode - or as one CORBA expert once said - silly little beans.
    </william>

    I agree. When you want components, there's a lot going for EJB. When you want fine-grained objects, the overhead gets you. Components tend to be session beans.

    I think the fact that all EJBs are best used as components is one of the reasons that entity beans are problematic. Once you give up on remote access to entities (as EJB 2.0 effectively does) it's hard to find a justification for modelling persistent objects as EJBs.

    If you want a component model, you have to accept that you probably need something fairly heavyweight such as an EJB container to manage your components, accept remote calls etc. With persistent *objects* however, it's harder to justify their dependence on a heavyweight container. (Of course an AOP "container" might not need to be as heavyweight--we'll see.)

    Regards,
    Rod
  110. Rod's framework[ Go to top ]

    Rolf,

    "If you really want quality in your app, consider using something like Rods DAO framework in his book!"

    I could not agree more. By the way, the full framework is about to be open-sourced on sourceforge (this week-end) under the "Spring framework" public name. Why don't you join the club and contribute enhancing its quality ? As Rod pointed out in the interview, it would be good to see J2EE and .NET sharing best practices (cross-pollenating or something like that).

    Check out http://p2p.wrox.com/list.asp?list=expertj2ee_with_rodjohnson

                    Yann
  111. Rod's framework[ Go to top ]

    Yann,

    Ok, I take a look. Would be nice to have only one framwork for both .NET and Java!

    Regards
    Rolf Tollerud
  112. old persistence discussion[ Go to top ]

    Ali-
    You need O/R mapping when you have large number of objects and tables usually the something greater than 45 tables is considered large.
    In this case, you need JDBC does not scale well in terms of maintainability and amount of code that needs to written.
    Having an O/R mapping in such a project actually increases productivity once you have passed the learning curve.
    Of course, once you get used to it you feel like you want to use it in all projects that don't require a powerful framework like O/R mapping.
  113. WHY JDO or CMP, use JDBC (EVERYWHERE IT FITS)[ Go to top ]

    <Rajnikant>
    JDBC does not scale well in terms of maintainability and amount of code that needs to written.
    Having an O/R mapping in such a project actually increases productivity once you have passed the learning curve.
    </Rajnikant>

    I know writting jdbc code for 45 tables is wasting time BUT i say, why you can't see JDBC code generators ??
    They do everything for you (just config 3 line )
    This solution FITS IN ANY LARGE SCALE PROJECT.
    It is Convenient because the generated code is JDBC and you don't need to learn anythings.
    Performance will be greate. (for whom need performance)
    The coding time will be almose NOTHING as we compare with the whole project.
    There is no problem.
    I can't understand why you want to learn JDO or CMP when you have the right tool in open-source ?

    Really amazing !!!

    Regards
  114. You can not think only of yourself![ Go to top ]

    But Ali, to follow your advice means that there will be no difference between Microsoft programmers and Java programmers. And how do you expect the big Java app server vendors to earn a living?

    They have expenses you know, rent and kids that need dental treatment and so on, Do you want to take the bread of out their small mouths?

    Regards
    Rolf Tollerud
  115. I think u r not even qualified to use Java! If u think that EJB is useless because of the performance penalties, then after some time, u will find out that Object Orientation is useless either. Then you go back to functional programming with C. Of course, finally u become a hopeless Assembler!
  116. But I try as well as I can![ Go to top ]

    Every day I am getting better and better..

    Maybe one day I can take the great examination..

    Ambition is what counts!

    Regards
    Rolf Tollerud
  117. WHY JDO or CMP, use JDBC (EVERYWHERE IT FITS)[ Go to top ]

    When complexity is an issue that is where OO (or O-R mapping) kicks in. Just bunch of SQL calls and JDBC can't manage it effectively.
    What you do need is the ability to shield applications from future complexity and requirements i.e. you need to make your application design scalable.
    By shielding your business layer from the persistence layer implementation (JDBC, JDO, etc..) you retain the choice to adapt a more suitable persistance mechanism in future.
  118. old persistence discussion[ Go to top ]

    These discussions usually happen because of:
    1. People get tired of dealing with JDBC such as DB Vendor lock-in, no OR mapping (I've seen projects who have spent years worth of man-hours maintaining), and high levels of implementation details in their application code.

    2. People then turn to CMP, esp. with all the hype surrounding it (which was more true several years ago). Then like one of the projects I was on, halfway through the project, an actual usuability test happens and people start freaking out because of the performance. Then their project manager/client asks why they spent thousands upon thousands of dollars for a product that is so slow. Carnage ensues.

    3. People haven't tried JDO. Between CMP vendors pushing down technology that requires huge expenditure on their half reworking, business guys who only read about CMP in trade papers, and the constant confusion between JDO and Object databases, JDO has converted people like me whove tried it, but hasn't reached the masses yet. But its new. I know most developers stayed away from CMP as well until deep into weblogic's product cycle.
  119. Hi Ali

    I also think that there's no need to talk about the performance penalties of using say EJB/JDO or ... compared to JDBC anymore. As you said everyone knows that pure JDBC is so faster than EJBs and JDOs.

    The problem is that no one forces us to implement our project using EJB or JDBC. If someone feels that JDBC satisfies its requirements there's no need to goto the EJB way and on the other hand if someone understands that the project that he/she or his/her team is responsible for demands the use of EJB or say JDO or ... no one forces him not to use that.

    The problem is that the Sun is hearing all of us, and of course is aware of the defficiencies of J2EE (every platform has its own pros/cons) and is trying to do its best to solve these defficiencies.

    I'am %100 in agreement with u that the talks about JDO/JDBC/EJB are becoming so boring and we have to avoid such conversations anymore.

    Best Regards,
    Behrang
  120. J2EE can be hard to use out of the box[ Go to top ]

    <excerpt>
    J2EE can be hard to use out of the box. Take JDBC and JMS for example. Using either or these APIs is quite verbose, and they're quite low level. So we need a higher level of abstraction. However, this isn't a deficiency in the specs so much as an indicator that we need to build applications on frameworks simplifying the use of J2EE.
    </excerpt>

    What kind of framework would that be? Do you mean a framework such as Oracle's BC4J?
  121. J2EE can be hard to use out of the box[ Go to top ]

    Well, one option is the framework published with the book, which is about to become an open source project on SourceForge under the name "Spring Framework". There's a range of stuff there, including a JDBC framework that makes life a lot easier and helps to avoid common errors, and a consistent approach to configuration management using JavaBeans.

    BC4J has similar goals, although I haven't used it myself.

    In my experience, most large projects develop their own infrastructure to solve these problems. Unfortunately this takes a lot of development effort, solutions vary in quality, and developers need to learn a different approach for each project they work on.

    Regards,
    Rod
  122. J2EE can be hard to use out of the box[ Go to top ]

    Thanks Rod!

    I liked the interview very much and I just ordered your book. I'll definitely have a look at the framework as well.

    Best of luck,
    Regards,

    ->Yagiz
  123. Rod,
    Though I am not an J2EE wiz, I do have a decent amount of experience and I thought the book was great. The framework also gave me alot to think about.

    However, as good as J2EE is, it seems to me that Sun would do well to focus much of its energy on delivering better tools to truly enable RAD for J2EE apps.

    There are many frameworks out there to help deliver quick and sturdy apps and many of them do a great job. But I think some standard tools and higher-level APIs are needed moving forward. Rod, take your JDBC framework code. I think this is great. As you say, it removes much of the code not related to solving the business problem at hand out of business methods. Why hasn't more of this type of thing coming directly from Sun? It would be nice if there was a strong, standardized toolset(and ideally, vendor-neutral) that could be used to minimize complexity when dealing with J2EE. Some existing frameworks are wonderful but in my opinion they often enable faster development but not RAD, except for the highly technical.

    One would argue that even with higher-end tools, one needs to be well versed in all the J2EE APIs etc. I agree to an extent but if there were tools out there that were 1.)high in quality and 2.)relatively easy to learn (much easier than using all existing J2EE APIs directy), it would be eagerly embraced by IT departments wanting to utilize J2EE standards to build robust apps.

    Is it just me (and it very well could be), or is J2EE missing someting?

    Mike
  124. Michael,

    I agree.

    I think one of the challenges for J2EE is that, as it does involve multiple servers, rather than a single product like .NET, it's hard to get a "standardized toolset". Although (if you're talking of IDEs), Eclipse & co are getting really good now.

    Regarding simplified APIs like my JDBC framework, I think it's disappointing that Sun haven't picked up the need for something at a higher level than the specs. They don't seem to appreciate that "a simple solution for common problems" is as important as "a [complex] solution for just about any problem". However, I think the community can step in and bridge this gap through open source projects such as Spring. I don't think we can expect all the answers to come from Sun as Java and J2EE matures.

    Regards,
    Rod
  125. 1 more question...[ Go to top ]

    Thanks for the reply. While on the topic (somewhat) of using a higher level of abstraction to simplify the development process, I'm interested on your opinion of MDA (Model Driver Architecture). I know this is in its infancy but it has geneated quite alot of buzz.

    Do you think such a high-level approach to software development will ever become the mainstay? Obviously on the surface it sounds quite appealing as you should be able to model all of an application's 'business' functionality without coding, but I'm a little skeptical on the practicality of it. After all, I remember reading 10 years ago that by the 21st Century, we'd all just be 'gluing' pre-fabbed objects (Employee, Department, etc.) together, changing a couple of config properties, and voila! we'd have our entire application (or at least 90%). Obviously this has yet to come to fruition.

    Mike