"I'm an EJB proponent. Not just session beans, but ENTITY beans"

Discussions

News: "I'm an EJB proponent. Not just session beans, but ENTITY beans"

  1. "I'm an EJB proponent. Not just session beans, but ENTITY beans". This is so rare, that I just felt like I had to post about it :) Joe Ottinger continues to discuss why he thinks this, and how "BMP entities are where it's at, if you ask me".

    I'm an EJB proponent. Not just session beans, but ENTITY beans.

    NOTE: Being English, I still can't work out if there is any sarcasm in Joe's voice.

    Threaded Messages (43)

  2. I don't mean to run down Hibernate. I'm using it myself, right now, and I'm not unhappy with it. It's just that Hibernate pushes the decisions over to the developer, and I don't think the developer is the right person to make all of those scalability decisions
    :-)
  3. I don't think the developer is the right person to make all of those scalability decisions

    However, the developer is the right person to make all of the object design issues, not shackled by the cumbersome entity ejb api.
  4. >> I don't think the developer is the right person to make all of those scalability decisionsHowever, the developer is the right person to make all of the object design issues, not shackled by the cumbersome entity ejb api.
    If the developer's the architect and he doesn't need the things EJBs provide, great. But I still say that EJBs have their place in design, and I don't think they're crucially flawed - but I do think that 95% of the developers who "don't like them" have judged them on the basis of their having used a cannon to hammer a nail.
  5. Thanks for the response Joseph. In my own experience, I have found that the Spring+Hibernate architecture has provided what I need from the EJB solution space without the pain. I would urge you to check it out.
  6. Thanks for the response Joseph. In my own experience, I have found that the Spring+Hibernate architecture has provided what I need from the EJB solution space without the pain. I would urge you to check it out.
    But this assumes that I think EJB is a pain, doesn't it?
  7. Thanks for the response Joseph. In my own experience, I have found that the Spring+Hibernate architecture has provided what I need from the EJB solution space without the pain. I would urge you to check it out.
    But this assumes that I think EJB is a pain, doesn't it?
    No, he assumes you aren't masochist.
  8. Thanks for the response Joseph. In my own experience, I have found that the Spring+Hibernate architecture has provided what I need from the EJB solution space without the pain. I would urge you to check it out.
    But this assumes that I think EJB is a pain, doesn't it?
    No, he assumes you aren't masochist.
    Yet, in all honesty, I don't consider myself a masochist, either. Writing EJBs is trivial - all it really takes is an awareness that the deployer role isn't the same as the developer role.
  9. Writing EJBs is trivial - all it really takes is an awareness that the deployer role isn't the same as the developer role.

    Yet not all companies can afford to divide these roles and hire two separate teams of developers and deployers.

    About EJB 2.0 simplicity: anyone who tried to build better software instead better career had to try non-standard alternatives like Hibernate, AOP, Spring, etc. The only thing you loose is dependency on the costly EJB container. Sooner of later EJB spec will be broken into a few ones (one to manage distributed objects, another to offer some kind of ORM, etc, etc) to catch up with open source alternatives.

    About EJB success: Success of a project can take many forms. There are cases when excessive complexity is "what keeps us employed, what feeds us." In those cases projects built on EJB 1.0 and JSP Model 1 are the best.
  10. > Writing EJBs is trivial - all it really takes is an awareness that the deployer role isn't the same as the developer role.<br><br>Yet not all companies can afford to divide these roles and hire two separate teams of developers and deployers.
    It doesn't take two separate teams. I serve as my own developer, deployer, system administrator all the time. What it takes is a team made up of people who can "switch hats" mentally so that they're not developing based on what makes deployment go away, or easier, or whatever. It's not HARD, it's just a separate role.
    About EJB 2.0 simplicity: anyone who tried to build better software instead better career had to try non-standard alternatives like Hibernate, AOP, Spring, etc. The only thing you loose is dependency on the costly EJB container. Sooner of later EJB spec will be broken into a few ones (one to manage distributed objects, another to offer some kind of ORM, etc, etc) to catch up with open source alternatives. About EJB success: Success of a project can take many forms. There are cases when excessive complexity is "what keeps us employed, what feeds us." In those cases projects built on EJB 1.0 and JSP Model 1 are the best.
    I've tried them all. Some are wrenches, some screwdrivers, others hammers. I don't think EJBs are the cure-all to the world's ills, but I don't think EJBs are also the worst tech ever and to be avoided like the plague.
  11. But this assumes that I think EJB is a pain, doesn't it?

    Not trying to flame you, I don't care :-) I have had great success with S&H and wanted to share. Have fun!
  12. have judged them on the basis of their having used a cannon to hammer a nail
    thus spoke the author of webcompass ;)
  13. have judged them on the basis of their having used a cannon to hammer a nail
    thus spoke the author of webcompass ;)
    Okay, THAT hurt. WebCompass was definitely flawed, due to its CMP usage... but in my defense, Mike Cannon-Brookes coded that part. The current version of WebCompass (AKA HyperRef, with nothing to do with OpenSymphony) doesn't use CMP to manage relationships, and performs much better under load - although even its performance isn't anything to write home about.

    Bottom line is, if you can use directed graphs, do so. If not, hey, look at HyperRef or WebCompass.
  14. If you're using JBoss...[ Go to top ]

    I don't normally reply here, I have a theory about comments on forums such as this. I decided to make a rare exception, check out the (http://jboss.org/wiki/Wiki.jsp?page=JBossHibernate) JBoss Hibernate deployer. You can (please do not talk like a pirate) deploy a HAR file. The HAR file contains the bulk of that information in (and hopefully xdoclet generated) config that Joe most likely feels that Hibernate pushes down to the developer. The session management can then be done through interceptors and and MBean. In my view, managing the session is the biggest drawback to Hibernate. This really makes that concern mostly irrelevant. As for BMP entity beans, please be careful if you choose to heed Joe's advice (or sarcasm, in this case I can't detect its boundries). Most of the time BMP puts you in an N+1 load semantic or is all cost and no gain (meaning the finder will be a query and every row will be "on load"). I agree that well tuned CMP isn't toooo bad but I think Hibernate + managed sessions should prove superior. Take a look.
  15. If you're using JBoss...[ Go to top ]

    I don't normally reply here, [...]
    Or did you mean you normally do not reply here using this user id?!

    SCNR,
    Lars ;-)
  16. We have never had one without EJBs[ Go to top ]

    Sorry guys, at my company we never a single project WITHOUT EJBs. I do use and do like them. Sue me, or us, for that matter. Sure, XDoclet, and MiddleGen helps a lot.
  17. The earch is oval ![ Go to top ]

    Just passing by...and still see EJB. sounds like insisting that the earth is flat knowing that it is not a REAL WORLD choice for backend logic.
  18. I am proponent of ENTITY beans too. But I would advocate using them in 0.1% projects where they are really needed.
    I would say that BMP simply makes sense because it defines lifecycle that is well suited for distributed environment.
    CMP – no, I do not think it was/is a good idea. I would say that CMP is to blame for entity beans failure among developers. CMP beans were received as a generic persistence layer implementation and many projects attempted to use them as such, but CMP is not good enough for complex ORM and were initially unnecessary complex to develop (without XDoclet or nowadays IDEs… )
  19. We're really not as smart as we think we are...[ Go to top ]

    NOT being English, I think there is a LOT of sarcasm in Joe's voice.
  20. EJB CMP is good for you[ Go to top ]

    We have used EJB 2.0 with CMP in multiple projects - very successfully. And I know lots of other projects where they have been used without problems, as well (or at least with no more problems than other technologies).

    I simply don't believe that everyone and their brother fears EJBs and rather uses [insert favorite O/R mapper here]. The percentage of people who think that EJB/EntityBeans suck is totally out of proportion among those who write here on TSS.

    Stefan Tilkov, http://www.innoq.com/blog/st/
  21. EJB CMP 2.0 is all but dead...[ Go to top ]

    and that's a good thing. The EJB3 spec supports the model pretty much for backward compatibility. I do believe that customers have tried and failed with EJB CMP 2.0, and I think that's what's driving the newer directions of EJB3. EJB2 is just too hard for your average developer. Sure, you'll have success. You'll also have a whole lot of failure. I've done a whole lot of informal polls through the years to a variety of audiences, and a small percentage of EJB CMP users are happy with it, and most want to move off to something that's more productive, and in many cases, more performant (with less effort).

    Re. the community, the feedback that it has provided for me has been valuable. As an author, I recognize that the server side community is politically charged, and a very advanced community. As such, you've got to be careful to compensate for that bias in by books. But in this case, TSS and its community has grown much of its user base through EJB book giveaways (Ed and Floyd have two of the more successful Java books out there). So I don't buy your argument that EJB is somehow underrepresented on TSS.
  22. EJB CMP 2.0 is all but dead...[ Go to top ]

    "EJB2 is just too hard for your average developer. Sure, you'll have success. You'll also have a whole lot of failure."

    Nothing new here, don't blame EJB, this is just the classic software development crisis; Oracle with PL/SQL and Microsoft with Visual Basic fulfilled the needs of the "average" developer. Thus, these average developers were shocked by J2EE, especially the Entity Beans concept. Domain analysis and design abstraction is just not common sense here.

    A software developer could have a computer science degree or just spent a weekend browsing books in Borders. Then, I've seen Borders weekend warriors run circles around CS grads. So, things like "EJB CMP 2.0 is all but dead" is really insulting, too make this claim is just so arrogant.

    >"So I don't buy your argument that EJB is somehow underrepresented on TSS."

    Really, then why all the EJB bashing? Like I said earlier, TSS is like a big daycare, the first thing you notice is all the cry babies, while the confident majority is playing quietly with their EJBs...

    A question to Bruce Tate and Rod Johnson, have you spec out every conceivable business requirements in the world and decided to write books about what (J2EE developers) can or not do? What's the agenda?
  23. EJB CMP 2.0 is all but dead...[ Go to top ]

    >"EJB2 is just too hard for your average developer. Sure, you'll have success. You'll also have a whole lot of failure."Nothing new here, don't blame EJB, this is just the classic software development crisis; Oracle with PL/SQL and Microsoft with Visual Basic fulfilled the needs of the "average" developer. Thus, these average developers were shocked by J2EE, especially the Entity Beans concept. Domain analysis and design abstraction is just not common sense here.A software developer could have a computer science degree or just spent a weekend browsing books in Borders. Then, I've seen Borders weekend warriors run circles around CS grads. So, things like "EJB CMP 2.0 is all but dead" is really insulting, too make this claim is just so arrogant. >"So I don't buy your argument that EJB is somehow underrepresented on TSS."Really, then why all the EJB bashing? Like I said earlier, TSS is like a big daycare, the first thing you notice is all the cry babies, while the confident majority is playing quietly with their EJBs...A question to Bruce Tate and Rod Johnson, have you spec out every conceivable business requirements in the world and decided to write books about what (J2EE developers) can or not do? What's the agenda?
    Well, the problem is OO domain modeling isn't easy with CMP. Performance issues aside, entity beans are a setback for anyone who wants to make an object-oriented domain model. Finder methods that can't return polymorphic results? Yep, that's entity beans. I will certainly admit that it is possible to make some effective systems with CMP Entity beans. But why have we had to tolerate a methodology where easy things are "possible" instead of easy, or better yet, fun!

    When I went to Java One '02 and saw the JDO talk I saw immediately that JDO addressed my needs in a familiar, object-oriented way (of course I had to get over my fear first, since I'd spent 2+ years on entity beans). If you love OO, you just can't love entity beans. OO makes easy things easy and fun, and believe it or not, enterprise persistence can be easy and fun too if you can leverage plain old java objects.

    -geoff
  24. EJB CMP 2.0 is all but dead...[ Go to top ]

    Thus, these average developers were shocked by J2EE, especially the Entity Beans concept. Domain analysis and design abstraction is just not common sense here.
    I don't care about my rating as an average developer or not, but yes, I was shocked by the EJB concept because:
    - The specs make pure OO modeling impossible - cannot subclass anything with EJBs
    - The specs call for un-necessary donkey coding (fundamental problem - innovation by requiring methods to be implemented to facilitate underlying mechanisms as opposed to core language level innovations)
    - They insult business complexities by assuming that all we need is a facility to get entities by primary key or some silly finders
    - They further insult businesses by constantly changing "Enterprise class" specifications so that within 2 years, I find my "Enterprise" application written with features that are now second-class citizens.
    - The infect OO design by concepts such as "Data Transfer Objects"
    - The make a mockery of configuration by calling for complex xml configurations that are usually embedded deep in a jar and hidden somewhere in the classpath, making their hot-modification all but worthless

    Should I go on? May be I should - one more point:
    - The underlying driver behind Entity beans is very simple - MONEY. The app servers want to control the data access layer to relegate database providers into obscurity and turn them into a meaningless commodity. Unfortunately, someone told Sun that they know how to write Enterprise class apps. I mean think about it - does Sun have a services division like IBM or Accenture that has seen what happens when you are writing business apps? Frankly, I'm not surprise by the EJB mess. Microsoft is powering along with .NET. I hated ASP and COM and switched to Java. But now I find .NET and ADO.NET a joy to use. And yes, 95% of applications being written using J2EE containers don't need an "enterprise" class container or enterprise designs. Its over engineering
  25. Please excuse my ignroance. I must ask. What is "donkey coding?".
  26. You've never heard that term? Its when you are writing code just because the specs require you to - not because it is adding to your app logic. Like all the interfaces needed to create an EJB. To be fair both .NET and J2EE have that. The difference is that MS with its one vendor monopoly ships VS.NET which takes care of the donkey code for you. I know there are some java tools that do something similar, but until recently no one has thought of coming up with a comprehensive standards based tool for this.
  27. You've never heard that term? Its when you are writing code just because the specs require you to - not because it is adding to your app logic. Like all the interfaces needed to create an EJB. To be fair both .NET and J2EE have that. The difference is that MS with its one vendor monopoly ships VS.NET which takes care of the donkey code for you. I know there are some java tools that do something similar, but until recently no one has thought of coming up with a comprehensive standards based tool for this.
    You do not need to be very clever to generate this garbage, there is no problems to use more "transparent" ways and to generate adapters at runtime. EJB is not so bad framework for stuff like homepage backend, but it has two major problems as "enterprise" technology: EJB is too tied to single programming language and platform, It is too experimental (O/R stuff).
  28. EJB CMP 2.0 is all but dead...[ Go to top ]

    "But now I find .NET and ADO.NET a joy to use. And yes, 95% of applications being written using J2EE containers don't need an "enterprise" class container or enterprise designs. Its over engineering "

    Heretic!!

    The Java "community" is schizophrenic in that on one hand Java is great because it isn't hard like C/C++, yet when someone complains that some slice of Java is too hard or overly complex they attack the complainer saying that they are just too stupid. It's actually kinda fun to watch.
  29. EJB CMP 2.0 is all but dead...[ Go to top ]

    - They further insult businesses by constantly changing "Enterprise class" specifications so that within 2 years, I find my "Enterprise" application written with features that are now second-class citizens.
    This is one of the key and most disturbing points about EJBs... This is why specs should start slim (or just wait) and build out as there's a consensus on best practices, not try to codify an architecture front-to-back first, then see how they're used.
  30. EJB CMP 2.0 is all but dead...[ Go to top ]

    - They further insult businesses by constantly changing "Enterprise class" specifications so that within 2 years, I find my "Enterprise" application written with features that are now second-class citizens.
    This is one of the key and most disturbing points about EJBs... This is why specs should start slim (or just wait) and build out as there's a consensus on best practices, not try to codify an architecture front-to-back first, then see how they're used.
    2 years in the software industry is a lifetime. You guys need a little perspective. EJB was a collection of what was thought were best practices at the time. EJB 3.0 and J2EE 1.5 are doing a good job of learning from innovations of various companies and OSS projects to improve the usability of the specification. This is radical for a standards body.

    Each middleware specification has built on and learned from its predeessors.

    Bill

      



    EJB is and was the consensus of best practices at the time. Same thing when CORBA was popular. You forget that O/R has been around for awhile in Java and even further back, in C++. Distributed computing has been around even longer with predecessors of EJB in CORBA and DCE.

    Best practices change and improve over time. If we took your approach, there wouldn't be any standard worth implementing or writing applications for.

    The industry needs standards to unify the industry and set a direction for it so that best practices can be found and improved upon.

    This is why I'm very excited about J2EE 1.5. I've seen specs like DCE and CORBA just feature bloat with no attempt at simplifying development as they evolved. It is quite refreshing to see that the main focus of J2EE 1.5 and EJB 3.0 is simplifying development.

    I'm also impressed at Sun's stewardship. They recognized from XDoclet and .Net the power of Annotations, changed the Java language, and are now trying to leverage this within J2EE and other specifications. You may think : "Hey, if they don't simplify J2EE, J2EE is dead. So, of course they would do this." But, recognizing and accepting that that your specification needs serious revision is half the battle.

    Bill
  31. EJB CMP 2.0 is all but dead...[ Go to top ]

    Well, Bill, you managed to completely miss the point, so congrats...

    The point was that the entity beans part of the spec is now on its 3rd completely incompatible revision in 5 years. That's hardly an "Enterprise" API to me.

    I wrote a long rant here: http://jroller.com/page/jcarreira/20040910#biled_by_bburke
  32. EJB CMP 2.0 is all but dead...[ Go to top ]

    2 years in the software industry is a lifetime
    Bill, tell that to a CEO or CFO who has just spent $50M on a project and now has tech leads tell him he should switch to the newer spec and rewrite the project. The software industry has a very fast pace of change and it is innovating constantly. But remember, if the businesses don't buy your latest spec, it fails. A healthy respect and appreciation of your client's needs will only server software engineers and the IT industry in the long run.
  33. Don't ned enterprise design?[ Go to top ]

    And yes, 95% of applications being written using J2EE containers don't need an "enterprise" class container or enterprise designs. Its over engineering
    How many features of your cellular phone do you actually use? 10%?
    Why don't to throw it away to find something that fits better ;-)

    --
    Mike Skorik
  34. Don't ned enterprise design?[ Go to top ]

    How many features of your cellular phone do you actually use? 10%?
    Why don't to throw it away to find something that fits better ;-)
    It depends if the additional features make it very hard to make phone calls :-) True, in a well-designed phone, they won't...
  35. Don't ned enterprise design?[ Go to top ]

    EJB CMP? I think that everyone is entitled to his or her opinion on the subject. I just wish that this opinion were a result of sweat and tears working on large enterprise projects rather than on reading some articles and books on "J2EE" design.
    I was expecting Rod posting a little more here than he did, but if you want his opinion I guess you could read his excellent books. Based on my sweat and tears working for Fortune 500 companies and large healthcare companies EJB CMP is extremely hard to maintain and very difficult to troubleshoot. I have spent very many overnighters debugging, and testing, and debugging again, hoping that the nightmare would go away. Currently I am working at a Fortune 100 company and we are using Spring - one of the greatest products that open source ever produced. Simple and effective. Hibernate-Spring interfacing helps us with persistence and the first law of distributed applications (by Fowler) - "Do not distribute your applications" - is hard at work in our project.
  36. Don't ned enterprise design?[ Go to top ]

    EJB CMP? I think that everyone is entitled to his or her opinion on the subject. I just wish that this opinion were a result of sweat and tears working on large enterprise projects rather than on reading some articles and books on "J2EE" design.
    I was expecting Rod posting a little more here than he did, but if you want his opinion I guess you could read his excellent books. Based on my sweat and tears working for Fortune 500 companies and large healthcare companies EJB CMP is extremely hard to maintain and very difficult to troubleshoot. I have spent very many overnighters debugging, and testing, and debugging again, hoping that the nightmare would go away. Currently I am working at a Fortune 100 company and we are using Spring - one of the greatest products that open source ever produced. Simple and effective. Hibernate-Spring interfacing helps us with persistence and the first law of distributed applications (by Fowler) - "Do not distribute your applications" - is hard at work in our project.
  37. Realtive to ...[ Go to top ]

    The key sentence in the write up is :
    "I don't mean to run down Hibernate. I'm using it myself, right now "

    EJB's are better realtive to what?


    .V
  38. EJBs are here to stay[ Go to top ]

    Every technology has its advantages and disadvantages.After quantum rise Java fell back during last 2 years.But today it's growing and Java is everywhere.Same is happening with EJB.It is 1 of the most important requirement for distributed component object models.And Session beans may be more used everywhere but Entity beans have their own advantages.Or else one would hava to write all those code for persistense,transaction management and security which is now provided by the EJB container.
    So Entity beans are a flavour of their own and with EJB3.0 the ease of developing Enterprise applications will become much easier.
  39. ...Same is happening with EJB.It is 1 of the most important requirement for distributed component object models.And Session beans may be more used everywhere but Entity beans have their own advantages.Or else one would hava to write all those code for persistense,transaction management and security which is now provided by the EJB container.So Entity beans are a flavour of their own and with EJB3.0 the ease of developing Enterprise applications will become much easier.
    EJB's are silly. You can do everything you mention without them.

    They are way too hard compared to the problems they are trying to solve.

    And thats it really, they add hardship to the task of doing an IT solution. They steal joy and suck the intellect of the team into a meaningless morass of api's, lifecycles and compatability hell.

    But they do generate money for sun.

    Jonathan
    Emeraldjb - DAO for a simpler life.
  40. CMP Performance[ Go to top ]

    A benchmark from the Middleware Company showing that a CMP EJB solution significantly outperforms a JSP/Servlet only solution.
    http://www.gotdotnet.com/team/compare/middleware.aspx
    Yup, that's on a MS website.
  41. See the Drug use in the world...[ Go to top ]

    Now see! This is why drugs are bad. Once your brain is destroyed, you'll forever want EJBs. :)

    EJB suck, and hibernate doesn't suck as much. Actually the only thing that suck about hibernate is the poor documentation. The code is pretty solid, but something other than a reference book would be nice (yes this includes Hibernate in Action).

    Best thing about Hibernate - NO CONTAINER. It really does come down more to testing and quickly being able to determin if the configuration is correct. Hibernate is faster at this.
  42. I've never had a problem with EJBs. I use CMP beans at the bottom of all major business functions (that create or manipulate data) and with the use of a couple of design patterns they take me all of five minutes to write. They do what they need to do and I largely forget about the persistence layer. Instead, I spend ninety-nine percent of my time focussing on business logic. Am I missing something?
  43. Yes, it is better to optimize on "business logic", this stuff needs more abstraction than database. It must be better to optimize, abstract to forget about "business logic" layer and to spend ninety-nine percent of time on security, performance and maintainence.
  44. I've seen the comment several times that "EJB dosnt suck, all the people complaining are just mis-using it". Well, that may be true, but the question I have to ask is, if it gets misused that often arent we really looking at a brouder issue? Some times, we just need to sacrifice the sacred cow of "great concept" to make real progress. If you want to keep EJB as it, fine, but you need to rename it becasue all of use "average developers" out here have been told that ejb IS your persistance solution. Now when we all say "ok, but it sucks" you come back and say "thats becasue its not for you... your requirements are much too undane for the glory that is EJB". I reolized that these ideas are comming from different people. Unfortuanly the simple fact is that the market has said that what ever EJB happens to be, it is what we should be using for a persistance mechanizm. Therefor EJB has to change to become what the brouder audience needs, not what 0.1% of the market needs. If the final outcome is not what was originally inteneded, so be it. I think the guys who started the arpa net did not really forsee the internet.

    just my 2 cents