|
|
|
Java Developers Desk-EJB
3.0
|
|
|
Migrating to
EJB 3.0 is a big step towards simplifying
the process of developing EJBs, which
reduces lots of complexities, time and
cost. In spite of being rich featured,
developers feel complex working with
previous versions of EJB.
Limitations of EJB 2.1:
Developing EJB before release of EJB 3.0 was
not so easy because of some unnecessary
steps involved that are usually unused.
Some limitations of EJB 2.1 are listed below:
- A set of three source files must be create
-
Creating multiple xml deployment descriptors
-
Implementing several callback methods
-
Throwing several types of exceptions
-
EJB-QL is limited in functionality and difficult to
use
Features of EJB 3.0:
Now, have a look over the new features of EJB 3.0 that achieved some simplicity over the previous EJB APIs in various ways:
- EJBs are now Plain Old Java Objects(POJOs)
- No need of home and object interface.
- No need of any component interface.
- Unnecessary artifacts and lifecycle methods are optional
- Use of java annotations instead of using XML descriptors
- Use of dependency injection to simplify client view
- Simplify APIs to make flexible for bean’s environment
- Defaults are assumed whenever possible
Migration from EJB 2.1 to EJB 3.0
Lets go through some points justifying reasons to adopt EJB 3.0 instead of EJB 2.1:
|
|
- In EJB 2.1, home interface extends the javax.ejb.EJBHome interface and local home interface extends the javax.ejb.EJBLocalHome interface. The EJB 2.1 remote interface extends thejavax.ejb.EJBObject interface and local interface extends the javax.ejb.EJBLocalObject interface. In EJB 3.0, home and component interfaces are replaced with POJI business interfaces.
- EJB 2.1 needs the developer to implement a variety of callback methods in the bean class, ike ejbActivate(),ejbPassivate(), ejbLoad(), and ejbStore(),most of which were never used. JB 3.0 doesn’t force to implement any of these methods and instead can designate any arbitrary method as a callback method to receive notifications for life cycle events.
- In EJB 2.1, session bean implements the SessionBean interface and entity bean implements he EntityBean interface. In EJB 3.0, session and entity bean classes are POJOs and do not implement the SessionBean and EntityBean interfaces.
- The deployment descriptor, which specifies the EJB name, the bean class name, the interfaces, the finder methods etc.is not required because they are replaced by metadata annotations in the bean classes. Annotations are available in JDK 5.0 so you need JDK 5.0 to develop EJB 3.0
EJBs.
- In EJB 2.1, client application finds a reference to entity and session bean objects using JNDI name but in EJB 3.0, client finds them using dependency annotations like @Resource, @Inject, and @EJB.
- In EJB 2.1, developers used their own way to perform database specific operations like primary key generation while EJB 3.0 provides support for several database-specific operations. The O/R mapping model has intrinsic support for native SQL. The O/R mapping is specified using annotations.
- Runtime services like transaction and security are often implemented as the interceptor methods managed by the container. However, in EJB 3.0 developers can write custom interceptor. So developers have control for the actions like committing transaction, security check, etc.
|
|
|
Nov 2007 | Java Jazz Up | 12 |
| |
|
| |
| View All Topics |
| All Pages of this Issue |
Pages:
1,
2,
3,
4,
5,
6,
7,
8,
9,
10,
11,
12,
13,
14,
15,
16,
17,
18,
19,
20,
21,
22,
23,
24,
25,
26,
27,
28,
29,
30,
31,
32,
33,
34,
35,
36,
37,
38,
39,
40,
41,
42,
43,
44,
45,
46,
47,
48,
49,
50,
51,
52,
53 ,
54,
55,
56,
57,
58,
59,
60,
61,
62,
63 ,
64,
65 ,
66 ,
67 ,
68 ,
69 Download PDF |
|
|
|
|
|
|
| |
| |
|
