Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Despite several positives, the complexity of the Enterprise JavaBeans architecture is hindering the adoption of J2EE. The EJB architecture is probably the only J2EE component that has failed so miserably in delivering J2EE's promise of increased developer productivity thorough ease of development. EJB 3.0 makes another attempt at delivering that promise by reducing EJB's complexity for developers. EJB 3.0 decreases the number of programming artifacts for developers to provide, eliminates or minimizes callback methods required to be implemented, and reduces the complexity of the entity bean programming model and O/R mapping model.
In this article, I first cover the most significant changes in EJB 3.0. It's important to have the basics in place before diving into the EJB 3.0 pool. Next, I give a high-level view of the EJB 3.0 draft and then get into specifics of the proposed specification, paying attention to all changes one-by-one: impact on types of enterprise beans, O/R mapping model, entity-relationship model, EJB QL (EJB Query Language), etc.
The two most significant changes in the proposed EJB 3.0 specification are the use of the program annotation facility introduced in Java 5 and the new O/R mapping model based on Hibernate.
Java 5 (previously called J2SE 1.5, or Tiger) has introduced a new program annotation facility to the language. With this
facility, you can define custom annotations and then annotate fields, methods, classes, etc., with these annotations. Annotations
do not directly affect program semantics, but tools (compile time or runtime) can inspect these annotations to generate additional
constructs (like a deployment descriptor) or enforce desired runtime behavior (like an EJB component's stateful nature). Annotations
can be inspected through source parsing (e.g., compilers or IDE tools) or by using the additional reflection APIs added in
Java 5. Annotations can be defined to be available only at the source code level, at the compiled class level, or at runtime.
All annotations proposed in the EJB 3.0 early draft have a
RUNTIME. This increases the class's memory footprint marginally, but makes the life of container provider and tool provider much
Refer to Resources for further reading on this topic.
Hibernate is a popular, open source O/R mapping framework for Java environments, meant to shield developers from most common data-persistence-related programming tasks. It also has a specific Hibernate Query Language (HQL), imprints of which can be seen in the new EJB QL. Hibernate offers facilities for data retrieval and update, connection pooling, transaction management, declarative entity relationship management, and declarative and programmatic queries.
The changes in the proposed EJB 3.0 specification can be divided into two categories:
There are also several side effects to these proposals, like a new client-programming model, use of business interfaces, and an entity bean life cycle. Please note that the EJB 2.1 programming model (with deployment descriptors and home/remote interfaces) is still valid. The new simplified model does not entirely replace the EJB 2.1 model.
|Forum migration complete By Athen|
|Forum migration update By Athen|
|location of generated deployment descriptors By Nandakishore|
|isInverse=true By Anonymous|
|EJB 3.0 new Path Finder By Jai Kumar|
|prediction on where this will end up By tom-murphy|
|JDO ! By Tibo|
|Ejb not needed in our life By gamol|
|Entity Beans By Anonymous|
|EJB 3.0 is the right direction. By Mohit Keswani|
|Native SQL? Why? By mitko.p|
|EJB Complexity By Anonymous|
|Annotations OK, but depl.descr. still needed! By Hoffe|
|Annotations vs XDoclet By Anonymous|