Discussions

News: Comparing EJB2 and JPA: why?

  1. Comparing EJB2 and JPA: why? (37 messages)

    There are lots of articles and blog entries showing EJB2 container-managed entity beans and the new EJB3 equivalents using the Java Persistence Architecture. At the risk of being accused of whining: why? The only real strength EJB2 entities would have, compared to EJB3, is in tuning, mostly because EJB2 mandates familiarity with the XML deployment descriptors, making the learning curve for tuning much more shallow. I'm sure that tooling for application servers will compensate for this 'weakness' in EJB3 as demand for this feature increases. However, in terms of actual implementation, is there anyone who prefers EJB2 entity beans for any other reason besides application server compatibility?
    Simple explanation: if your application server doesn't support JPA, and you can't use an external implementation, EJB2 would be the default choice... except that EJB2 has many legitimate challengers in functionality, such as Hibernate, iBATIS, OJB, and a number of others, too numerous to mention.
    So why do people have so many EJB2-EJB3 comparisons? Why not show how EJB3 implements a given use case (avoiding the same old use case everyone else shows), or compare EJB3 to something actually closer to it in programming ease, like JDO or an object database?

    Threaded Messages (37)

  2. Maybe because the migration nightmare is closer and closer. I am really curious of how one would migrate complex business logic embedded in facade session beans from findByPrimaryKey and friends to PM operations. Maybe migration automation is possible for entity beans themselfs, but IMO persistence layer calls will be harder to migrate. Regards, Horia
  3. Maybe because the migration nightmare is closer and closer. I am really curious of how one would migrate complex business logic embedded in facade session beans from findByPrimaryKey and friends to PM operations.
    Customer cust = entityManager.find(Customer.class, pk); A common pattern for migration might be: * to change Entity Home interfaces into Stateless session beans. * to XML finder query declarations into named queries. EJB 3.0 QL is a superset of EJB 2.1 EJBQL. Hibernate has a few tools that would help with migration. Bill
  4. Do everyone like to migrate everything to somehting. Migrating really sucks. Why don't write a new application instead. I will be nuch cheaper anyway. Or just leave the application if it works. There should always be a strong reason to migrate. When migrating it's not only running a wizard, doing the big bang. As far as i know EJB2 is backcompatibel. Just move the old stuff to new server. Migrating is a complex, but i am sure that everyone want it to be easier.
  5. Why don't write a new application instead. I will be nuch cheaper anyway
    :)) really !? Maybe for a petsore kind of app. Tell this to eBay guys. I am sure they didn't know.
    There should always be a strong reason to migrate.
    Exactly. Regards, Horia
  6. Do everyone like to migrate everything to somehting.
    Migrating really sucks. Why don't write a new application instead.
    Perhaps because of the "Time To Market" concept? Just see what happened when netscape decided to do this.
  7. Apps that use stored procedures to do their backend stuff trade off speed vs. tying it to the backend. The C# petstore implementation went for speed. People who reported on it just looked at the speed numbers instead of digging deeper and understanding why (it's true of a lot of people nowadays who accept anything the talking heads on TV say w/o questioning it :-)
  8. Don't use EJB anything[ Go to top ]

    EJB2? EJB3? EJB20123? Here is a better idea: don't use EJB's. EJB's are grossly overwieght and slow. They don't reduce the amount of work you need to do. Remember the Java Pet Store versus .NET Pet Store? You wonder why Java, which has been found time and time again to outperform C#, lost the battle? Easy answer: EJB's.
  9. Re: Don't use EJB anything[ Go to top ]

    Well, in all fairness, the pet store "lost the battle" because the Java version wasn't intended to go to war. The pet store was an accumulation of patterns, not a "best practices" example, and as such went way over the top compared to the actual requirements. Therefore, blaming EJBs for the pet store's inappropriate use as a benchmark platform of any kind is unwarranted. EJBs were part of the collections of patterns. Those patterns make sense if the requirements call for them. At that, EJB3 is indeed a reduction of the amount of work you need to do, and they're not "overweight and slow," much less grossly so.
  10. Re: Don't use EJB anything[ Go to top ]

    Probably you are too old in EJB front...please come out of EJB 1.0 and better write few entity and session beans in EJB 3.0. Then you speak of performance...There are too many old java guys who never worked in recent versions and speak this nonsense always...
  11. Re: Don't use EJB anything[ Go to top ]

    Probably you are too old in EJB front...please come out of EJB 1.0 and better write few entity and session beans in EJB 3.0. Then you speak of performance...There are too many old java guys who never worked in recent versions and speak this nonsense always...
    I met EJB in 2001 and I thought it was not a wonderful spec. I already believed that EntityBean were, let's say it politically correct, not the best way to handle persistence. I already believed that persistence should have been POJO-like. And I don't think I was alone. After 5 (repeat with me, five) years of blood, sweat and tears (fortunately not mine) we have to hear that now EJB3 is this and this. A simple question arise: there was a real need to buy EJB1 and EJB2 to get EJB3? Are EJB3 spec managed by the same people of EJB1 and EJB2 ? Guido

  12. I met EJB in 2001 and I thought it was not a wonderful spec.
    I already believed that EntityBean were, let's say it politically correct, not the best way to handle persistence ... ...

    Guido
    Guido: What did you use for persistence back in 2001 in your Java applications? Anshuman

  13. I met EJB in 2001 and I thought it was not a wonderful spec.
    I already believed that EntityBean were, let's say it politically correct, not the best way to handle persistence ... ...

    Guido


    Guido:
    What did you use for persistence back in 2001 in your Java applications?

    Anshuman
    I used an in-house POJO-like solution. It was a hard (repetitive) work to write the persistence layer, but business layer didn't know anything about JDBC. Anyway, the point is not what I used. The point is that at that time, or even before, there was already TopLink or CocoBase (and many other). At that time Scott Ambler already wrote his articles on persistence. At that time Kyle Brown already wrote about distributed objects and the overhead when your remote objects are fine-grained. I mean, it was me, myself and I :) EJB had a different sponsorship. I think you catch the huge ($$$$$) difference. Guido.
  14. Re: Don't use EJB anything[ Go to top ]

    I met EJB in 2001 and I thought it was not a wonderful spec.
    I already believed that EntityBean were, let's say it politically correct, not the best way to handle persistence.
    I already believed that persistence should have been POJO-like.
    And I don't think I was alone.
    After 5 (repeat with me, five) years of blood, sweat and tears (fortunately not mine) we have to hear that now EJB3 is this and this.
    A simple question arise: there was a real need to buy EJB1 and EJB2 to get EJB3?
    Are EJB3 spec managed by the same people of EJB1 and EJB2 ?

    Guido
    Guido, the people who wrote the original EJB 1.x spec (none of whom were involved in the EJB3 expert group, AFAIK) did the best job they could, and came up with a model that seemed reasonable at the time (compared to other systems such as CORBA which existed at the time). It turned out that there were some real problems with EJB 1.x/2.x, but I recall that there were relatively few people actually saying this at the time. Now, five years later, with the full benefit of hindsight, it is easy to see the problems. I remember arguing the limitations of EJB 1/2 with my boss back in 2000, and, instead of just bitching about the problems, I decided to actually do something about it. Hibernate was first released in 2001, specifically meant as a fix to the problems with entity beans in a Java EE environment. In 2003 we started working with the EJB 3.0 expert group to bring the ideas from Hibernate back into the spec, to formalize our "fixes" into the standard. Later, other groups interested in persistence (primarily Oracle and Solarmetric) also got involved and brought their experience to the table. The Hibernate team regards EJB 3.0 as the culmination of the work we started back in 2001. EJB 3.0 embodies the cream of the ideas that are around now, in 2006, now that Java web application architecture is a _much_ better understood problem than it was in 2000.
  15. Re: Don't use EJB anything[ Go to top ]

    EJB 3.0 embodies the cream of the ideas that are around now, in 2006
    So a criteria api and components not being able to hold references to entities etc etc aren't needed afterall ? :)
  16. Re: Don't use EJB anything[ Go to top ]

    Personally, I think a criteria API would be a really valuable future addition to EJB persistence. When we originally laid down the roadmap for EJB 3.0, we thought that we had enough work to do without a criteria API.
  17. Re: Don't use EJB anything[ Go to top ]

    Personally, I think a criteria API would be a really valuable future addition to EJB persistence. When we originally laid down the roadmap for EJB 3.0, we thought that we had enough work to do without a criteria API.
    +1 for Criteria API
  18. Re: Don't use EJB anything[ Go to top ]

    I agree - don't use EJB. Components are a good idea for clients but bad on the server. Servers are built better from services.
  19. Re: Don't use EJB anything[ Go to top ]

    Guido, the people who wrote the original EJB 1.x spec (none of whom were involved in the EJB3 expert group, AFAIK) did the best job they could, and came up with a model that seemed reasonable at the time (compared to other systems such as CORBA which existed at the time).
    See my previous post recalling Scott Ambler and Kyle Brown writings. On CORBA topic I have already expressed my opinions so I will not repeat myself.
    It turned out that there were some real problems with EJB 1.x/2.x, but I recall that there were relatively few people actually saying this at the time.
    Maybe there were few people at that time, just like now there are a few people saying that there are pb with SOAP/Web Services. I have a clear memory of the huge milestone in the architecture of distributed objects framework represented by CORBA 2.3 specs, with the revolutionary server-side portability layer. CORBA 2.3 was almost perfect, IMO, in catching the needs of server side development, introducing POA and Servants. And this happened in late '90s. Now, in 2006, Web Services are incredibly far from being comparable to CORBA. I have recently read an article about WS_Addressing and its wonderful capabilities of specifying a reference that can be intepreted by the target WebService in order to identify some internal resource. Wow ! When WS_POA ? It was really necessary to get JAX-RPC and JAX-WS to still work without POA/Servant-like concepts on the server side ? How many years should we wait for another Expert Group not reinventing the wheel on the n-th try ? Back to persistence, Gavin, do you really think that EJB1 Entity Beans was reasonable model to take into account with the knowledge on the topic at that time ? Guido
  20. Re: Don't use EJB anything[ Go to top ]

    "Now, in 2006, Web Services are incredibly far from being comparable to CORBA." I think I probably agree that WebServices is an inferior model to CORBA. I expect you will find many people in the industry with a lot of sympathy for that point of view - many of whom work on other technologies within the JCP. (Note that you can't really blame the JCP for WS-blah, since that stuff was mostly created outside the JCP. "Back to persistence, Gavin, do you really think that EJB1 Entity Beans was reasonable model to take into account with the knowledge on the topic at that time ?" Have you looked at the CORBA persistence service? At IBM's San Francisco? Yes, among the many systems around at the time, there were several better systems than EJB entity beans. For example, TopLink was a better solution, but note that the TopLink of the time was quite different and far inferior to the systems we have today. If I've got my history correct, I don't think TopLink was a POJO solution at that time (I could be wrong on that). Nor was the stuff described in the famous Scott Ambler papers a POJO-oriented approach. So, at the time, there were a number of different approaches floating around - none identitical to the approach that the industry has settled upon - and it was far from clear which was the approach that would have true staying power. It is clear now, with the benefit of hindsight.
  21. Re: Don't use EJB anything[ Go to top ]

    (Note that you can't really blame the JCP for WS-blah, since that stuff was mostly created outside the JCP.

    Yes, that's true. But JAX-RPC and JAX-WS are inside.
    Have you looked at the CORBA persistence service? At IBM's San Francisco?

    Yes, among the many systems around at the time, there were several better systems than EJB entity beans. For example, TopLink was a better solution, but note that the TopLink of the time was quite different and far inferior to the systems we have today. If I've got my history correct, I don't think TopLink was a POJO solution at that time (I could be wrong on that). Nor was the stuff described in the famous Scott Ambler papers a POJO-oriented approach.

    So, at the time, there were a number of different approaches floating around - none identitical to the approach that the industry has settled upon - and it was far from clear which was the approach that would have true staying power. It is clear now, with the benefit of hindsight.
    Obviously TopLink in now a better solution maybe because is the RI of JPA ? as JDO2 ;-) And at that time there was no pure POJO solution (well ObjectStore PSEPro was POJO but not an OR Mapper). But the outcome has been an architecture where every entity bean attribute access required a RPC call. And testing could take place only in a container. Let say it all, Gavin, JTA, JMS, JNDI are great specs. But if EJB was missing in J2EE I don't think that so many people would have felt the lack. Guido.
  22. Re: Don't use EJB anything[ Go to top ]

    Yes, among the many systems around at the time, there were several better systems than EJB entity beans. For example, TopLink was a better solution, but note that the TopLink of the time was quite different and far inferior to the systems we have today. If I've got my history correct, I don't think TopLink was a POJO solution at that time (I could be wrong on that).
    You couldn't be more wrong ;-). TopLink has always been POJO and hasn't really changed much in 10 years (except for the piles of extra features that were added). In fact, TopLink at the time of EJB 1.0 was still superior to the first release of JPA in terms of flexibility and extensibility, etc. but we all know that the role of the spec is not to have everything but the kitchen sink in it. When EJB 1.0 first came out TopLink created the first EJB 1.0 implementation that ran in the WebLogic Tengah server. Because our POJO architecture was far better than the entity bean one we actually had most of our customers stay with regular POJO TopLink instead of using CMP. In the meantime, while everybody else has been catching up with our O/R mapping features we have been doing other stuff, like a complete object-XML mapping layer including a JAXB implementation, advanced support for connector architectures, etc. The fact is that despite the existence of POJO persistence at the time, the EJB model was component-based and even though the company that created TopLink was on the specification group at the time, we were small and not able to convince the big vendors to go for lightweight persistence. Now, as Oracle and JBoss we were thankfully much more successful! That's the history lesson for today :-)
  23. Re: Don't use EJB anything[ Go to top ]

    Yes, among the many systems around at the time, there were several better systems than EJB entity beans. For example, TopLink was a better solution, but note that the TopLink of the time was quite different and far inferior to the systems we have today. If I've got my history correct, I don't think TopLink was a POJO solution at that time (I could be wrong on that).


    You couldn't be more wrong ;-). TopLink has always been POJO and hasn't really changed much in 10 years
    Then I stand corrected. I though the person I mentioned who had worked with early versions of TopLink for Java told me that TopLink required some kind of inheritance from special classes. Presumably he got that wrong, or my recollection is bad.
  24. Re: Don't use EJB anything[ Go to top ]

    Yes, among the many systems around at the time, there were several better systems than EJB entity beans. For example, TopLink was a better solution, but note that the TopLink of the time was quite different and far inferior to the systems we have today. If I've got my history correct, I don't think TopLink was a POJO solution at that time (I could be wrong on that).


    You couldn't be more wrong ;-). TopLink has always been POJO and hasn't really changed much in 10 years


    Then I stand corrected. I though the person I mentioned who had worked with early versions of TopLink for Java told me that TopLink required some kind of inheritance from special classes. Presumably he got that wrong, or my recollection is bad.
    That was my impression. I used Toplink a couple of years ago. You had to use, I believe, some special ValueListHolder or somesuch interface for things like collections. I personally didn't care for Toplink and went to Hibernate afterwards. Toplink's XML mapping was unreadable, the mapping tool tempermental. Their criteria API was, IMO, extremely hard to read, the documentation wasn't very good(not must my opinion, but the other developers). Using Toplink wasn't an experience I enjoyed. It just seemed to make easy things harder than necessary.
  25. Re: Don't use EJB anything[ Go to top ]

    I personally didn't care for Toplink and went to Hibernate afterwards.
    Ah, well. It goes both ways, I guess. We also see people coming from Hibernate to TopLink. The important thing is that developers can try things out for themselves and can choose on their own what they like and don't like. Please be careful about spreading misinformation about TopLink (or any other product for that matter) though. Thanks. -Mike
  26. Re: Don't use EJB anything[ Go to top ]

    I personally didn't care for Toplink and went to Hibernate afterwards.


    Ah, well. It goes both ways, I guess. We also see people coming from Hibernate to TopLink. The important thing is that developers can try things out for themselves and can choose on their own what they like and don't like. Please be careful about spreading misinformation about TopLink (or any other product for that matter) though. Thanks.

    -Mike
    I don't believe that I did that. I think that I just gave my impressions. Heck, I thought I heard that Toplink is now the the JPA reference implementation, so what do I know!!?! :-)
  27. Re: Don't use EJB anything[ Go to top ]

    Hibernate was first released in 2001, specifically meant as a fix to the problems with entity beans in a Java EE environment.

    In 2003 we started working with the EJB 3.0 expert group to bring the ideas from Hibernate back into the spec, to formalize our "fixes" into the standard. ... The Hibernate team regards EJB 3.0 as the culmination of the work we started back in 2001. EJB 3.0 embodies the cream of the ideas that are around now, in 2006, now that Java web application architecture is a _much_ better understood problem than it was in 2000.
    Well, since Hibernate was actually just released as a free scaled down version of TopLink, with persistent POJO's, Session and Query APIs, etc, and TopLink API predated Hibernate by a full 5 years, then it clearly was not the Hibernate design that fixed EJB ;-) It doesn't matter, now, though. Trying to take all the credit for EJB 3 was so last year.
  28. Re: Don't use EJB anything[ Go to top ]

    Well, since Hibernate was actually just released as a free scaled down version of TopLink
    Give me a break. I don't attack you or your product in public, why do you feel the need to attack mine. FYI, I had never even looked at TopLink when I first created Hibernate (though I did once work someone who had).
    then it clearly was not the Hibernate design that fixed EJB ;-) It doesn't matter, now, though. Trying to take all the credit for EJB 3 was so last year.
    As you are certainly well aware, you were not even a member of the EJB 3.0 expert group when we made the fundamental design decisions that changed the future of EJB. Of course, we welcomed you onto the expert group and appreciated the benefit of your experience. But it was not the success of Toplink that created the conditions for a total redesign of entity beans, nor was it Oracle who argued for that in the expert group. Please stop trying to minimize the role of JBoss in this work.
  29. Re: Don't use EJB anything[ Go to top ]

    Give me a break. I don't attack you or your product in public, why do you feel the need to attack mine. FYI, I had never even looked at TopLink when I first created Hibernate (though I did once work someone who had).
    No, I didn't assume that you calling TopLink of the time an inferior product was attacking our product, it was just incorrect. When TopLink was first released (5 years *before* that time) TopLink was quite scaled down. I know for a fact that when Hibernate was first released that it, too, had a scaled down feature set. I kind of think of Hibernate 3.0 as its real coming of age when it got many of its more slick and polished feature set. Sorry if that seemed like an attack, but my point was that the early Hibernate APIs were very similar to what at the time was a more advanced TopLink API. Also, I think that TopLink afficionados are perhaps a little sensitive about people thinking that Hibernate was the first POJO persistence product of its kind.
    Please stop trying to minimize the role of JBoss in this work.
    I was not trying to minimize the role of JBoss in this and a host of other spec work in the JCP, including the Java EE 5 platform which Scott Stark also spent a lot of time improving. Let me be clear so that you not think I am trying to minimize the JBoss role. JBoss drove an incredible amount of stuff into the Java EE and EJB 3 specifications that would not have been possible otherwise. The JCP owes a lot to the JBoss drive and specifically to the people at JBoss that contributed so much, and I say this in all sincerity. What I guess I have a problem with is when the message is repeatedly given that it was all about JBoss. So many other people worked so hard on it to leave them out. I hope that does not minimize the incredible amount of work that both you and I put into these specifications as well.
  30. Re: Don't use EJB anything[ Go to top ]

    Mike, the problem here is that you are jumping at shadows. The point of my post was: (1) To defend the original EJB EG, from criticism which is unfair (criticism of the spec is fair, of the EG, generally unfair). (2) To show that the people who created EJB3 were in fact a different group of people to the original EJB EG, and were in fact the same people who have continuously been working outside the spec and who criticized the original spec. I did this by relating my personal experience. (This was in response to a specific question by another poster.) The point of my post was not to take credit for anything. When I do talk about people who contributed to the EJB persistence design, I always mention Oracle (along with others). That was not the point here. We've seen this kind of pattern before: (1) Someone says EJB is crap and everyone should use Hibernate instead (2) I answer that Hibernate was extremely influential upon the EJB3 spec, and that EJB persistence is essentially similar to Hibernate (3) You get angry because I didn't talk about TopLink (4) I get confused because it was not _me_ who started talking about Hibernate, but the person I was responding to In this case it was actually me who first started mentioning Hibernate, but in the context of telling a story that I thought was relevant.
  31. Re: Don't use EJB anything[ Go to top ]

    Sorry, I probably didn't respond with the right blockquote or make clear the bit that I found unfair. It was the part that said:
    In 2003 we started working with the EJB 3.0 expert group to bring the ideas from Hibernate back into the spec, to formalize our "fixes" into the standard."
    If that is a shadow then I am happy for any light to be shed on it and fully dispel it. I just don't see that POJO persistence was an idea from Hibernate or that the "fixes" were yours. Don't want this to turn into a Groundhog Day of the stuff that you mentioned either, and I'm happy to let you have the last word as a response. -Mike
  32. Re: Don't use EJB anything[ Go to top ]

    Sorry, I probably didn't respond with the right blockquote or make clear the bit that I found unfair. It was the part that said:

    In 2003 we started working with the EJB 3.0 expert group to bring the ideas from Hibernate back into the spec, to formalize our "fixes" into the standard."


    If that is a shadow then I am happy for any light to be shed on it and fully dispel it. I just don't see that POJO persistence was an idea from Hibernate or that the "fixes" were yours. Don't want this to turn into a Groundhog Day of the stuff that you mentioned either, and I'm happy to let you have the last word as a response.

    -Mike
    Struts is much less well designed in the Web space than Hibernate2.1 in the persistence space, but still dominates other Web frameworks in the job market (aka how much the framework is used in the industry) and will continue to do so for a while (probably until the next down turn). IMHO Hibernate will have been better off without getting into the EJB3 saga. Then comes the economics. How would the Hibernate team have got paid? By joining Interface21? :-)
  33. Struts is much less well designed in the Web space than Hibernate2.1 in the persistence space, but still dominates other Web frameworks in the job market (aka how much the framework is used in the industry) and will continue to do so for a while (probably until the next down turn).

    IMHO Hibernate will have been better off without getting into the EJB3 saga. Then comes the economics. How would the Hibernate team have got paid? By joining Interface21? :-)
    Warning: flamebait detected. George, get some clue, if you'll try to attack someone, at least do it properly.
  34. Warning: flamebait detected.

    George, get some clue, if you'll try to attack someone, at least do it properly.
    Seems you tend to see things through negative glasses. Why don't see there might be some truth in the original statement?
  35. Re: Don't use EJB anything[ Go to top ]

    It turned out that there were some real problems with EJB 1.x/2.x, but I recall that there were relatively few people actually saying this at the time. Now, five years later, with the full benefit of hindsight, it is easy to see the problems.
    Not true. See http://www.theserverside.com/news/thread.tss?thread_id=4658
  36. Re: Don't use EJB anything[ Go to top ]

    Here is a better idea: don't use EJB's. EJB's are grossly overwieght and slow. They don't reduce the amount of work you need to do.
    _This_ is the reason people are still writing EJB2 vs EJB3 articles. Because some people out there have not yet got the message about how easy EJB3 is (and how non-slow and non-"overweight").
  37. I met with lot of people wondering how they will migrate from "nonEJB3-Hibernate" (hbm.xml and org.hibernate.*) to EJB 3 (persistence.xml and javax.persistence.*). Are there plans to provide some migration path in Hibernate itself? I found myself playing around with some real application migration and found some common practices (for the mapping I used a bottom up approach so I mostly had to migrate the hibernate Criteria, HSQL and Hibernate Session stuff). Has someone done similar work? Generally speaking this process was not that hard but I'd love to hear about others' experience. Alex
  38. A POJO clarification[ Go to top ]

    Since I have triggered the discussion on POJO and Toplink, I would clarify a little. I have deliberately used POJO-like term in my post, because I wanted mainly to point out the difference between a lightweight approach and the EJB one. With a lightweight approach you write your domain class. The requirement of deriving you model class from common base is not a real big issue. On the other side, persistence as enity beans required you to write 2 interfaces and 2 classes, deployment descriptors and all that paraphernalia we all know very well. Anyone can appreciate the difference of effort required during development/test/maintenance. In this sense, any discussion about how much a certain product was feature-rich or feature-poor or who is the father of whom is unimportant. Guido