How does EJB and JPA relate?

How does EJB and JPA relate?

JPA has been designed to replace EJB2 entity beans, and has started as a part of the EJB3 specification.

Since it makes sense to also use JPA outside of an EJB container, it has now its own specification, but it's still related to EJB3, since a compliant EJB3 container has to provide a JPA implementation, which integrates into the transaction handling of the container.

EJB2 had "entity beans" which were a third type of component. EJB3 has JPA, which has "entities". But I don't think they're considered as "EJB components" anymore. They're just called JPA entities.

2. Up until version 2.1 of the EJB specifications, an entity bean class had to implement the javax.ejb.EntityBean interface and provide an implementation for boilerplate methods such as ejbLoad, ejbStore, ejbActivate, and ejbPassivate.

EJB 3.0 adopted the JPA specification. The very notion of an entity bean was superceded by the simpler notion of a JPA entity. To create such entity, no interface implementation or boiler plate methods are required. The entity is a POJO that has the @Entity annotation.

Thus, in practice the use of "entity bean" EJBs in Java EE applications is dead (buried under JPA) as of EJB 3.

You are right. JPA has more to do than only supporting EJB. Thats the reason why JPA became a separate JSR or specification. EJB uses or enables the usage of JPA in its specification, simply because JPA is a good standard. You can now switch between JPA vendors without changing your code if designed properly.

EJB specification can be used independent of JPA (although JPA has been included as a part of EJB spec) and likewise JPA can be used for many more stuff outside the EJB spec. Nevertheless, EJB specification enables the injection of JPA Entitiy Manager (and its usage) into its beans very easily which makes programming easier. Ofcourse this can now be achieved easily using a new JSR on CDI :-).

All the application server that supports EJB spec, should support JPA also. You can see this threadfor more information.

Hibernate is an implementation of the JPA spec.

Pros of Agile methods

• Working software is delivered much more quickly and successive iterations can be delivered frequently, at a consistent pace.
• There is closer collaboration between developers and the business.
• Changes to requirements can be incorporated at any point of the process – even late in development.
• It gives the opportunity for continuous improvement for live systems
• It is highly transparent

Pros of the waterfall method

·        Potential issues that would have been found during development can be researched and bottomed out during the design phase. If appropriate meaning an alternate solution is selected before any code is written.

·        The development process tends to be better documented since this methodology places greater emphasis on documentation like requirements and design docs. Many organisations find this reassuring.

·        Because the waterfall process is a linear one it is perhaps easier to understand, especially for non-developers or those new to software development. Often teams feel more comfortable with this approach.

Cons of the waterfall method

·        Often the people we’re building software for (the client) don’t know exactly what they need up front and don’t know what’s possible with the technology available. This way of working doesn’t handle this well.

·        Solution designers often aren’t able to foresee problems that will arise out of the implementation of their designs.

·        Changes to requirements (e.g. like those resulting from new technologies, changes in a market or changes to business goals) can’t easily be incorporated with the waterfall method and there are often laborious change control procedures to go through when this happens

·        The process doesn’t have its own momentum