Ease of Development in Enterprise JavaBeans Technology

Discussions

News: Ease of Development in Enterprise JavaBeans Technology

  1. A new article on EJB 3.0 has been released from Sun. The article gives a high level view of EJB, shows EJB 2.1, and then gets into EJB 3.0 itself. As well as showing development with EJB 3.0 there is mention of issues such as support for testing outside of the container, OR mapping, and the new EJB QL.

    Ease of Development in Enterprise JavaBeans Technology

    Threaded Messages (13)

  2. Excellent article![ Go to top ]

    This was very usefull information
  3. 1[ Go to top ]

    1
  4. is it the EJB powful enough?[ Go to top ]

    "EJB 3.0, focuses primarily on making the technology easier for developers to use -- but not at the expense of the technology's power and sophistication." is that mean the EJB 2.1 is powerful enough?

    Why don't they think about the Cluter issue, Messaging Issue and better Persistent technology?

    Is that mean the end of EJB ???
  5. is it the EJB powful enough?[ Go to top ]

    don't worry ... just go back to sleep. classes start again next semester ....

    --b
  6. Solve complexity or laziness??[ Go to top ]

    I’ve been working with ejbs for the past three years and I don’t think ejbs are complex, just a lot of work. You have to create a remote interface and home interface and maybe a local interface and then you have to setup the deployment descriptors. None of this stuff is complex.
  7. Solve complexity or laziness??[ Go to top ]

    I’ve been working with ejbs for the past three years and I don’t think ejbs are complex, just a lot of work. You have to create a remote interface and home interface and maybe a local interface and then you have to setup the deployment descriptors. None of this stuff is complex.

    Not if you use XDoclet.
  8. Solve complexity or laziness??[ Go to top ]

    You could be use absolutely any tool on earth to create those artifacts. Honestly those are the least of what from a systems point of view you should be worring about in terms of complexity. That problem is so easy to solve, and has been solved in about 20 different solutions already.

    Unfortunately thats all they focused on in EJB3 because this is what developers face on a day to day basis. This shows SUN's continued myopic view of selling solutions. They continue to focus purely on the experience of the developer and not on the business. By failing to solve the real busienss problems, they fail to help the business decision makers, who are the ones with the money.

    The real complexity still remains. Scalability, Maintainability, Resilience, Transactionality, etc. Nothing has honestly improved here. They continue to leave the door swinging open.

    Dave Wolf
    Cynergy Systems
  9. Solve complexity or laziness??[ Go to top ]

    ...The real complexity still remains. Scalability, Maintainability, Resilience, Transactionality, etc. Nothing has honestly improved here.

    The whole point of EJB from the first day it was created has been to address these 'enterprise' problems. What is wrong with having a release of the spec that focuses on making it easier to use?

    -Scott
  10. EJB 3.0 is crap ![ Go to top ]

    This article says that there will be no relationships in entity beans ! Who will use that crap if there are so many O/R mapping solutions that have this simple feature.

    And the reason is that just some clueless developers that don't know how to start an EJB container under a debugger decided that they want to test their beans without a container !

    And what will do those injections if they run EJB's outside of a container ?
  11. EJB 3.0 is crap ![ Go to top ]

    This article says that there will be no relationships in entity beans

    You misread. There will be no container-managed relationships, which makes testing easier.

    All you need to do is set the pointers yourself (a couple of extra lines), like Hibernate users have been doing for

    --
    Cedric
    http://beust.com/weblog
  12. Who's responsibility ?[ Go to top ]

    The real complexity still remains. Scalability, Maintainability, Resilience, Transactionality, etc. Nothing has honestly improved here. They continue to leave the door swinging open.
    I would also argue that this should be a focus area for the implementations of the specifications. If the model (read spec) itself doesn't provide the foundation to scale, make it maintainable++ then of course this must change, but I don't think that has been EJBs greatest problem.

    ---- Trond
  13. Who's responsibility ?[ Go to top ]

    I don't think that has been EJBs greatest problem.---- Trond

    What would you contend has been the greatest problem then? I cannot believe that EJB's biggest achiles heel has been needing a code generator hidden behind annotations.

    Thats my point. They have focused on the minutia and forgotten the elephant in the room. I'd agree at a moral level that the onus remains on the developer. However, the reason we use a framework and a service is to provide us with value. The more the service provides to help ensure the success of the developers using it, the more truly successful it is. We may at a moral level feel that academia and purity are what we want from a specification. I contend this has never been what makes a framework successful in the field.

    At the end of the day NOTHING matters outside of "Have you gotten Sh*t done today?" Did you make progress. Did you accomplish anything. Did you deliver value back to your customer (everyone has a customer even if there is no exchange of currency).

    So my challenge is did this specification do much of anything to make developers more successful in the delivery of enterprise class applications. The changes listed here dont change much. We had xdoclet, IDE code generators, blah blah blah. This stuff is the easy stuff. Where's the hard stuff?

    Dave Wolf
    Cynergy Systems
  14. This article claims that EJB should work with other persitence mechanisms but relational databases. But my questions is: Could EJB-QL ever be applied to hierachical databases like LDAP or network databases? EJB-QL seem to be such a direct rip-off from SQL that it is hard to imagine that it would work with any other kind of database.

    Fredrik Bertilsson
    http://butler.sourceforge.net