Tech Talk: Mike Keith on the EJB3 Persistence API

Discussions

News: Tech Talk: Mike Keith on the EJB3 Persistence API

  1. In this talk, given at TheServerSide Java Symposium in March, Oracle's Mike Keith talks about the release of EJB3 and preparations around the release. Keith dispels the two large myths behind EJB3 and explains how EJB3 tackles persistence. Keith also discusses the best ways to prepare for the migration to EJB3. Other topics include: - Goals of the EJB3 spec - The influence of Spring and open source on EJB3 - The flexibility of the Java persistence API - EJB3's reference implementation - Vendor compliancy - Tool development Watch Mike Keith on the EJB3 Persistence API.

    Threaded Messages (29)

  2. I think EJB3 is barking at the wrong tree (persistence) if someone need POJO based persistence it is here right now: Hibernate, Cayene, JDO, Top-Link. What is needed: - short develop-deploy-test(debug) cycles - under 10 seconds from code change to seeing its consequences; - modular J2SE and J2EE; no more huge rt.jar please and monstrous app servers. It all should work as on demand deployed and configured modules. - guaranteed hot deployment: servers must not choke during redeployments under load – guaranteed; - more monitoring and management interfaces;
  3. Has anybody tried Hibernate EntityManager in a big project. I am using just one session bean as the controller + Hibernate and I am not sure whether it will stand the test of heavy traffic. http://www.skillipedia.com
  4. I think EJB3 is barking at the wrong tree (persistence) if someone need POJO based persistence it is here right now: Hibernate, Cayene, JDO, Top-Link.
    This sounds like the perfect moment to standardize - the products have been tried and tested by the public and innovation has (mostly) stopped. Standardization can begin, at least on the common subset of the features. Exactly the opposite than EJB 1.0 brouhaha.
    What is needed:
    - short develop-deploy-test(debug) cycles - under 10 seconds from code change to seeing its consequences;
    Up to the vendors to reduce startup overhead of app servers and up developers to slim their applications. EJBs, JSPs (and to a degree servlets) are as good module of deployment as you can get. It's usually application code that's at fault: configuration that can't be changed without restarting application coupled with heavy initialization (yay for Hibernate's "SessionFactoryImpl - building session factory" when you have >200 persistent classes). Devil's advocate: isn't code-test-fix development a swear word these days?
    - modular J2SE and J2EE; no more huge rt.jar please and monstrous app servers. It all should work as on demand deployed and configured modules.
    As far as memory usage goes, JAR size is irrelevant as classes are already loaded on demand. As for startup, J2SE will (probably) never be on par with non-VM languages without some sort of preloading. With J2EE it's again up to the vendors to make as tight runtime and startup procedures as possible. Can't see anything in the standard that can't be turned off unless needed by the deployed applications. "Size on disk" is a different matter, though. Unfortunately, on-demand downloading has its issues, such as firewalls, trusting download server and unpredictable load on network.
    - guaranteed hot deployment: servers must not choke during redeployments under load – guaranteed
    Up to the vendors. I know of one that did that for JEE 1.4.
    - more monitoring and management interfaces
    Up to the vendors, I'd say. Standardized set of JMX components would help providers of management software, but I've seen a lot of products with extensive support for major app servers.
  5. Devil's advocate: isn't code-test-fix development a swear word these days?
    Perhaps, but this is what I do whan I am not on a meeting :)
    As far as memory usage goes, JAR size is irrelevant as classes are already loaded on demand. As for startup, J2SE will (probably) never be on par with non-VM languages without some sort of preloading.
    It is not about memory, nor it is about disk size. Modularity is about manageability, incremental updates, and network bandwidth. For example GNU0-Linux distro can be installed as a very small set of core stuff and then it can easily grow to a begemoth _on demand_. Parts can be updated as needed. That is wery convenient and practical. Now imagine GNU-Linux will try to install everything (100 GB?), and then update everything (how about 50 GB update?).... but that is the Java way, on a smaller scale still, but we are getting there. In the language space Perl is a very good example: it does NOT try to provide everything, but provides an easy way of adding and maintaining modules (CPAN). IMO modular Java would beat Flash and Ajax on client.
    Up to the vendors. .... Up to the vendors...
    They do not do a good job I would say...
  6. The influence of Spring and open source on EJB3.
    Note Mike Keith was asked about the influence of Spring on EJB3 and he is only diplomatic here.

  7. Note Mike Keith was asked about the influence of Spring on EJB3 and he is only diplomatic here.
    Not sure what you mean. I said: "Spring ... definitely had a role to play". ... "It only made sense to take some of those practices, and incorporate them into a standard. So things like dependency injection have been talked a lot about, but there is no doubt about their value and these practices have indeed been incorporated into EJB3 as well as Java EE." Not sure how I could have been more clear. To add to this statement let me also say that Spring is offering complete JPA support, so it is not an either/or situation. You can now use Spring as a JPA Container and plug in the compliant JPA persistence provider of your choice. Many of the EJB 3.0 component annotations are also offered in Spring so they are obviously serious about it. -Mike
  8. TopLink vs JPA[ Go to top ]

    A while back I received some from information fron an Oracle product manager stating that they would be "recommending" POJO TopLink users to begin coding to the JPA spec, rather than the TopLink API. How accurate is this? And what TopLink specific features would not be available through JPA?
  9. JPA is not EJB3[ Go to top ]

    EJB123 is rubbish. Session, Entity, Message, Weblogic, Websphere, etc are all monolithic dot com leftovers. Spring is OK, but has many anti OO patterns embedded in its usage. JPA is pretty cool on the face of it, but is it better than hbm files? I've played, and I've talked to others who have used it more. The problem is that DTO's (Value objects) are no longer vanilla. You have annotations and business functions and bespoke annotations all crowding into a single class. Is a field mapped or not - search the code. This compares to large hibernate projects where people know the O/R layer is a set of hbms and once you are used to that there seems no point in changing. And I think thats the problem. JPA may be fab, but why bother. The best you can hope for is that it works as well as hibernate, but since it's new and has no critical mass then there is no proof. Jonathan ps All overstated, but just wondering if anyone left on TSS cares enough to argue.
  10. Re: JPA is not EJB3[ Go to top ]

    EJB123 is rubbish. Session, Entity, Message, Weblogic, Websphere, etc are all monolithic dot com leftovers.

    Spring is OK, but has many anti OO patterns embedded in its usage.

    [...]
    Could you please post further details about these statements?
  11. Re: JPA is not EJB3[ Go to top ]

    I have already added a statement sometime ago but i thought it would be a good idea to say it again..EJBs have had their days. EJBs try to be POJOs...but lets not forget Session beans and Messae Driven beans still need an EJB container to run in. The development of the lightweight container architecture is the way forward. Developing POJOs and applying declarative services such as persistance, security, logging makes development easier and easier to test and configure. Spring has offered loads of benefits in the Java/J2EE arena...more than EJBs. Spring's AOP, Persistance support, middleware support is great. Thanks Amin
  12. Re: JPA is not EJB3[ Go to top ]

    I have already added a statement sometime ago but i thought it would be a good idea to say it again..EJBs have had their days. EJBs try to be POJOs...but lets not forget Session beans and Messae Driven beans still need an EJB container to run in.
    Yes, EJB3 (excluding JPA) EJBs are the same EJBs as they were in EJB2, even thought they look like POJO. For people who havn't used EJB2 (or EJB1) before, the effect is even more confusing.
  13. Re: JPA is not EJB3[ Go to top ]

    Spring is OK, but has many anti OO patterns embedded in its usage
    I'd also be interested in more details about that. And what'd you mean with anyone left at TSS? hans
  14. Re: JPA is not EJB3[ Go to top ]

    Spring is OK, but has many anti OO patterns embedded in its usage
    I'd also be interested in more details about that.
    May I? 1. Proliferation of singletons. 2. Managing dependencies between objects is easier. So instead of eliminating them, you just hand them over to Spring. With those two forces in action, application can easily turn into a soup of interconnected objects, each one (transitively) depeneded on pretty much all of the rest. As always, if you pay extra attention, you can avoid that.
  15. Could you just clarify, are you saying that Spring leads to, or avoids, the proliferation of singletons. My understanding is the latter.
  16. Could you just clarify, are you saying that Spring leads to, or avoids, the proliferation of singletons. My understanding is the latter.
    It leads to. Prototype beans are very seldom used in practice.
  17. Could you just clarify, are you saying that Spring leads to, or avoids, the proliferation of singletons. My understanding is the latter.
    It leads to. Prototype beans are very seldom used in practice.
    I forgot to describe the most blatant abuse of singletons that Spring facilitates: proliferation of utility classes. This can be done only with custom Spring beans (doh). Those are classes that contain only some procedures and very little state. What state object they may need are injected at start and don't change much afterwards. Their names usually end with "Worker", "Configurer" or the dreaded "Manager". It's also possible to go hog-wild with Strategy patterns, which usually does more harm than good. As before, this is all avoidable, if you think a bit about overall picture and don't use Spring for Spring's sake.
  18. Hi Bostjan,
    I forgot to describe the most blatant abuse of singletons that Spring facilitates: proliferation of utility classes. This can be done only with custom Spring beans (doh).... As before, this is all avoidable, if you think a bit about overall picture and don't use Spring for Spring's sake.
    This is a bit unfair on Spring, especially in comparison to EJB's. Alexandre has explained quite eloquently what Singleton means in the context of Spring. It means a single object instance created and served by a given bean factory. The bean factory itself does not necessarily have application scope also there could be several factories each with it's own single object instance. Hence a Spring Singleton is not necessarily a single global application instance. Of course through mis-application you can perform a number of nasties with Spring or with any Framework, but unlike EJB's these nasties are not mandated :^). Paul.
  19. Hey, people do still care! Hurrah. OK, EJB123 is dead. Spring is FANTASTIC by comparison. However, as a friend said, java coding used to be fun, with spring xml coding it's not. Which I think is a fair assesment. IOC is fab, but config of the system should be just that - config; database names, port and host names, pool sizes etc. The fact is that changing the wiring config in prod via changing the implementation (coding to interfaces for ioc/dep inj) is very rare. And non existant if you think about changing prod without an entire build/test/deploy cycle (OK, we did switch out a dead cache once, but all that work for a single useful time is not good return on investement). So all the XML autowiring stupidity is just that. It was a response to the fact that EJB was rubbish, and xml was and is still in fashion. Using XML as a post compilation stage to make code hang together is rubbish. As for the anti-OO pattern stuff, I'll let others add to the list. Although I did have one wierd thought - maybe the principles of OO stem from useless IDE's about 20 years ago. Nowadays those principles of encapsulation, cohesion and so on are less important, we let the IDE to the symbol chasing. When I used to join a project with a large code base I always used to dive into the object model. Nowadays I use the IDE to walk though symbol trees. i.e. the tools are alot better. The object model is less interesting. Personally I love OO, but it was a thought. Jonathan
  20. OO, What do you mean?[ Go to top ]

    Hi
    As for the anti-OO pattern stuff, I'll let others add to the list. Although I did have one wierd thought - maybe the principles of OO stem from useless IDE's about 20 years ago. Nowadays those principles of encapsulation, cohesion and so on are less important, we let the IDE to the symbol chasing. When I used to join a project with a large code base I always used to dive into the object model. Nowadays I use the IDE to walk though symbol trees. i.e. the tools are alot better. The object model is less interesting. Personally I love OO, but it was a thought.
    Don't get me on to this subject. Unfortunately, knowadays OO is just a marketing term; and a marketing term past it's sell by date at that. There was a time that if your product didn't have OO in the title it wouldn't sell. So OO 'C' (C++), a better OO 'C' (Java), distributed OO (CORBA, COM etc), a better distributed OO (RMI, EJB's). The funny thing is that everyone forgot to ask the guy who invented the term in the first place:
    I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind" - Alan Kay, OOPSLA '97
    As a consequence OO has managed to tarnish it's name although 99% of people who talk of OO do not know what Alan Kay meant by it. In our "top of the pops" culture I can see the same happening to "Agile" and another powerful idea turned into marketing fodder. Fortunately, all is not lost, and the language archive is still there (Smalltalk, LISP etc), so the orginal ideas can still be resurrected by anyone who cares, even if it means going back to the future:
    "The best way to predict the future is to invent it" - Alan Kay
    Which is why I wish Matz and the Ruby community all the best. Paul.
  21. Re: OO, What do you mean?[ Go to top ]

    As a consequence OO has managed to tarnish it's name
    I don't think that's true. I got OO from all the books circa 1990-1992 I think. Booch et al. So that's what I meant by OO. Never went down small talk or eifel(sp) as they never got the critical mass that interests me. Jonathan
  22. Re: OO, What do you mean?[ Go to top ]

    As a consequence OO has managed to tarnish it's name


    I don't think that's true. I got OO from all the books circa 1990-1992 I think. Booch et al. So that's what I meant by OO. Never went down small talk or eifel(sp) as they never got the critical mass that interests me.

    Jonathan
    I'm glad to hear it. I'm not sure that everyone would agree though. BTW on Grady Booch (an opportunist if ever there was one :^)), some one forgot to tell him that you don't need Classes or Inheritance for OO and Classes/Inheritance (classification) isn't what it's all about. I read his book too, had me confused for years until I came across Smalltalk. IMO there are many others who are either: a) Still confused, but too embarrassed to admit it. b) Have come to there own understanding and acceptance of a degenerative form of OO. Paul.
  23. Re: OO, What do you mean?[ Go to top ]

    I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind" - Alan Kay, OOPSLA '97
    He was always _so_ humble. ;-) Peace, Cameron Purdy Tangosol Coherence: Clustered Shared Memory for Java
  24. Re: JPA is not EJB3 - Singletons?![ Go to top ]

    +1
    Could you just clarify, are you saying that Spring leads to, or avoids, the proliferation of singletons. My understanding is the latter.
    It leads to. Prototype beans are very seldom used in practice.

    I forgot to describe the most blatant abuse of singletons that Spring facilitates: proliferation of utility classes. This can be done only with custom Spring beans (doh).

    Those are classes that contain only some procedures and very little state. What state object they may need are injected at start and don't change much afterwards. Their names usually end with "Worker", "Configurer" or the dreaded "Manager". It's also possible to go hog-wild with Strategy patterns, which usually does more harm than good.

    As before, this is all avoidable, if you think a bit about overall picture and don't use Spring for Spring's sake.
  25. Re: JPA is not EJB3 - Singletons?![ Go to top ]

    This is what is (sadly) promoted in SOA, where the system organized using a bounch of stateless session beans.
    Could you just clarify, are you saying that Spring leads to, or avoids, the proliferation of singletons. My understanding is the latter.
    It leads to. Prototype beans are very seldom used in practice.

    I forgot to describe the most blatant abuse of singletons that Spring facilitates: proliferation of utility classes. This can be done only with custom Spring beans (doh).

    Those are classes that contain only some procedures and very little state. What state object they may need are injected at start and don't change much afterwards. Their names usually end with "Worker", "Configurer" or the dreaded "Manager". It's also possible to go hog-wild with Strategy patterns, which usually does more harm than good.

    As before, this is all avoidable, if you think a bit about overall picture and don't use Spring for Spring's sake.
  26. Re: JPA is not EJB3[ Go to top ]

    Spring is OK, but has many anti OO patterns embedded in its usage
    I'd also be interested in more details about that.
    May I?

    1. Proliferation of singletons.
    2. Managing dependencies between objects is easier. So instead of eliminating them, you just hand them over to Spring.

    With those two forces in action, application can easily turn into a soup of interconnected objects, each one (transitively) depeneded on pretty much all of the rest.

    As always, if you pay extra attention, you can avoid that.
    Singletons in Spring aren't Singleton in the sense of the pattern but a container managed single instance of an object. The creation is delegated to the IoC container, the object doesn't hold the reference itself. A IoC container is a creational pattern as a factory and builder are ... The problem of the singleton pattern is where you get your object from, ie you don't defer the object creation to another object. Hence you can't change the object creation strategy by subclassing and so the object become a global variable in disguise. The singleton is not a anti pattern because you always reuse the same object but because it gives a global visibility to an object. So in short, don't stop to the word "singleton" found in Spring configuration. Singleton refers to a creation strategy in this context.
  27. Re: JPA is not EJB3[ Go to top ]

    The singleton is not a anti pattern because you always reuse the same object but because it gives a global visibility to an object.
    Well, that's still the problem with Spring singletons, isn't it? It's not always a problem, though - global visibility through application for resources such as data sources and message queues is good. Actually, singleton pattern is not bad by itself. It's bad because non-global context is usually better, but programmer can't be bothered to find it and code it. Also, singletons in enterprise appplications cause problems with contention and make distribution hard.
  28. Re: JPA is not EJB3[ Go to top ]

    The singleton is not a anti pattern because you always reuse the same object but because it gives a global visibility to an object.
    Well, that's still the problem with Spring singletons, isn't it?
    No, you get the singleton from the IoC container, you can get it without asking the IoC container (directly or indirectly). So it's easy to substitute which implementation you want to use, something not doable with a regular singleton. Also as Paul stated, there is one singleton per application context, not one per jvm. Big difference. In this case, the singleton is just a "scope", along the lines of "request" and "session". BTW, the flyweight pattern use similar strategies, is it an evil pattern too?
  29. What's your problem?[ Go to top ]

    JPA doesn't force you to use annotations, XML mapping is possible too. (Very useful if you get assigned to a project where some architect decided 2 years ago that annotations cannot be used ever within the company) JPA is just a more standardized api, so you have the possibility to switch more easily to another product (eg. from Hibernate to TopLink). There is nothing in the JPA spec that says you have to put business functions in your entity beans. Edwin
  30. Re: TopLink vs JPA[ Go to top ]

    A while back I received some from information fron an Oracle product manager stating that they would be "recommending" POJO TopLink users to begin coding to the JPA spec, rather than the TopLink API. How accurate is this? And what TopLink specific features would not be available through JPA?
    Absolutely. All of the vendors including Oracle (TopLink), JBoss (Hibernate) and BEA (Kodo) are saying the same thing. We have wanted a proper POJO persistence and ORM standard all along. Corporations don't usually want to develop their sophistocated applications on top of proprietary APIs. It's just too risky. Every vendor will have a number of proprietary features in addition to the JPA API. Having been around for over ten years, TopLink has a huge array of additional features that are not in JPA. As with most vendors, many of these features will be accessible through the metadata and API (as hints and properties) but will just not be standard, and will be simply ignored by other vendors. -Mike