EJB 3.0 is taking ease of development very seriously and has adjusted its model to offer the POJO (Plain Old
Java Object) persistence and the new O/R mapping model inspired by and based on Hibernate (a less
intrusive model). In EJB 3.0, all kinds of enterprise beans are just POJOs. EJB 3.0 extensively uses Java
annotations, which replace excessive XML based configuration files and eliminate the need for rigid component
Emerging Technologies/Frameworks 223
model used in EJB 1.x, 2.x. Annotations can be used to define a bean’s business interface, O/R mapping
information, resource references etc.
ƒ In EJB 1.x, 2.x the container manages the behaviour and internal state of the bean instances at runtime. All
the EJB 1.x, 2.x beans must adhere to a rigid specification. In EJB 3.0, all container services can be
configured and delivered to any POJO in the application via annotations. You can build complex object
structures with POJOs. Java objects can inherit from each other. EJB 3.0 components are only
coupled via their published business interfaces hence the implementation classes can be changed without
affecting rest of the application. This makes the application more robust, easier to test, more portable and
makes it easier to build loosely coupled business components in POJO.
ƒ EJB 3.0 unlike EJB 1.x, 2.x does not have a home interface. The bean class may or may not implement a
business interface. If the bean class does not implement any business interface, a business interface will
be generated using the public methods. If only certain methods should be exposed in the business
interface, all of those methods can be marked with @BusinessMethod annotation.
ƒ EJB 3.0 defines smart default values. For example by default all generated interfaces are local, but the
@Remote annotation can be used to indicate that a remote interface should be generated.
ƒ EJB 3.0 supports both unidirectional and bidirectional relationships between entities.
ƒ EJB 3.0 makes use of dependency injection to make decoupled service objects and resources like queue
factories, queues etc available to any POJO. Using the @EJB annotation, you can inject an EJB stub into
any POJO managed by the EJB 3.0 container and using @Resource annotation you can inject any
resource from the JNDI.
ƒ EJB 3.0 wires runtime services such as transaction management, security, logging, profiling etc to
applications at runtime. Since those services are not directly related to application’s business logic they are
not managed by the application itself. Instead, the services are transparently applied by the container
utilizing AOP (Aspect Oriented Programming). To apply a transaction attribute to a POJO method using
annotation:
public class Account {
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public getAccountDetails(){
…
}
}
EJB QL queries can be defined through the @NamedQuery annotation. You can also create regular
JDBC style queries using the EntityManager. POJOs are not persistent by birth and become persistent
once it is associated with an EntityManager.
Java Object) persistence and the new O/R mapping model inspired by and based on Hibernate (a less
intrusive model). In EJB 3.0, all kinds of enterprise beans are just POJOs. EJB 3.0 extensively uses Java
annotations, which replace excessive XML based configuration files and eliminate the need for rigid component
Emerging Technologies/Frameworks 223
model used in EJB 1.x, 2.x. Annotations can be used to define a bean’s business interface, O/R mapping
information, resource references etc.
ƒ In EJB 1.x, 2.x the container manages the behaviour and internal state of the bean instances at runtime. All
the EJB 1.x, 2.x beans must adhere to a rigid specification. In EJB 3.0, all container services can be
configured and delivered to any POJO in the application via annotations. You can build complex object
structures with POJOs. Java objects can inherit from each other. EJB 3.0 components are only
coupled via their published business interfaces hence the implementation classes can be changed without
affecting rest of the application. This makes the application more robust, easier to test, more portable and
makes it easier to build loosely coupled business components in POJO.
ƒ EJB 3.0 unlike EJB 1.x, 2.x does not have a home interface. The bean class may or may not implement a
business interface. If the bean class does not implement any business interface, a business interface will
be generated using the public methods. If only certain methods should be exposed in the business
interface, all of those methods can be marked with @BusinessMethod annotation.
ƒ EJB 3.0 defines smart default values. For example by default all generated interfaces are local, but the
@Remote annotation can be used to indicate that a remote interface should be generated.
ƒ EJB 3.0 supports both unidirectional and bidirectional relationships between entities.
ƒ EJB 3.0 makes use of dependency injection to make decoupled service objects and resources like queue
factories, queues etc available to any POJO. Using the @EJB annotation, you can inject an EJB stub into
any POJO managed by the EJB 3.0 container and using @Resource annotation you can inject any
resource from the JNDI.
ƒ EJB 3.0 wires runtime services such as transaction management, security, logging, profiling etc to
applications at runtime. Since those services are not directly related to application’s business logic they are
not managed by the application itself. Instead, the services are transparently applied by the container
utilizing AOP (Aspect Oriented Programming). To apply a transaction attribute to a POJO method using
annotation:
public class Account {
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public getAccountDetails(){
…
}
}
EJB QL queries can be defined through the @NamedQuery annotation. You can also create regular
JDBC style queries using the EntityManager. POJOs are not persistent by birth and become persistent
once it is associated with an EntityManager.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.