• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

EJB 3.0 vs Spring

 
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How does EJB 3 compare to "lighter weight" frameworks like Spring with Hibernate?
 
author
Posts: 33
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Bill-
First off, the JPA entity part of the EJB 3 spec was created largely in the image of POJO-based persistence frameworks like Hibernate and TopLink. Their similarities far outweigh their differences, and this POJO is a stark departure from EJB 2.x entity beans. In fact, the bulk of the TopLink source -- known as TopLink Essentials -- was donated by Oracle to become the JPA reference implementation for EJB 3. Both JBoss (Hibernate) and Oracle (TopLink) are promoting standardization on JPA entities, and compete on the strengths and weaknesses of their underlying implementations. The JPA spec took so much from these technologies that it left surprisingly little left over -- primarily, high-end configuration options -- that are not rolled into JPA. The JPA is designed to be extensible, so Hibernate and TopLink features that go beyond the JPA spec are entirely acceptable, though their use may limits the portability of the entities should the the application become reliant on these extension (this is rare). Because so much is in the JPA, however, many powerful JPA entities will exist that require no configuration extensions at all.

As for Spring, both EJB session and message driven beans, and JPA entities, have incorporated features of Spring, such as container injection and method interception (interceptors, for enterprise beans, and entity callbacks, for JPA entities). EJB 3 offers a standard programming API built around Java EE services, whereas Spring offers its own programming API. My impression is that whereas Spring is highly flexible and extensible, EJB 3 trades in some of that flexibility for clarity of its programming API.

Regards,
Jon
 
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

What is JPA?

To my understanding Spring doesn't require any Application Server whereas EJB require a container in Application server.
 
Jon Wetherbee
author
Posts: 33
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Venkat-

What is JPA?


JPA is the Java Persistence API, and defines the behavior of JPA entities which have replaced EJB 2.x entity beans. The Java Persistence API is one of three spec documents in JSR-220, which defines the EJB 3 spec. The JPA portion of the EJB 3 spec is pretty self-contained and holds no requirements on the EJB container. JPA entities can live and be instantiated outside the EJB container, since they are POJOs (plain old Java objects). EJB 2.x entity beans, like session beans, lived only in the EJB container and could only be accessed by remote clients through a remote interface. [BTW, other posts in this forum further describe the behavior of JPA entities.]

To my understanding Spring doesn't require any Application Server whereas EJB require a container in Application server.


In EJB 3, session and message driven beans execute inside the EJB container, and this requires an application server. The EJB container, and its supporting Java EE server, offer session beans and MDBs a number of standard enterprise services, including remotability, transaction management, shared resources, security services, and many others. JPA entities do not need to execute in an EJB container, or even in a Java EE server, and so they do not require an application server. They are supported by a persistence provider (a .jar file on the classpath) which, among other things, offers them persistence services to load/save their data to the database.

Regards,
Jon
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic