Original link http://www.javaworld.com/javaworld/jw-08-2004/jw-0809-ejb.html
Translator language:
After the translation of this article, I feel that EJB3.0 has indeed great improvements, especially in reducing development difficulties, individuals think that EJB3.0 uses annotations to simplify development is really a good attention. Friends who have used XDoclet or BEA's WebLogicWorkshop (its JWS is a comment) friend should not be very unfamiliar. The author of this article is the Senior Programmer of BEA, not only to describe the latest EJB3.0 technology, but also puts forward some of his personal opinions. It is worth our reference. The author is also in the art to participate in the EJB3.0 specification together. Develop in the formulation. I hope that by reading this article, you can give you a horn of the iceberg in EJB3.0.
For the Chinese translation of this article, the author retains all its rights, and if you need to reprint the consent of the translator.
introduction
Looking forward to a long-lasting EJB3.0 specification recently issued its first draft. In this paper, a new specification will be conducted, including new metadata support, EJBQL modification, entity bean model access to new methods and runtime environments, etc. The author also discusses the adjustment of EJB in the future and the relationship between EJB3.0 and other development specifications.
Start
Regardless of the complexity of EJBs, it is not very good in the J2EE architecture. EJB is probably the only one in the J2EE architecture that does not fulfill it easily develop and improve productivity. EJB3.0 specification is trying to make efforts in this regard to mitigate the complexity of its development. EJB3.0 reduces the workload of developers for underlying development, it cancels or minimizes many (formerly these are required) the implementation of the callback method, and reduces the complexity of the entity bean and O / R mapping model.
In this article, I will introduce several major changes in EJB3.0. It is very important to further understand EJB3.0. Subsequently, I will describe the details that have been submitted to the EJB3.0 specification from a higher level, and a change in new specifications: entity bean, O / R mapping model, entity relationship model and EJB QL (EJB query language), etc.
background
Two important changes in EJB3.0 are: using program annotation tools in Java5 and Hibernate-based O / R mapping models.
Metadata tool in Java5.
A new program annotation tool is added to Java5 (previously called J2SE 1.5 or Tiger). With this tool you can customize the comment tag, comment, methods, classes, and more, by these custom tags. These comments do not affect the semantics of the program, but can interpret these tags and generate additional content (such as deployment description files), or to force certain runtime behavior (such as EJB components) Status characteristics). Annotation parsing can pass the resolution of the source file (such as a compiler or this IDE tool) or using the API reflex mechanism in Java5. Note You can only be defined in the source code layer. Since all annotated tags submitted to the EJB3.0 have a runtime RetentionPolicy, the storage space occupied by the class file is increased, but this has brought convenience to the container manufacturer and tool manufacturer.
Hibernate
Hibernate is very popular. It is a Java O / R mapping framework for the development source code. The purpose is to free developers from cumbersome data persistence programming. It also has a standard HQL (Hibernate query language) language, you can see its shadow in the new EJB QL. Hibernate is very simple in processing such as data queries, updates, connection pools, transaction processing, entity relationship processing, etc.
Overview
In the EJB3.0 specification that has been submitted, it mainly involves two modifications:
1. A set of comments-based EJB programming models, plus application behavior defined by deployment descriptors and several interfaces defined in EJB2.1. 2. New entity bean persistence models, EJBQL also has many important changes.
There are also some proposals, such as: a new client programming model, usage of business interfaces, and physical Beans life cycle. Note that the EJB2.1 programming model (including deployment descriptor and home / remote interface) is still valid. The new simplified model does not completely replace the EJB2.1 model.
EJB comment
An important goal is an important goal to mitigate the number of original code, and they give this perfect way. In EJB3.0, any type of enterprise bean is just a simple Java object (Pojo) added appropriately. Note You can use the service interface, O / R mapping information, resource reference information of the bean, and the effect is the same as the deployment descriptor and the interface in EJB2.1. The deployment descriptor in EJB3.0 is no longer a must; the home interface is not, you don't have to implement business interfaces (containers can do these things for you).
For example, you can use the @StateLess annotation tag class to declare the Java class as a stateless reply bean. For stateful reply beans, @ remove comments can be used to marke a specific method, and the instance of Bean will be cleared after calling this method.
In order to reduce the description of the description of the components, the standardization organization also adopts the means of configuration-by-exception, meaning that you can provide a clear default value for all comments, so most of these general information can be This inferred.
New persistence model
The new entity bean is also a simple Java object (POJO) added. Once it is accessed by EntityManager, it becomes a persistent object, and has become part of the persistening context. One persistence context is loosely coupled to a transaction context; strictly speaking, it is implied with a transaction session.
Entity relationship is also defined by comments, O / R mapping is also, and provides several different database specification operations, which are completed in EJB2.1 (for example, self-growth) through developers's own design modes or other technologies Primary key policy).
In-depth study
It is time to learn about the draft EJB3.0. Let us start to explore all four enterprise beans in EJB and see what they look like in the new norm.
No status reply bean
In the EJB3.0 specification, write a stateless reply bean (SLSB) only needs a simple Java file and add @StateLess annotations in the class layer. This bean can expand the Javax.ejb.SessionBean interface, but these are not required.
A SLSB no longer needs home interface, no EJB needs it. The bean class can implement the business interface or not. If no service interface is implemented, the service interface will be generated by any public method. If only a few business methods are exposed to the business interface, these methods can use @businessMethod comments. By default, all generated interfaces are Local (Local) interface, you can also use @Remote annotations to declare this interface as the REMOTE interface.
The following lines of code can define a HelloWorldbean. The same beans in EJB2.1 require at least two interfaces, one implementation, and several empty implementation methods, plus deployment descriptors.
import javax.ejb *;.. / *** A stateless session bean requesting that a remote business * interface be generated for it * / @ Stateless @ Remotepublic class HelloWorldBean {public String sayHello () {return "Hello World !!!" }} There is a state of reply bean
In addition to the special instructions of several SFSBs, there is a status back to the BEAN (SFSB) and SLSB.
l You should have a method to initialize yourself (in EJB2.1 is implemented by ejbcreate ()). These initialization operations in EJB3.0 are recommended to complete them through custom methods and expose them in the business interface. The corresponding initialization method is called by the client before using this bean. Currently, the organization provides an annotation to tag a method for initialization and controversy.
l Bean's provider can use @Remove annotations to mark any SFSB methods to illustrate that the instance of the bean after this method is called. Similarly, the standardization organization still discusses whether there is a mechanism to handle this special situation, that is, if this method is abnormal, the instance of the bean is removed.
Here is the perspective of my personal opinion:
l Will there be an annotation to indicate a method to initialize? My point is - should have, so that the container can initialize at least one method before calling other methods. This can not only avoid unnecessary errors (due to the start of the initialization method) and can make the container more clearly determine whether the SFSB instance can be reused. I have been putting on this question, and the Specification Organization only considers that it provides a note to declare it is an initialization method.
l The idea of my second problem is also sure. This facilitates the control of the BEAN to control it. There is only one legacy question: That is, once the method is called, can the instance of this bean can be removed? The answer is not, but it will be removed at the end of the back.
Message driver bean
Message Drive Bean is the only bean that must implement a service interface. This interface indicates which message system that bean supports. This interface is javax.jms.MESSAGELISTENER for JMS-based MDB. Note that the MDB service interface is not a real business interface, which is just a message interface.
Entity bean
l The entity bean uses the @entity annotation to tag, and the properties / fields in all entity beans do not have to be marked with the @Transient comment. The persistence field of the entity bean can be implemented by the JavaBean-Style mechanism or declared as a public / protected field.
l The entity bean can use the assistant class to describe its status, but these classes do not have the characteristics of persistent Identity (ie, uniquely identifying this bean field, etc.), actually these assistant classes with their entity The bean instance is closely coupled; and these objects are also accessed in a non-shared approach.
Entity association
EJB3.0 simultaneously supports two-way conformal associations between Beans, which can be one-to-one, one-to-many, multi-to-one or more. However, both ends of the two-way association are also different from the OWNING SIDE and the INVERSE SIDE. It is responsible for the change associated with the database. For multi-to-many associated own ends must be clearly declared. In fact, the opponent is annotated by isinverse = true (from this itself does not have to be explained, but is inferred by another paragraph). It seems that the above description, can I still say that the EJB is simple? O / R mapping
The O / R mapping model in EJB3.0 also has important changes, which becomes the current Hibernate-Inspired mode from the original Abstract-persistence-Schema-based. Although the current regulatory organization is also discussed, a clear model will appear in the next version.
For example, the O / R mapping model will be declared through comments in the bean class. Moreover, this method also points out the corresponding specific tables and fields. The O / R mapping model provides a set of own SQL; and in addition to providing some basic SQL, it supports certain high-level development functions. For example, there is a field columnDefinition that is declared through @Column annotation, then you can write such SQL: columnDefinition = "blob not null"
Client program model
An EJB client can obtain a bean service interface reference in a "injection" manner via @ITECT annotation. You can also use another comment @ javax.ejb.ejbcontext.lookup () to complete the above operation, but not tell us how a normal Java client gets a bean instance because this normal Java client is Run in a client container, it can't access the @ javax.ejb.ejbcontex object. There is still another mechanism to complete the above work. That is to use a super context environment: @ javax.ejb.context (). However, it is not pointed out in the specification to use this object in the client.
EJB QL
EJB QL can be commented by @namedquery. This comment has two member properties that are Name and QueryString. Once these properties are defined, they can point to this query via EntityManager.createNamedQuery (Name). You can also create a standard JDBC style query and use EntityManager.createQuery (EJBQLSTRING) or EntityManager.createNativeQuery (NativeSqlstring) (this method is used to execute a local query) to perform a query.
EJB QL has two places to define their parameters. The Javax.ejb.Query interface provides defined parameters, pointing to query, update data, etc. Here is an example of EJBQL pointing to the query:
.. .. @ NamedQuery (name = "findAllCustomersWithName", queryString = "SELECT c FROM Customer c WHERE c.name LIKE: custName") .. .. @ Inject public EntityManager em; customers = em.createNamedQuery ( "findAllCustomersWithName") .SETPARAMETER ("CustName", "Smith"). ListResults ();
Some EJB QL enhancements are listed below:
l Supports bulk updates and deletion.
l Supports internal connections and external connections. Fetch Join runs you pointed out the associated entity, order can specify only a field. l Query statements can return more than one result value. In fact, you can return a dependence, such as the following: Select New CustomerDetails (C.ID, C.Status, O.Count) from Customer C Join C.ORDERS o Where o.count> 100
l Support Group By and Having.
l Support the nested subsequent query for WHERE clauses.
In the draft EJB3.0 submitted, EJB QL is very close to the standard SQL. In fact, the local SQL directly supports local SQL (just as mentioned above). This may not be very clear about some of the programmers, we will explain more detailed explanation below.
Diversity
Method Permissions can be declared via @MethodPermissions or @unchecked annotations; the same, transaction attributes can also be declared by @TransactionAttribute annotations. Resource reference and resource environment reference are still reserved in the specification. These can be declared by comments, but there are some subtle differences. For example, the context environment is controlled by the injection tool. The container automatically initializes an appropriately declared instance variable based on the Bean to the external environment. For example, you can get a data source like this: DataSource:
@Resource (name = "mydatasource") // type is inferred from variablepublic DataSource Customerdb;
In the above example, if you do not specify the name of the reference resource (name) therein, the CustomerDB will be considered a default. When all reference properties are available, @ INJEC comments can be written this:
@Inject public DataSource CustomerDB;
The container is responsible for initializing the CustomerDB data source instance at runtime. Deployers must define these resource properties in the container before this.
Better messages are: Those excellence that you must test before will not return. You can declare any application exception without having to throw or capture an exception such as CreateException and FINDEREXCEPTION. The container will thrown the system-level exception in javax.ejb.ejbexception or throw IllegaLaRgumentException or ILLEGALSTATEEXCEPTION or ILLEGALSTATEEXCEPTION.
EJB file processing mode
Before we end this section, let my fast browsing the container provider may change in EJB processing mode. There is no clear statement in the specification, but I can think of at least two modes.
l One way is to first use the EJB file to generate files similar to the EJB2.1 deployment mode (including the necessary interfaces and deployment descriptors) and then deploy this EJB component with similar to EJB2.1. Of course, the deployment descriptor thus produced may not be standard but it can solve the same container to EJB2.1 and EJB3.0 compatible issues. The following will describe this process.
L Another method is a deployment mode similar to JSP. You can put an EJB file into a predefined directory, then the container will identify this EJB and process it, and then deploy and make it. This method can be based on the above method and have a great help when supporting repeated deployment. Considering that the simplicity of deployment is one of the purposes of EJB3.0 specification, I sincerely hope that one model can be determined when the next draft (at least one informal) is available.
Do you have any idea?
The development of EJB3.0 specification is undergoing, in order to make EJB development easier, the effort to EJB specification organization is obvious. Just like they say, everything will become simple, but it is not easy to do this. 50 annotation tags have been defined (there are several will be released in the next draft), each has its own default rules and other operations. Of course, I really don't want EJB3.0 to become an eJB2.1 "EJB 3.0 = EJB 2.1 for Dummies" (I hope this equation is not to be established). Finally, I still can't help but give some opinions: l First, the specification does make it easy for repeated deployment, and there is a simple mode to access the runtime environment. I still think that the home interface should give up.
l In an earlier EJB specification, entity beans are used to map a persistent storage. Theoretically (perhaps only theory) may need to map entity beans to a legacy EIS (Enterprise Information System) system. This is good for future considerations, and more business data models can be used to use entity Beans. Also, their accompanying complexity makes the entity bean is not optimistic. In the draft submitted, an entity bean is just a map of a database. And is more simple development based on non-abstract persistent mode and simple data access mode.
l I reserved the model change, I think it is not good to pay attention to the SQL script segment in EJB. Some developers fully oppose some "SQLness" (such as @Table and @Column comments). My point is that these SQLness is good, accordingly, we can clearly know what we have to do in the end. But some SQL segments I seem to be very good, such as columnDefinition = "blob not null", which makes the coupling between EJB code and SQL too close.
l Although the support of local SQL seems to be very attractive, it is actually embedded in the EJB code is a very bad idea. Of course, some methods can avoid hard coding SQL in EJB, but this should be described in the specification without being a model that some developers know themselves.
l Suppose @Table comments are only used for classes. Table names defined by the Name property of the @Table annotation at runtime will have to correspond to an actual database table. The norms should be given a clear description and consistent mode.
l The specification also requires more clear instructions of client programming models, especially ordinary Java clients. All references in the specification assume or imply with the EJB client. And there is no clear statement on the backward compatibility of the client in the specification.
l Transient comments should be renamed to avoid conflicts with existing Transient keywords. In fact, at this point we are more happy to depth from the Configuration-By-Exception principle and define a @Persistent annotation to define the persistence field. @Persistent comments can be just a tag annotation or it can have several properties to associate an O / R mapping comment.
Association with other specifications
It is currently possible to affect the JSR of EJB3.0 has JSR175 (Java language metadata tools) and JSR181 (Java Web service metadata)
JSR175 has been initially completed and will not have too much conflict with EJB3.0; but JSR181 has two associated places with EJB3.0:
l Web Service Interface: The EJB specification will adopt a mechanism to adapt to JSR181 so that you can implement a bean as a web service and tell Web Service how to be called by the client.
l JSR 181 plans to use different mechanisms to handle security issues. In the early specification, EJB is recommended to use a consistent mechanism, but JSR 181 plans to use a slightly different way (SecurityRoles and SecurityIdentity notes). The same rule is also existed in the definition of the same Runs annotation. This problem is still in the resolution will eventually maintain its consistency in the J2EE layer specification. Some development specifications in J2EE 1.5 may be associated with EJB3.0. There is no other development specification in addition to several associations mentioned above and conflicts with EJB3.0.
Conclude
We have a long way to go before the development of EJB is simple and efficient. Standardization has made a good role in the development of EJB development. The proposal of the O / R mapping model is also in the early stage, and the standardization organization is improving it. I hope it should not be too complicated and do not have an excessive coupling with SQL. Let us not just stay in expectations, hopes, thinking, thinking, and request: Propose your ideas and send your recommendations to the Specification Organization EJB3-FEEDBACK@sun.com. JCP is not a very democratic organization, but your suggestion must be valuable.
The view of this article is that the author's personal advocacy does not have any relationship with the author's company. The author is very grateful to Hemant Khandelwal to publish this article.
The downloaded code is an example code for the draft ejb3.0. This example is not verified because there is no tool and environment. These code only exemplify future EJB3.0 probably.
Anil Sharma is a senior programmer for BEA SYSTEM development WebLogic Integration products. Before joining the BEA, Oracle and PRAMATI were added and committed to studying J2EE technology. In the spare time it likes to listen to music watching movies; he also participates in some open source projects.
