Relationship between EJB 3.0 and JPA?
Asked Answered
F

4

20

That may seem obvious but I've seen contradictory statements: Is JPA part of EJB 3.0? I'm no specialist and it's quite confusing for me.

If so, JPA manipulates Entity Beans? These entity beans being the interface between the persistence layer and the business layer implementing the logic with stateless beans?

The underlying question for me is how to implement a "search for user based on various criteria" function, where the "search" request -its string representation- should be built? I mean, if JPA is not part of EJB, my beans shouldn't be aware of the data model, right?

Where is the boundary?

Forgot answered 30/10, 2011 at 15:34 Comment(0)
H
17

Is JPA part of EJB 3.0 ?

Yes and no... Yes because every application server claiming to implement EJB 3.0 spec must also provide JPA implementation. No because JPA can be easily outside of EJB, in standalone applications or Spring-managed ones.

JPA manipulates Entity Beans ?

Entity beans was a scary idea in pre-3.0 EJBs. JPA uses the term entities to distinguish itself from the disgraceful history. But yes, JPA entities are a way to map database tables to plain Java objects. In principle changes made to object are propagated to database and vice-versa (oversimplification).

As I said, JPA does not have any dependency on EJB (considered as stateless and stateful session beans) and the other way around. But there is nothing preventing you from using JPA in EJB.

In your scenario you'll have a stateless EJB constructing the query and interacting with the database via JPA. Technically speaking you will call methods on EntityManager injected to your bean:

@Stateless
public class SearchService {

    @PersistenceContext
    private EntityManager em;

    public List<User> findUsersBornAfter(Date date) {
        return em.
            createQuery("SELECT u FROM User u WHERE u.birthDate > :birthDate ORDER BY name").
            setParameter("birthDate", date).
            getResultList();
    }
}

As you can see the business layer is aware of the data model (obviously), but there is no dependency on EJB/business services as far as entities are concerned. In this example JPQL (query) is formed in the service layer and User is a JPA entity. Calling getResultList() causes the JPA provider to translate JPQL to SQL, run the query and transalte the results back to User object instances.

Is the border between EJB and JPA clear now?

Hindemith answered 30/10, 2011 at 15:49 Comment(6)
so the Stateless EJB embeds JPQL in the search method ? and JPQL is not segregated in the persistence layer ?Forgot
I don't necessarily understand your question, but I updated my example, does it help you somehow?Hindemith
Wouldn't you rather store birthdate in DB instead of age? Or do you have daily scripts to update the age tablewide?[/nitpick] ;)Loosen
Instead of arguing it turned out that "fixing" an example is both faster and easier ;-). Thanks.Hindemith
thank you for the updated example...This is clearer now..I've to find a way to build a kind of query based on arbitrary selection of criteria...(if we only give the first name or the first and the last name)..Forgot
@LB there's the Criteria API for that in JPA 2.0/Java EE 6.Solleret
G
10

A couple of notes:

  • when it comes to the JSR, JPA 1.0 was part of EJB 3.0. See here , JPA 2.0 is a separate JSR (see here)
  • "entity beans" are EJB pre-3.0, and they are luckily dead. They are succeeded by JPA.
  • when it comes to dependencies - JPA does not depend on EJB, and EJB does not depend on JPA. However, EJB can handle injection of JPA entity manager
  • you can use either of them standalone
  • each application server supports both
Guthrie answered 30/10, 2011 at 16:49 Comment(0)
S
4

Adding to BalusC's answer, from Wikipedia - Enterprise JavaBean:

Note that the current EJB 3.1 specification does not detail how an application server provides persistence (a task delegated to the JPA specification), but instead details how business logic can easily integrate with the persistence services offered by the application server.

The integration takes away some pain points from JPA, namely the rather verbose and noisy starting and committing/rollbacking a transaction and scoping the extended persistence context (that last one only for statefull session beans).

Adding to Bozho's answer:

  • In EJB 3.0, JPA 1.0 was part of EJB but as a sub-spec and useable outside EJB and outside Java EE.
  • In EJB 3.1, JPA has been completely split-off from EJB and JPA 2.0 is 100% a separate JSR.
Solleret answered 31/10, 2011 at 12:35 Comment(0)
P
1

From Wikipedia - Java Persistence API:

Enterprise JavaBeans

The EJB 3.0 specification (itself part of the Java EE 5 platform) included a definition of the Java Persistence API. However, end-users do not need an EJB container or a Java EE application server in order to run applications that use this persistence API.[1] Future versions of the Java Persistence API will be defined in a separate JSR and specification rather than in the EJB JSR/specification. The Java Persistence API replaces the persistence solution of EJB 2.0 CMP (Container Managed Persistence).

Preserve answered 30/10, 2011 at 15:48 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.