Home

News: Featured Article: What You Can Do With EJB3 (part one)

  1. EJB 3.0 has an early draft out for us all to look at. Gavin King has taken the ideas from the specification, and shows us how you can actually get your work done with EJB 3. He starts off discussing some use cases that the committee went over, and then goes into details of a sample Auction application.

    What You Can Do With EJB3 (part one)

    Threaded Messages (56)

  2. Hibernate is doomed?[ Go to top ]

    Maybe Gavin can also explain why one would even bother using EJB3 in a web application. I would argue that 90% of web applications do NOT need EJBs in any shape or form.

    IMHO, the article is just another attempt to pimp EJB (and hence Jboss/Consulting-services) and possibly is an indication that Hibernate is doomed long term (even HB site's front page is promoting EJB3!) That's very sad (we are using HB) but fortunately Apache OJB is picking up speed.

    Conclusion: separate your db access code from business logic, there's always a chance you may have to migrate to another persistence framework.
  3. Is not![ Go to top ]

    Nobody says that Hibernate 3 will be able to cooperate with the full-blown
    J2EE containers only. I assume that while it is intended as a backplane for JBoss EJB Entity Bean implementation, Hibernate 3 will still be capable of backing small (yet powerfull) web-container only apps.

    BTW, I'm really impressed by the simplicity introduced in EJB3.
  4. Hibernate is doomed?[ Go to top ]

    look at the roadmap
    Hibernate will not become dependent on or require a J2EE application server. With Hibernate3, we continue to innovate and spearhead the Java object/relational mapping field, without the burden of a specification
  5. I do not really think that having a specification to adhere to is a boring or annoying thing at all. Customers do need safety and stability, and these are the two main reasons that justify the need of a specification.

    As far as I am concerned, it has been useful having plenty different implementations and solutions to the OR problem, but now it is time to gather all the acquired knowledge and devise a solution that should be suitable to the majority of us, both in a managed and in a non-managed environment.

    What I mean is that EJB3.0 is a really appealing thing, but is "just a patch", not the final answer. The problem of persisting objects is one only problem, and there is no reason in facing it from many different perspectives (EJB3.0, JDO2.0, OJB, Hibernate, TopLink, etc.).

    In my opinion there is no more space left for "out of standard solutions", and there is a strong need to have the EJB3.0 and JDO2.0 come to one final solution to the problem, a solution whose primary purposes should be:
      
    1. ease of use
    2. transparency
    3. suitability both in a managed and unmanaged environment
    4. flexibility in the query language(s) (try to fully support raw SQL too even if I know this might not sound good to someone, maybe I am amongst these ones)

    This is my humble point of view,
    Francesco
  6. 1. ease of use
    2. transparency
    3. suitability both in a managed and unmanaged environment
    4. flexibility in the query language(s) (try to fully support raw SQL too even if I know this might not sound good to someone, maybe I am amongst these ones) This is my humble point of view, Francesco
    I think 3 and 4 are more important than 1 and 2, 1/2 sounds like plain populism and learning can solve this problem without any standard.
  7. 1. ease of use 2. transparency3. suitability both in a managed and unmanaged environment4. flexibility in the query language(s) (try to fully support raw SQL too even if I know this might not sound good to someone, maybe I am amongst these ones) This is my humble point of view, Francesco
    I think 3 and 4 are more important than 1 and 2, 1/2 sounds like plain populism and learning can solve this problem without any standard.
    I partially agree with you. By "transparency" I mean that persistency should be achieved seemlessly. I.e. persistent classes should not contain references to classes belonging to the O/R framework, developers should be able to move them across the tiers of their environment and so on. These are topics already addressed by the JDO spec., and now EJB is moving in this direction too.

    As far as "ease of use" is concerned, I agree with you, it is just a matter of learning.

    Francesco
  8. I saw term "transparency" is used to motivate "easy to use" and to hide data access, but I agree with you if we are talking about model reuse in any layer .
  9. Finally![ Go to top ]

    I am seeing the light at the and of the tunnel after so many years
    of waiting. I am extremly happy to see that ELB spec publishers
    have listened to the community.
    I am also extremly pleased to see that people like King are
    buying into it. It gives me more hope that we'll finally move closer
    to well rounded, powerful and easy to use J2EE spec. It was about time.
    I like JavaBean like implementation, and injections seem easy enough. I think
    that even beginners will find it easier to use (maybe too easy).

    I am really looking forward to implement
    solutions following this spec.

    Thank you for your attention,
    Edmon Begoli
  10. Now, show me the road maps[ Go to top ]

    I really appreciate what folks behind Hibernate, iBATIS, Spring and other solutions have done with their excellent frameworks.
    Looking at the EJB 3.0 it seems that lots of good ideas
    have made their ways into the spec.

    What immediately comes to my mind is that transition or compatibility road map is needed for the implementers that plan to use EJB 3.0, but today have to build their apps based on the best available frameworks.

    Best regards,
    Edmon Begoli
  11. Is there some place for asynchrnous method calling in the new EJB model?
    If it has been considered, I hope it stays simple and avoids the weaknesses inherent to the current .NET aRMI paradigm.
  12. Asynchronicity[ Go to top ]

    Is there some place for asynchrnous method calling in the new EJB model?
    This has been discussed in the group, and a number of us are *very* keen on the idea. I won't say much more about it, since we did not finalize a proposal, and I don't wanna be slapped down by Linda for speaking out of turn ;-)

    If you want it, feel free to make a bunch of noise about it! :-)
  13. Hibernate is doomed? Yeah, right...[ Go to top ]

    Maybe Gavin can also explain why one would even bother using EJB3 in a web application. I would argue that 90% of web applications do NOT need EJBs in any shape or form.
    Well, I guess I think I did .... you would use EJBs to get O/R mapping, dependency injection, declarative transaction and persistence context management, efficient replication or server-side state, caching, asynchronicity, a simple standard programming model, etc.

    But let me undermine the assumption of your question: why *not* use EJB, if EJBs are now just simple JavaBeans? Your question assumes that there is some heavy cost to using EJB, which there is not, in EJB3.
    IMHO, the article is just another attempt to pimp EJB (and hence Jboss/Consulting-services)
    Oh you saw straight through me. What happened was that representatives of Sun, BEA, IBM, Oracle, Sybase, Open EJB, etc, sat down with us and we all figured out a way to help JBoss to sell some more consulting services. This despite the fact that consulting is not really at the core of JBoss' business model (we make money from support contracts), and hence complexity is not really in our commercial interest.

    Can I just ask, out of curiosity, why did you type that? Did you really believe something so absurd, or does it just make you feel good to insult us?
    and possibly is an indication that Hibernate is doomed long term
    Heheh. You guys have been predicting Hibernate's demise since we first joined JBoss. Since that time, activity on our website has trebled (we just had yet another record month) and we have just kept pushing new releases out the door. (Hibernate3 alpha coming soon!) TSS comments are now *such* a reliable reverse indicator that an almost surefire way to predict the next successful technology is to look for what is currently most hated on on TSS. ;-)
    Conclusion: separate your db access code from business logic, there's always a chance you may have to migrate to another persistence framework.
    Well, I certainly agree with the *conclusion*. In fact, we have been advising that for the past three years, and we say excactly that in our book. (Though we have much more sound reasons for /reaching/ that conclusion.)

    On a more serious note, the EJB group put out an early release of the spec so that we could solicit useful feedback from the community. Please download the spec and actually read it, and let us know what needs improving. You guys have an unprecedented opportunity here to influence the EJB spec - we *are* listening to feedback, and we *do* care about the end users. Useful feedback does not mean personal attacks on the people or companies behind the spec, it means suggestions and thoughtful criticisms of the details of the spec. Thanks in advance!
  14. Hibernate is doomed? We'll see ...[ Go to top ]

    But let me undermine the assumption of your question: why *not* use EJB, if EJBs are now just simple JavaBeans?
    That's simple. EJB, like any other technology, must justify its existence. Almost everything you mentioned as reasons to use EJB could be simpler/better/cheaper done with POJOs + Hibernate + Spring. Some stuff you mentioned is just plain useless in practical terms (e.g. declarative transactions).

    So, the bottom line is that EJB solution is more complex, less portable, potentially more expensive and introduces dependency on EJB container where there's no justification for it. Besides, the alternative (POJOs + Hibernate + Spring) is available now with no need to wait 1-2 years until the spec is finalized and the implementation is available.
    Can I just ask, out of curiosity, why did you type that? Did you really believe something so absurd, or does it just make you feel good to insult us?
    Actually, I have a tremendous respect for your work on Hibernate. However, it appears to me that people who in one way or the other are related to the sale of EJB containers are pushing them without regard for technical merits (like they've been doing for many years).

    Seeing HB developers pushing EJB3 seems to me as strange as if JBoss would start promoting Apache's Geronimo.
  15. Almost everything you mentioned as reasons to use EJB could be simpler/better/cheaper done with POJOs + Hibernate + Spring. Some stuff you mentioned is just plain useless in practical terms (e.g. declarative transactions).

    So, the bottom line is that EJB solution is more complex, less portable, potentially more expensive and introduces dependency on EJB container where there's no justification for it.
    So I guess you're utilization of Spring and hibernate don't introduce dependencies on Spring and Hibernate? It seems to me that spring is a container of beans in much the same way an EJB container contains beans. Maybe you're referring to the ability to deploy and EJB in a J2EE server. Correct me if I'm wrong but I don't believe there is any requirement stating that EJBs must be deployed in a J2EE server though EJBs have traditionally been looked at that way. It will soon be possible to deploy Spring ApplicationContext's as JMX beans onto application servers. To me it is just two different technologies that are working to accomplish the same goal but are doing so from two different directions.

    I'd much rather produce dependencies on a standard where several implementations exist from several venders then from a single organization and a single technology. I look forward to EJB3 but for the mean time I am enjoying Spring.

    Mike
  16. Good replies, Mike and Gavin. Nice to see that there are still people here that manage to create insightful posts devoid of negative prejudgements and/or insults.

    As for using Spring (or any other lightweight container) vs. EJB3, I don't understand all those who whine about Spring being superior, more lightweight(?) and ready now, and so on and so forth. Apart from being not true, that is, to me at least, a completely moot point.

    To me, EJB3 is the final proof that lightweight and agile is good and that Rod Johnson and all other proponents of this were right all along. EJB3 will NOT be a competitor to Spring, EJB3 will be the standard that Spring will adhere to and implement (in a very competent way), apart from all its other features. I don't understand what's so problematic with that.

    The agile part of the Java industry has turbo injected ;) a standard that would have taken the standard "find a problem for a solution" way of doing things many years longer (and might still not have gotten it right).

    And, not to forget, the customers will once again be able to base their IT strategy and investemens on a standard, and then go out to find the best implementation at that point in time, possibly changing the latter down the line. Once again, what's the problem with that?

    Cheers, and to all you guys (and girls) behind the EJB3 spec, keep up the good work!

    /Par
  17. Hibernate is doomed? We'll see ...[ Go to top ]

    Almost everything you mentioned as reasons to use EJB could be simpler/better/cheaper done with POJOs + Hibernate + Spring. ... Besides, the alternative (POJOs + Hibernate + Spring) is available now with no need to wait 1-2 years until the spec is finalized and the implementation is available.
    Well, continue to develop with Hibernate + Spring and if you'll ever need the other XX% from J2EE that doesn't mean EJB than consider using Geronimo. They are working on providing Geronimo support for Spring so that you can for example hot deploy your Spring container. As Dion says in his blog, Geronimo 'brings us freedom' :-)
    However, it appears to me that people who in one way or the other are related to the sale of EJB containers are pushing them without regard for technical merits (like they've been doing for many years).


    Stop whining about that. There are at least two production ready free J2EE containers right now and the third (Geronimo) is coming fast. You don't have to buy anything from the guys that are pushing EJB tech, but maybe one day you'll be happy that standards exist and you can deploy your web application in a better container, even a commercial one.
    ... as strange as if JBoss would start promoting Apache's Geronimo.
    Actually that wouldn't be such a bad move since Geronimo will rock JBoss any time in any way you can imagine :-))
  18. Hibernate is doomed? We'll see ...[ Go to top ]

    Seeing HB developers pushing EJB3 seems to me as strange as if JBoss would start promoting Apache's Geronimo.
    I agree. Why is Gavin promoting EJB3?
  19. Why?[ Go to top ]

    Why is Gavin promoting EJB3?
    Because what happens with mature technology is it becomes standardized. Because we believe in POJO-oriented solutions, and it's time there was a compelling standard for that. And because I think EJB3 will be actually Good.

    Also, because it establishes a truly fantastic precendent to see ideas that were developed and innovated in the OSS community become part of the JCP standards. And to demonstrate that the OSS community can work with the big vendors to come up with great stuff.

    Finally, if this is a question about my *personal* motivations: Remember, I have a very different background to some of you guys. It's just great that you get to use things like Spring and Hibernate and experiment with sexy new open source stuff. But I used to wear a suit and sit in a cubicle, and worked for very conservative, IBM-centric IT organizations, where technology decisions where made by very risk-averse markitecture guys who did not really pay much attention to young geeky guys like me and you. There are a *lot* of people out there still struggling with EJB 2.x. There are a lot *more* of them, in fact....
  20. Why we need EJB?[ Go to top ]

    GK: "you would use EJBs to get O/R mapping, dependency injection, declarative transaction and persistence context management, efficient replication or server-side state, caching, asynchronicity, a simple standard programming model, etc."

    Is this useful and an effiecent way to solve it? I only want to do CRUD simply and powerful. Above seems like techies at play. You can just use collections instead of beans (Struts supports collections based Forms). I for sure do not need O/R, when a collections works and is less code.

    Using SQL I can do realistic and efficent querries, for example corelated. That is why lots of people use JDBC, even silly JSF uses RowSet.

    I just want EG to be aware that... sometimes we need less technology.

    .V
    (I use the simple SQL based iBatis which does not force O/R, lots of messages on this topic, just click on my name)
  21. Why we need EJB?[ Go to top ]

    That is why lots of people use JDBC, even silly JSF uses RowSet. I just want EG to be aware that... sometimes we need less technology..V(I use the simple SQL based iBatis which does not force O/R, lots of messages on this topic, just click on my name)
    I will not be surprised if EJB4 will look like IBatis or Voruta.
  22. Hibernate is doomed?
  23. light-weight persistence engine?[ Go to top ]

    EJB3 seems great with its simplified persistence development.
    However, I'm afraid it's only a beautiful dream for a long time.
    Is there any concrete persistence engine that is really light-weight and really light-cost? Or everything is tied tightly in the J2EE container?

    I just worry that J2EE market is dominated by few giants and light-cost implementations seldom survive successfully.
  24. Hibernate is doomed?[ Go to top ]

    I don't think that Hibernate is doomed, rather that hibernate can naturally fit into EJB 3 persistence scheme as a simple way to implement new persistence features, besides EJB it isn't only about persistence.

    I must say I was a bit sceptical about that IoC a.k.a DI thing at the very beginnig - but then I used to implement few spike projects using spring and hibernate and now I'm addicted;). Currently I can't wait for first EJB 3 implementations.

    Back to persistence layer in EJB, it looks very much like hibernate (which is very good IMHO), but I wonder whether EJB 3 resolves some issues I've with HB 2, namely:

    * Looks like we map types (via annotations) rather than concrete entities. This approach is, of course, simple but sometimes insufficient. Anybody knows if there will be some kind of "named entities" known from upcoming HB 3? (the way to have multiple, different mappings for single class).

    * I wonder how we could map parent-child relationship? In Gavin's example it looks simple. In hibernate, for instance we should have "inverse" link from Bid to Item, set in Item - see hibernate description of parent-child (here is reasonable explaination why we have to do things this way). I cannot imagine how EJB 3 can map this kind of relation without (kind of) "inverse relationship" for simple POJOs. Could anybody explain this?

    Artur
  25. Hibernate is doomed?[ Go to top ]

    Web applications are applications with a web UI. So do 90% of applications NOT need EJBs? Probably.

    But a lot of enterprise applications have web interfaces. When the application has logic that is "orthogonal" to HTML display, it is good design to separate that logic from the web interface.

    I'd say the number one reason most "web applications" do not use EJBs is not because they are not needed (or useful) but because the existing "application" being exposed to the web doesn't use EJBs because it uses older and/or better technology.

    What we need are useful objects that provide more than database mapping and text stream output.
  26. EJB is not 'central to J2EE'
  27. EJB ~ J2EE[ Go to top ]

    EJB is not 'central to J2EE'
    Building reuseable business logic is a central concern of J2EE developers. EJB is the J2EE standard for reuseable business logic.

    When J2EE was first concieved, EJB was considered a core part of the standard. Lets not forget that the whole "J2EE!=EJB" thing arose in response to *problems* with the EJB spec - problems which we are now fixing.
  28. EJB ~ J2EE[ Go to top ]

    EJB is not 'central to J2EE'
    Building reuseable business logic is a central concern of J2EE developers. EJB is the J2EE standard for reuseable business logic. When J2EE was first concieved, EJB was considered a core part of the standard. Lets not forget that the whole "J2EE!=EJB" thing arose in response to *problems* with the EJB spec - problems which we are now fixing.
    Yes but to claim EJB is 'central to J2EE' implies you cannot write a J2EE application without EJB. This is patently wrong.
  29. EJB != J2EE[ Go to top ]

    Building reuseable business logic is a central concern of J2EE developers. EJB is the J2EE standard for reuseable business logic. When J2EE was first concieved, EJB was considered a core part of the standard. Lets not forget that the whole "J2EE!=EJB" thing arose in response to *problems* with the EJB spec - problems which we are now fixing.
    There is more than one meaning of the term "reusable business logic".

    EJB's original intent was distributed components: reusable business logic in the sense of physical reuse, i.e. everybody accessing the same remote component instance at some physical place. While this is useful in some scenarios, 90% of applications don't need this at all. Local EJBs as introduced in EJB 2.0 were still clearly intended to run in servers: Clients that want to use that logic have to delegate to the corresponding server.

    Spring's central concern is reusable business logic in the sense of logical reuse, i.e. the same class can be instantiated and used in any sort of environment. The container is lightweight in the sense that it can be created like a library in any environment, be it in a web app on Tomcat, within an EJB, in a standalone application, or in a test suite. It is important to notice that EJB 3 still just targets one (or one and a half) of those scenarios.

    While EJB 3 looks similar to Spring in terms of the implementation model, it is still about components deployed to a J2EE server, to be looked up by clients via JNDI. The EJB 3 EntityManager is inherently tied to JTA and JNDI too, just supposed to work in a J2EE server. And all those components still run in their own EJB class loader, and need to be explicitly deployed in the form of an EAR. Everything else is not the intent of the EJB spec.

    Granted, an EJB 3 Session Bean and EJB 3 Entity Beans can be instantiated manually outside an EJB container. But all the services that the container offers are not available there: no declarative transactions, no dependency injection, no EntityManager for actual database access. Pure unit tests may be possible, but live tests still aren't, and neither standalone applications nor servlet containers like Tomcat can benefit from those services.

    So all things considered, the differences between EJB 3 and Spring are *not* moot: The former provides its services only within an EJB container, just allowing for reuse of the naked classes outside of it. Spring on the other hand can provide its services (like declarative transactions and dependency injection) in *any* environment, just like plain old Hibernate, OJB and JDO can provide their persistence services in any environment.

    An EJB 3 container also has to provide both the EJB 2.1 model and the completely different EJB 3 model. No new container will implement EJB 2.1, so no new container will ever be able to claim EJB 3 compliance. Furthermore, Spring does not mess with the class loader or separate deployment units: Why should it start providing an EJB class loader and require EJB jars, when it can provide so much within existing environments and deployment units (like WARs)?

    I do recognize the point that EJB 3 will make the life of developers in conservative environments easier, where all a developer ever gets is plain J2EE. However, many of those developers will have to continue suffering till 2007 and beyond: IBM may release an EJB-3-compliant WebSphere version earlier, but conservative environments won't update immediately. Why else are there still many WebSphere 4 and even WebSphere 3.5 environments around?

    Juergen
  30. Timing and binding[ Go to top ]

    Juergen, these are the key issues. Timing and binding. EJB3 annotations bind you to the services provided by the container. That's not an accident. The EJB vendors would not have it any other way. That's their cash cow.

    Further, you've got to wait for the opportunity to do EJB today. That's a painful proposition for the average EJB2 customer, who's struggling now. 2007 sounds about right to me.

    I'm telling my customers to adopt Spring plus a persistence alternative today. I recommend Hibernate for lightweight persistence, and Kodo for enterprise-level solutions with more advanced mapping requirements. Those customers will be more ready to migrate to an EJB3 solution than their counterparts running EJB2. I've got a hunch that once they adopt Spring, they probably won't need anything else that EJB3 has to offer.
  31. Timing and binding[ Go to top ]

    Nice say Bruce, cannot agree more :-). Many have been using Spring+Hibernate and it works well. I am not sure if I wanna venture into EJBs again unless its some direct order by above management.
  32. Timing and binding[ Go to top ]

    Bruce, stop making generalized statements! Stop handwaving! Come out of your book-writing corner and tell us what is so bad about Hibernate and why it is not "enterprise level". I think some techical arguments would be interesting for all of us.
  33. Timing and binding[ Go to top ]

    There is nothing technically wrong with Hibernate in enterprise usage. Most of the time the enterprise operations simply don’t allow open source stuff in their production servers due to various non-technical reasons. That’s my experience.

    Pratheep P
  34. Hand-waving[ Go to top ]

    Bruce, stop making generalized statements! Stop handwaving! Come out of your book-writing corner and tell us what is so bad about Hibernate and why it is not "enterprise level". I think some techical arguments would be interesting for all of us.
    Can we have this in another thread, please? Funny I should say that, but this thread is about what you can do with EJB 3, not another incarnation of Hibernate vs JDO vs your-persistence-framework here.

    For the record, Bruce only stated what he recommends to his customers--what he recommends to his customers is his problem, what you recommend to your customers is yours. I can't see any statement saying that Hibernate is not enterprise-ready in his post (I'm not saying it is, I'm not saying it isn't). A discussion on this may be interesting, but should probably be in a different thread.

    It might be useful to note that tool selection usually involves more than technical aspects, so a purely technical discussion will not help either.
  35. Timing and binding[ Go to top ]

    I would also like a clarification.
    I'm telling my customers to adopt Spring plus a persistence alternative today. I recommend Hibernate for lightweight persistence, and Kodo for enterprise-level solutions with more advanced mapping requirements.
    What defines "enterprise-level solutions" and "advanced mapping". I am assuming that you feel there are some pesistence requirements where Hibernate falls short and Kodo does not. Can you give a use case that demonstates this?

    Ryan
  36. reusable business logic[ Go to top ]

    EJB is not 'central to J2EE'
    Building reuseable business logic is a central concern of J2EE developers. EJB is the J2EE standard for reuseable business logic.
    The business logic of a system is almost by definition that part of the system that is most highly specific to the application at hand. The whole idea that underpins EJB - namely that an entity bean can be viable unit of reuse or "component" in the true sense has proven in practice to be a complete falacy.

    The whole reason why there is a huge backlash against entity beans in particular (and indeed the reason for the roaring success of the likes of Hibernate) is because the vast majority of appication only need security and transaction control at the boundary of the model - inside the model all people want is the cleanest most powerful persistence mechanism possible.

    "reusable business logic" - that on earth is that ?.

    Paul C.
  37. http://www.hibernate.org/About/RoadMap
  38. This is some very interesting stuff. I appreciate the move towards simplicity, especially with injection and things like message driven beans.

    One thing that I hope they keep diligent about is allowing for options in specifying the descriptors. While it's better to have the option of both annotations and external deployment descriptors, it would be a grave error IMHO to remove the ability to use deployment descriptors completely in favor of annotations. Annotations are nice and all but they can be overused and are just as coupling as javax.ejb interfaces. The .NET equivalent requires you to import the necessary attribute (annotation) before using it, which is no different than importing a necessary interface and using that. It's a different kind of coupling but a coupling nonetheless. External descriptors are nice (as Hibernate shows) because they totally remove the details of something (in this case, persistence) from the classes it affects. Hibernate descriptors are external to classes, and managed by hibernate, and so the classes themselves don't need to know anything about persistence, hibernate, or anything outside of their own object model. When you start combining different ways of working with things, such as XML serialization markup and persistence markup, the use of annotations can get very cluttered and the web of dependencies very much more complex than necessary.

    Not to say that annotations won't be useful in some cases, just not all. I sincerly hope they make the use of annotations and external descriptors equal class citizens in the new spec.
  39. The support for dependency injection is useful but can it be used with non-EJB components?

    I stopped writing monolithic session beans a long time ago. I would, for example, move the query to find the items into a repository class (see http//www.domaindrivendesign.org), e.g. ItemRepository.getItemSummaries(). The session bean would then be configured with the ItemRepository through dependency injection. I would also want to configure the ItemRepository with the EntityManager through dependency injection. I can do this today with JDO/Hibernate and Spring/PicoContainer. Can I do this with EJB 3.0?

    Also, what about being able to test the persistent classes outside of the container as you can today with JDO or Hibernate?

    Chris
    http://chris-richardson.blog-city.com
  40. I just read the blog entry. Congrats to EJB30 expert group for such a programming model. I don't know if enterprise programming can get much simpler than this. It resembles so well what we're used to from Spring/Hibernate except that dependencies are expressed in annotations and not xml context descriptors.

    Congrats to the Spring team for bringing such a programming model to the 'unwashed masses' :-) (Well, some say that IoC, Dependency Injection etc. is not the merit of the Spring team. Indeed is not. People have been using IoC after they read GoF patterns book. It is their merit, though, that they have implmeneted it in such a nice way and gave it to us as an excellent open source project).

    I am sure that EJB 3.0 won't mean anything else for Spring than the posibility to run a Spring container in a EJB container(of course if you need such a thing). Geronimo has started it, who doesn't follow certainly doesn't have anything to gain.
  41. Drop the name EJB?[ Go to top ]

    Perhaps if the name 'EJB' was dropped then some of these arguments would go away.

    If Sun came out and said "EJB is now dead. We're doing something better and it's called XYZ". Everyone could then breath a sigh of relief AND we wouldn't need to think about backwards compatibility.

    There seems to be enough changes to justify a new name, not just a version increment.

    People could then compare EJB to XYZ instead of being tied to the past.

    -- Brian
  42. let ejb die[ Go to top ]

    We didn't need it.
  43. Are these still POJO's ?[ Go to top ]

    While I agree that writing EJBs this way is a lot better than before, and annotations are a good replacement for descriptors, I wonder what happened to the idea that EJBs should be POJOs, because following Gavin's article, they are not. The annotations tie them to their nature as EJBs (and are in some regard worse than XDoclet 'annotations' depending on when the annotations are evaluated, at compiletime or runtime). Since I haven't had the time to read the EJB3 draft spec yet, I wanted to ask whether there will be a way to use real POJOs with EJB3 (without annotations) ?
  44. No DTOs?[ Go to top ]

    Gavin,

    Your statement: No DTO's

    So each time when creating instance of entity it's exposed remotly as well?

    Because if not I don't get it how you can get rid of dto's in other case. If my domain model has "big" 1-m association I do not want to transfer half of database to the UI. It would be mouch better to transfer just "domain view" to UI not whole picture. So I do not agree that EJB 3.0 spec will help me to get rid of DTO's.

    PS: I just posted this message accidenly to other forum lol :)
  45. No DTOs?[ Go to top ]

    Gavin is right about DTO. If your client see only structs then you do not need any domain model in application, you have it in database. Model between RDBMS and client is something you need to maintain, but do not use it. Hibernate solves this problem without "remote entities", it has a lot of features to support it and I hope it is possible to use object model with hibernate without my additional data structures like DTO and without performance problems.
     I prefer to store static or dynamic data structures directly and to use "table" as domain model.
  46. No DTOs?[ Go to top ]

    I agree that it's a good aproach for some applications.
    But I think that in some cases it's good to have rich domain model as well, especially when you have business rules and constraints associated with that data.
    I don't see how EJB3 will help me to get rid of DTOs for such applications.
  47. No DTOs?[ Go to top ]

    I agree that it's a good aproach for some applications.But I think that in some cases it's good to have rich domain model as well, especially when you have business rules and constraints associated with that data.I don't see how EJB3 will help me to get rid of DTOs for such applications.
    Yes, it is very interesting for me too, but I see a lot of implementation problems. I like object model, it is much better in some cases (I think geometry is a good example), but I do not think it is a pragmatic way for my applications.
  48. EJBs and Technology Use[ Go to top ]

    Over the last couple of years I have made good use of EJBs in my EAI and data warehouse work. I found they perform quite well. I rarely do any front-end work so I can't address their use in web applications. While I find EJBs pretty straight forward to work with and maintain (at least as compared to my CORBA work), I welcome the new EJB 3.0 spec as a step in the right direction.

    I have been fortunate in my work in that I haven't been held down by task masters or evil vendors requiring that I use EJBs where they aren't required as apparently so many people have. In fact, the more choices I have for attacking a problem, the more I like it. I enjoy having a choice of Hibernate or Spring or JDO or EJB (or whatever). While each proponent might understandably want their particular technology to be the end-all solution, having a wide array of tools in my arsenal makes my work that much better. I look at J2EE as a collection of standardized tools and since I have yet to see a silver bullet solution that fits every situation I would like to see that toolset widen. Move EJB forward. Move JDO in. That sort of thing. Gavin is spot on - many companies are run by risk-averse individuals and so like accepted standards. Widen the accepted standards toolset and we're good to go.

    Thanks
    Ray
  49. bashing EJBs[ Go to top ]

    It seems funny to me to hear some people talk so negative about EJBs, when they never even tried using it more than a simple prototype, or maybe they have tried and failed. I agree Hibernate is a great product, but EJB is part of the J2EE standards, and yes EJB is part of J2EE. If you think differently, then let me ask you how you can build a J2EE compliant container (WebSphere, WebLogic, etc.) without implementing EJBs?

    In any case, EJB3 is definitely making a great stride for more industry support or use. They are learning a lot from projects like Hibernate and Spring. I applaud the people who are working on the specs, and I recommend all the naysayers to shut up and contribute more to the community and stop whining.
  50. Wow! I finally see light at the end of the tunnel.

    What a relief to see the move towards POJO persistence. I guess the EJB team finally realized that all complex things need to evolve from very simple things. Getting rid of complex deployment descriptors, home interfaces and making entity beans simple JavaBeans is something that will now tempt me to give entity beans another chance.

    I thought JDO had got right what the EJB guys had failed miserably at, but it looks like they have caught up.

    If I understand right, entity beans can now be used outside of a EJB container.

    Vijay
  51. Too bad they're not POJOs, at least in my opinion. When I see:
        private Long id;
    and
        @Id(generate=AUTO)
        public Long getId() {
            return id;
        }
        protected void setId(Long id) {
            this.id = id;
        }
    in both example classes it starts to look like they are not "Plain" objects anymore, but rather objects that know they're going to be persistent.
    I admit I haven't read the draft spec yet but, if this has to be done for every persistent class, shouldn't this raise a flag with someone that we have some redundant code that maybe should be in some base class (OK, I'll say it, a persistent base class, go on, flame me now)? I guess the bigger question is Why does a persistent class have to know its id or even that it has an id? I just want it stored in the database.
    Tony
  52. If I understand right, entity beans can now be used outside of a EJB container.
    You can use the entity bean classes themselves outside of an EJB container, but not the EJB 3 EntityManager, i.e. not the persistence service. So you can instantiate your persistent objects any way you please, but you won't be able to persist them outside of an EJB container...

    There might be some standalone EJB-3-compatible EntityManager one day, but that's clearly not the intent of the EJB spec. I assume that it won't be trivial to implement such a standalone thingy, given that the EJB 3 EntityManager concept is closely tied to JTA transactions.

    So for persistence that can be used both within a J2EE container and outside of it (Tomcat, standalone application, test suite, etc), you'll still have to choose plain old Hibernate, JDO, OJB, or the like. EJB 3 will *not* give you such a generic POJO persistence service.

    Juergen
  53. out of container[ Go to top ]

    Juergen, I guarantee you that it will be easy to get an out-of-container EntityManager.
  54. out of container[ Go to top ]

    Juergen, I guarantee you that it will be easy to get an out-of-container EntityManager.
    Well, maybe from JBoss' specific implementation, but not covered by the EJB spec, as far as I can see. And if there was an explicit focus on out-of-container usage, for what technical reason is the persistence service still part of the EJB spec then? (Remember that I asked this very same question on your blog right after Linda's announcement in Vegas?)

    Anyway, the EntityManager concept also has some technical limitations regarding out-of-container usage: It assumes a persistence context to be managed alongside the JTA transaction context of the container. I cannot see how it could work without such a context: It does not provide means for native resource and transaction management (in contrast to plain old Hibernate or JDO).

    Juergen
  55. out of container[ Go to top ]

    Juergen, I guarantee you that it will be easy to get an out-of-container EntityManager.
    Well, maybe from JBoss' specific implementation, but not covered by the EJB spec, as far as I can see. And if there was an explicit focus on out-of-container usage, for what technical reason is the persistence service still part of the EJB spec then? (Remember that I asked this very same question on your blog right after Linda's announcement in Vegas?)Anyway, the EntityManager concept also has some technical limitations regarding out-of-container usage: It assumes a persistence context to be managed alongside the JTA transaction context of the container. I cannot see how it could work without such a context: It does not provide means for native resource and transaction management (in contrast to plain old Hibernate or JDO).Juergen
    Juergen, I can assure you that this is one question you won't get an explanation, at least a technical one, from Gavin or other EJB3 EG members. So many have asked in TSS and other forums but there hasn't been any response. I can understand the debate on whether it should have been based on JDO or Hibernate-like approach as there can be convincing justifications for either approach. But the argument for moving the ORM persistence out of the EJB spec (and not limiting it to the EJB container just like JMS, JDBC etc.) is a no-brainer.

    Kalyan
  56. Out of container?[ Go to top ]

    Juergen, I guarantee you that it will be easy to get an out-of-container EntityManager.
    Gavin,

    very politely and with all due respect, I would like to suggest that this is beside the point.

    The EJB specification's objective, as far as I understand it (which, granted, may not be very far), aims to define interfaces and behaviour of server-side components (and with EJB 3.0 entity beans also of POJOs/POJIs) to be deployed _within_ a specified container.

    Being able to obtain something that runs out-of-container and implements the EntityManager interface does not mean that you can "use entity beans outside a container". Similarly, building something that invokes my SessionBean's methods outside an EJB container does not mean that I can use session beans outside the container.

    Kind regards,
    Oliver
  57. You can use the entity bean classes themselves outside of an EJB container, but not the EJB 3 EntityManager, i.e. not the persistence service. So you can instantiate your persistent objects any way you please, but you won't be able to persist them outside of an EJB container...
    I guess I got excited too soon!

    If I cannot persist the entity beans that I use outside of an EJB container, I am going to stick with my current philosophy of using a session bean wrapper around the business services that my apps provide, with JDO to manage my persistable business entities. I find tremendrous value in building rich application clients too (Swing-based) for testing, admin functions, power-user versions etc. that use the business services directly in a 2-tier architecture.

    POJO persistence just makes plain sense to me. I guess the JDO (and other similar) folks are still the ones who seem to have got it right.

    Vijay