Introduction
The long-awaited EJB3.0 specification recently released its first draft. In this article, we will give a brief introduction to the new specifications, including new metadata support, modification of EJBQL, new methods for entity bean models to access bean contexts and runtime environments, etc. The author also discusses the adjustments to EJB in the future and the relationship between EJB3.0 and other development specifications.
start
In any case, due to the complexity of EJB, it has not performed well in the J2EE architecture. EJB is probably the only one in the J2EE architecture that has not fulfilled its ability to develop simply and improve productivity. The EJB3.0 specification is trying to make efforts in this regard to alleviate the complexity of its development. EJB3.0 reduces the workload of developers for underlying development, cancels or minimizes the implementation of a lot of (previously these must be implemented) callback methods, and reduces the complexity of entity Bean and O/R mapping models.
In this article, I will first introduce several major changes in EJB3.0. It is very important to further understand EJB3.0. Then, I will describe the details that have been submitted to the EJB3.0 specification from a higher level, and explain the changes in the new specification one by one: entity Bean, O/R mapping model, entity relationship model, EJB QL (EJB query language), etc.
background
Two important changes in EJB3.0 are: using the program annotation tool in Java5 and the Hibernate-based O/R mapping model.
Metadata tools in Java5
Java5 (formerly called J2SE1.5 or Tiger) has added a new program annotation tool. Through this tool, you can customize comment tags, and use these custom tags to annotate fields, methods, classes, etc. These comments do not affect the semantics of the program, but can be interpreted through tools (compiled or runtime) and produce additional content (such as deployment description files), or enforce certain necessary runtime behaviors (such as state characteristics of EJB components). The resolution of comments can be done by the resolution of the source file (such as the compiler or this IDE tool) or the APIs reflection mechanism in Java5. Comments can only be defined at the source code layer. Since all comment tags submitted to the EJB3.0 draft have a runtime RetentionPolicy, it increases the storage space occupied by class files, but this brings convenience to container manufacturers and tool manufacturers.
Hibernate
Hibernate is very popular at present. It is a Java O/R mapping framework for developing source code, with the purpose of freeing developers from tedious data persistence programming. It also has a standard HQL (Hibernate query language) language, which you can see in the new EJB QL. Hibernate is very simple in handling such as data query, update, connection pooling, transaction processing, entity relationship processing, etc.
Overview
The submitted EJB3.0 specification mainly involves two changes:
1. A set of annotation-based EJB programming model, coupled with application behavior defined in EJB2.1 through deployment descriptors and several interfaces.
2. The new entity bean persistence model, EJBQL also has many important changes.
There are also some suggestions about the above, such as: a new client programming model, the use of business interfaces, and the life cycle of the entity bean. Please note that the EJB2.1 programming model (including deployment descriptors and home/remote interfaces) is still valid. The new simplified model does not completely replace the EJB2.1 model.
EJB Comments
An important goal of EJB specification organization is to reduce the amount of original code, and they provide a perfect and brief approach to this. In EJB3.0, any type of enterprise-level bean is just a simple Java object (POJO) with appropriate annotations. Comments can be used to define the business interface, O/R mapping information, and resource reference information of the bean. The effect is the same as defining deployment descriptors and interfaces in EJB2.1. Deploying descriptors in EJB3.0 is no longer necessary; the home interface is gone, and you don't have to implement business interfaces (containers can do these things for you).
For example, you can declare the Java class as a stateless reply bean using the @Stateless annotation marker class. For stateful replies beans, the @Remove annotation can be used to mark a specific method. This annotation shows that the instance of the bean will be cleared after the method is called.
To reduce the description information describing components, the specification organization also adopts the configuration-by-exception method, meaning that you can provide a clear default value for all comments, so that most of the general information can be inferred from this.
New persistence model
The new entity bean is also a simple Java object (POJO) with comments. Once it is accessed by EntityManager it becomes a persistent object and becomes part of the persistence context. A persistent context is loosely coupled to a transaction context; strictly speaking, it implicitly coexist with a transaction session.
Entity relationships are also defined through comments, as are O/R mappings, and provide several different database specification operations. In EJB2.1, these are done through the developer's own design patterns or other technologies (such as self-growth primary key strategy).
In-depth research
Now it's time to learn more about the EJB3.0 draft. Let's start exploring the four enterprise-level beans in all EJBs and see what they look like in the new specification.
Stateless reply bean
In the EJB3.0 specification, writing a stateless callback bean (SLSB) only requires a simple Java file and adding @Stateless annotation to the class layer. This bean can extend the interface, but these are not necessary.
A SLSB no longer needs a home interface, and no EJB needs it anymore. The Bean class can implement business interfaces or not implement it. If no business interface is implemented, the business interface will be generated by any public method. If only a few business methods are exposed to the business interface, these methods can be commented using the @BusinessMethod. By default, all generated interfaces are local (local) interfaces, and you can also use the @Remote annotation to declare this interface as remote (remote) interface.
The following lines of code can define a HelloWorldbean. In EJB2.1, the same bean requires at least two interfaces, one implementation class and several empty implementation methods, plus the deployment descriptor.
import .*;
/**
* A stateless session bean requesting that a remote business
* interface be generated for it.
*/
@Stateless
@Remote
public class HelloWorldBean {
public String sayHello() {
return "Hello World!!!";
}
}
Stateful reply bean
Apart from a few SFSBs' special notes, stateful reply beans (SFSBs) are as streamlined as SLSBs:
An SFSB should have a method to initialize itself (implemented by ejbCreate() in EJB2.1). It is suggested that these initialization operations can be done through custom methods and expose them to the business interface. The client calls the corresponding initialization method before using this bean. There is still debate at present whether the normative organization provides an annotation to mark a method for initialization.
The bean provider can use the @Remove annotation to mark any SFSB method to indicate that the bean instance will be removed after this method is called. Similarly, the normative organization is still discussing whether there is a mechanism to deal with this particular situation, namely whether the instance of the bean is removed when an exception occurs in this method.
Here are my personal views on the above issues:
1) Should there be a comment to indicate that a method is initialized? My point is that there should be so that the container can call at least one method to initialize before calling other methods. This not only avoids unnecessary errors (because the initialization method is not called) but also allows the container to make a more clear decision on whether the SFSB instance can be reused. I'll put this problem aside for now. The standard organization only considers providing a comment for a method to declare it as an initialization method.
2) My point of view is also affirmative to the second question. This helps the Bean's provider to combine client programs to control it. There is only one legacy question: that is, if the call to this method fails, can the instance of this bean bean be removed? The answer is no, but it will be removed at the end of the reply.
Message-driven beans
Message-driven beans are the only beans that must implement a business interface. This interface indicates which message system the bean supports. For JMS-based MDB, this interface is. Note that the MDB business interface is not a business interface in the true sense, it is just a message interface.
Entity Bean
Entity beans are marked with @Entity annotation, and all attributes/fields in entity beans do not have to be marked with @Transient annotation. The persistent fields of entity beans can be implemented through the JavaBean-style mechanism or declared as public/protected fields.
Entity beans can use helper classes to describe their state, but instances of these classes do not have the characteristics of persistent identity (i.e., fields that uniquely identify the bean, etc.). In fact, these assistant classes are closely linked to their entity bean instances; and these objects still access entity objects in a non-shared way.
Entity association
EJB3.0 also supports two-way combined and one-way associations between beans, which can be one-to-one, one-to-many, many-to-one or many-to-many associations. However, the two ends of the two-way association must also be divided into different ends of the own side and the other side. The self-side is responsible for notifying the associated changes to the database. The many-to-many relationship must be clearly stated. In fact, the other end comments through isInverse=true (thus, the end of the itself does not need to be explained but is inferred from another paragraph). It seems that the above description can standardize organization and make EJB simple?
O/R mapping
The O/R mapping model in EJB3.0 has also undergone important changes, from the original abstract-persistence-schema-based to the current Hibernate-inspired model. Although the normative organization is currently discussing this, a clear model will appear in the next version of the draft.
For example, the O/R mapping model will be declared by comments in the bean class. Moreover, this method will also indicate the corresponding specific tables and fields. The O/R mapping model provides a set of its own SQL; in addition to providing some basic SQL, it also supports certain high-level development functions. For example, if there is a field columnDefinition declared through @Column annotation, you can write SQL like this: columnDefinition="BLOB NOT NULL"
Client program model
An EJB client can obtain a bean's business interface reference in a "inject" way through the @Inject annotation. You can also use another comment @() to complete the above operation, but the specification does not tell us how to get an instance of a bean by a normal Java client, because this normal Java client is running in a client container and it cannot access the @ object. There is another mechanism to do the above work now, which is to use a super context environment object: @(). However, the specification does not specify how to use this object in the client.
EJB QL
EJB QL can be annotated via @NamedQuery. This comment has two member attributes, name and queryString. Once these attributes are defined, you can point to the query through (name). You can also create a standard JDBC-style query and execute the query using (ejbqlString) or (nativeSqlString) (this method is used to execute a local query).
EJB QL has two places to define its parameters. The interface provides methods such as defining parameters, pointing to queries, updating data, etc. Here is an example of an EJBQL pointing to a query:
.. ..
@NamedQuery(
name="findAllCustomersWithName",
queryString="SELECT c FROM Customer c WHERE LIKE :custName"
)
.. ..
@Inject public EntityManager em;
customers = ("findAllCustomersWithName")
.setParameter("custName", "Smith")
.listResults();
Here are some enhancements to EJB QL:
1) Support batch updates and deletion.
2) Directly support internal and external connections. FETCH JOIN runs the entity you indicate the associated, and the Order can specify that only a certain field is queryed.
3) The query statement can return more than one result value. In fact, you can return a dependency class like this:
SELECT new CustomerDetails(, , )
FROM Customer c JOIN o
WHERE > 100
4) Support group by and having.
5) Support nested subqueries of where clauses.
In the submitted EJB3.0 draft, EJB QL is very close to standard SQL. In fact, local SQL is even directly supported in the specification (as we mentioned above). This may not be very clear to some programmers, and we will explain it in more detail below.
The long-awaited EJB3.0 specification recently released its first draft. In this article, we will give a brief introduction to the new specifications, including new metadata support, modification of EJBQL, new methods for entity bean models to access bean contexts and runtime environments, etc. The author also discusses the adjustments to EJB in the future and the relationship between EJB3.0 and other development specifications.
start
In any case, due to the complexity of EJB, it has not performed well in the J2EE architecture. EJB is probably the only one in the J2EE architecture that has not fulfilled its ability to develop simply and improve productivity. The EJB3.0 specification is trying to make efforts in this regard to alleviate the complexity of its development. EJB3.0 reduces the workload of developers for underlying development, cancels or minimizes the implementation of a lot of (previously these must be implemented) callback methods, and reduces the complexity of entity Bean and O/R mapping models.
In this article, I will first introduce several major changes in EJB3.0. It is very important to further understand EJB3.0. Then, I will describe the details that have been submitted to the EJB3.0 specification from a higher level, and explain the changes in the new specification one by one: entity Bean, O/R mapping model, entity relationship model, EJB QL (EJB query language), etc.
background
Two important changes in EJB3.0 are: using the program annotation tool in Java5 and the Hibernate-based O/R mapping model.
Metadata tools in Java5
Java5 (formerly called J2SE1.5 or Tiger) has added a new program annotation tool. Through this tool, you can customize comment tags, and use these custom tags to annotate fields, methods, classes, etc. These comments do not affect the semantics of the program, but can be interpreted through tools (compiled or runtime) and produce additional content (such as deployment description files), or enforce certain necessary runtime behaviors (such as state characteristics of EJB components). The resolution of comments can be done by the resolution of the source file (such as the compiler or this IDE tool) or the APIs reflection mechanism in Java5. Comments can only be defined at the source code layer. Since all comment tags submitted to the EJB3.0 draft have a runtime RetentionPolicy, it increases the storage space occupied by class files, but this brings convenience to container manufacturers and tool manufacturers.
Hibernate
Hibernate is very popular at present. It is a Java O/R mapping framework for developing source code, with the purpose of freeing developers from tedious data persistence programming. It also has a standard HQL (Hibernate query language) language, which you can see in the new EJB QL. Hibernate is very simple in handling such as data query, update, connection pooling, transaction processing, entity relationship processing, etc.
Overview
The submitted EJB3.0 specification mainly involves two changes:
1. A set of annotation-based EJB programming model, coupled with application behavior defined in EJB2.1 through deployment descriptors and several interfaces.
2. The new entity bean persistence model, EJBQL also has many important changes.
There are also some suggestions about the above, such as: a new client programming model, the use of business interfaces, and the life cycle of the entity bean. Please note that the EJB2.1 programming model (including deployment descriptors and home/remote interfaces) is still valid. The new simplified model does not completely replace the EJB2.1 model.
EJB Comments
An important goal of EJB specification organization is to reduce the amount of original code, and they provide a perfect and brief approach to this. In EJB3.0, any type of enterprise-level bean is just a simple Java object (POJO) with appropriate annotations. Comments can be used to define the business interface, O/R mapping information, and resource reference information of the bean. The effect is the same as defining deployment descriptors and interfaces in EJB2.1. Deploying descriptors in EJB3.0 is no longer necessary; the home interface is gone, and you don't have to implement business interfaces (containers can do these things for you).
For example, you can declare the Java class as a stateless reply bean using the @Stateless annotation marker class. For stateful replies beans, the @Remove annotation can be used to mark a specific method. This annotation shows that the instance of the bean will be cleared after the method is called.
To reduce the description information describing components, the specification organization also adopts the configuration-by-exception method, meaning that you can provide a clear default value for all comments, so that most of the general information can be inferred from this.
New persistence model
The new entity bean is also a simple Java object (POJO) with comments. Once it is accessed by EntityManager it becomes a persistent object and becomes part of the persistence context. A persistent context is loosely coupled to a transaction context; strictly speaking, it implicitly coexist with a transaction session.
Entity relationships are also defined through comments, as are O/R mappings, and provide several different database specification operations. In EJB2.1, these are done through the developer's own design patterns or other technologies (such as self-growth primary key strategy).
In-depth research
Now it's time to learn more about the EJB3.0 draft. Let's start exploring the four enterprise-level beans in all EJBs and see what they look like in the new specification.
Stateless reply bean
In the EJB3.0 specification, writing a stateless callback bean (SLSB) only requires a simple Java file and adding @Stateless annotation to the class layer. This bean can extend the interface, but these are not necessary.
A SLSB no longer needs a home interface, and no EJB needs it anymore. The Bean class can implement business interfaces or not implement it. If no business interface is implemented, the business interface will be generated by any public method. If only a few business methods are exposed to the business interface, these methods can be commented using the @BusinessMethod. By default, all generated interfaces are local (local) interfaces, and you can also use the @Remote annotation to declare this interface as remote (remote) interface.
The following lines of code can define a HelloWorldbean. In EJB2.1, the same bean requires at least two interfaces, one implementation class and several empty implementation methods, plus the deployment descriptor.
import .*;
/**
* A stateless session bean requesting that a remote business
* interface be generated for it.
*/
@Stateless
@Remote
public class HelloWorldBean {
public String sayHello() {
return "Hello World!!!";
}
}
Stateful reply bean
Apart from a few SFSBs' special notes, stateful reply beans (SFSBs) are as streamlined as SLSBs:
An SFSB should have a method to initialize itself (implemented by ejbCreate() in EJB2.1). It is suggested that these initialization operations can be done through custom methods and expose them to the business interface. The client calls the corresponding initialization method before using this bean. There is still debate at present whether the normative organization provides an annotation to mark a method for initialization.
The bean provider can use the @Remove annotation to mark any SFSB method to indicate that the bean instance will be removed after this method is called. Similarly, the normative organization is still discussing whether there is a mechanism to deal with this particular situation, namely whether the instance of the bean is removed when an exception occurs in this method.
Here are my personal views on the above issues:
1) Should there be a comment to indicate that a method is initialized? My point is that there should be so that the container can call at least one method to initialize before calling other methods. This not only avoids unnecessary errors (because the initialization method is not called) but also allows the container to make a more clear decision on whether the SFSB instance can be reused. I'll put this problem aside for now. The standard organization only considers providing a comment for a method to declare it as an initialization method.
2) My point of view is also affirmative to the second question. This helps the Bean's provider to combine client programs to control it. There is only one legacy question: that is, if the call to this method fails, can the instance of this bean bean be removed? The answer is no, but it will be removed at the end of the reply.
Message-driven beans
Message-driven beans are the only beans that must implement a business interface. This interface indicates which message system the bean supports. For JMS-based MDB, this interface is. Note that the MDB business interface is not a business interface in the true sense, it is just a message interface.
Entity Bean
Entity beans are marked with @Entity annotation, and all attributes/fields in entity beans do not have to be marked with @Transient annotation. The persistent fields of entity beans can be implemented through the JavaBean-style mechanism or declared as public/protected fields.
Entity beans can use helper classes to describe their state, but instances of these classes do not have the characteristics of persistent identity (i.e., fields that uniquely identify the bean, etc.). In fact, these assistant classes are closely linked to their entity bean instances; and these objects still access entity objects in a non-shared way.
Entity association
EJB3.0 also supports two-way combined and one-way associations between beans, which can be one-to-one, one-to-many, many-to-one or many-to-many associations. However, the two ends of the two-way association must also be divided into different ends of the own side and the other side. The self-side is responsible for notifying the associated changes to the database. The many-to-many relationship must be clearly stated. In fact, the other end comments through isInverse=true (thus, the end of the itself does not need to be explained but is inferred from another paragraph). It seems that the above description can standardize organization and make EJB simple?
O/R mapping
The O/R mapping model in EJB3.0 has also undergone important changes, from the original abstract-persistence-schema-based to the current Hibernate-inspired model. Although the normative organization is currently discussing this, a clear model will appear in the next version of the draft.
For example, the O/R mapping model will be declared by comments in the bean class. Moreover, this method will also indicate the corresponding specific tables and fields. The O/R mapping model provides a set of its own SQL; in addition to providing some basic SQL, it also supports certain high-level development functions. For example, if there is a field columnDefinition declared through @Column annotation, you can write SQL like this: columnDefinition="BLOB NOT NULL"
Client program model
An EJB client can obtain a bean's business interface reference in a "inject" way through the @Inject annotation. You can also use another comment @() to complete the above operation, but the specification does not tell us how to get an instance of a bean by a normal Java client, because this normal Java client is running in a client container and it cannot access the @ object. There is another mechanism to do the above work now, which is to use a super context environment object: @(). However, the specification does not specify how to use this object in the client.
EJB QL
EJB QL can be annotated via @NamedQuery. This comment has two member attributes, name and queryString. Once these attributes are defined, you can point to the query through (name). You can also create a standard JDBC-style query and execute the query using (ejbqlString) or (nativeSqlString) (this method is used to execute a local query).
EJB QL has two places to define its parameters. The interface provides methods such as defining parameters, pointing to queries, updating data, etc. Here is an example of an EJBQL pointing to a query:
.. ..
@NamedQuery(
name="findAllCustomersWithName",
queryString="SELECT c FROM Customer c WHERE LIKE :custName"
)
.. ..
@Inject public EntityManager em;
customers = ("findAllCustomersWithName")
.setParameter("custName", "Smith")
.listResults();
Here are some enhancements to EJB QL:
1) Support batch updates and deletion.
2) Directly support internal and external connections. FETCH JOIN runs the entity you indicate the associated, and the Order can specify that only a certain field is queryed.
3) The query statement can return more than one result value. In fact, you can return a dependency class like this:
SELECT new CustomerDetails(, , )
FROM Customer c JOIN o
WHERE > 100
4) Support group by and having.
5) Support nested subqueries of where clauses.
In the submitted EJB3.0 draft, EJB QL is very close to standard SQL. In fact, local SQL is even directly supported in the specification (as we mentioned above). This may not be very clear to some programmers, and we will explain it in more detail below.