http://www0.ccidnet.com/tech/guide/2001/06/29/58_2484.html 1. Overview JavaSoft defined EJB specification provides Java developers with a foundation for creating distributed business components. EJB is a Java component that implements business logic, and it complies with the constraints defined by the EJB specification. The EJB component is survived within the EJB container, and the EJB container provides a range of standard services, including transactions, persistence, security, concurrency, etc., which makes application developers do not need to develop these services from scratch. In an enterprise-class distributed application supported by the J2EE application server, you should try to play the role of EJB, the programmer should:
Strictly follow the EJB specification. Use a variety of available tool auxiliary beans development and compatibility tests. From other programmers' experience. There are four types of EJB components in EJB 2.0:
Status Session Bean: Provides a service, but does not save session status information between multiple method calls. There is a state session bean: maintains a session state; each instance is associated with a specific user. Entity Bean: A object-based description representing permanent data is often rows in the database. They have primary keys as a unique identifier. The entity bean has two ways of operation: Container-Managed Persistence, CMP, bean management persistence (BEAN-Managed Persistence, BMP). Message-driven bean: This is a new type of EJB 2.0. Message-driven bean implements integration between JMS (Java Message Service) and EJB to perform asynchronous operations within the server. In order to help you develop EJBs for enterprise-class distributed applications supported by J2EE applications (such as Bea WebLogic Server), some EJB development experiences and techniques have been carefully selected, and the front of each point is specifically indicated by "▲" symbol. This article assumes that the reader is a Java programmer above the intermediate level, and you are familiar with how to write EJB for the application server. Our discussion will be conducted from the following aspects:
Transaction EJB Safety Creating Main Keys When you avoid using stateful session beans to write business interfaces to use messages driven in transactions, transaction skills Almost all EJB applications will be used in a transaction (Transaction). The transaction ensures correctness and reliability, which is essential for e-commerce applications. However, misuse or abuse of affairs affect performance and may even have incorrect results. The session bean itself cannot be transactional, and it is very important to understand this. A common misunderstanding is that when the transaction is aborted, the members variable of the session bean will be rolled back. In fact, the conversation bean is just the resources "propagating" to all the resources they receive. For example, assume that the transaction begins, the session bean has a member variable value of 0. During transaction processing, this member variable is set to 2, and one record is inserted into the database. If the transaction is rolled back, the member variable of the bean does not restore 0 values, but the records in the database will no longer exist. The database is a transactional resource, which will join the session bean transaction, once the transaction rolls back, all databases are also rolled back. ▲ The state of the session bean itself is not a transactional. 2.1 User interaction and transaction performance If the operation is more complicated, there are many, they may result in performance issues. In particular, transactions never include user input operations or other operations that require users to participate. For example, if the user starts a transaction, then go to a lunch or visit another web site, the transaction will not be submitted; the transaction will not be submitted; the transaction will not be submitted; in contrast, it will continue to lock and occupy a valuable server resource. Generally, all transaction boundaries should appear on the server. There are many well-known technologies to avoid long-term transactions in a continuous opening state. When you ask the user to submit, verify the form, you should divide the operation into two transactions: The web page should read the data within a single complete transaction, which is submitted before the form is returned to the user; then modify the data as needed The update of the form is completed in a new transaction. ▲ The transaction process never inserts user input or other operations that require users to participate. 2.2 Entity Bean: Select transaction management mode EJB specification Allow session beans or selects transactions managed by containers, or selects BEAN-managed transactions. The former is managed by the EJB container, and the latter is managed by Bean itself. For a transaction-managed transaction, bean developers declare transaction properties in the deployment descriptor. In this case, the EJB container will automatically start and submit a transaction if necessary, and Bean developers do not need to write code for any management transaction. For BEAN-managed transactions, Bean developers must explicitly launch and submit transactions using transaction interface. The first choice of bean developers will always be a transaction management of containers. BEAN developers must ensure that transactions are submitted or returned. Although the system supports the transaction timing like the BEA WebLogic Server, Bean developers should not rely on this functionality provided, but should release transaction resources as early as possible. This is automatically processed by the EJB container if you use a transaction-managed transaction. ▲ Try to use the container management transaction instead of the transaction management of Bean. Third, EJB security EJB not only supports an illustrative security configuration, but also provides a simple programmable interface for security check inside the bean code. In practice, the security configuration of EJB should be placed under the application of the overall security model. In web-based applications, verification processing is common in the web layer. In this environment, the EJB layer may only contain little security constraints. This arrangement simplifies EJB design, and because security checks are performed in the performance layer, we can modify the application's security policy without modifying the EJB layer.
However, applications with independent programmable clients often need to directly access session beans. Since there is no intermediate layer, access security must be controlled within the EJB layer. Illustrative security control is a preferred safety control method for simple applications. Since security constraints are declared in the deployment descriptor, there is no need to insert a security check code in the business logic of the bean class, making the business logic code more tidy. The illustrative security model is based on the security role declared in the deployment descriptor. If the number of roles is fixed, and it is ideal for the number of security models with the number of customers. For example, an application may include a user role and an administrator role. Since there are only two access modes here, they declare that these roles are feasible in the deployment descriptor. However, when each user is required to have different security constraints, we should not use the illustrative security model, which requires a security check in the EJB code. In addition, it is also common in combination with two safety inspections. For example, an Account (account) bean can use the illustrative security check how to ensure that only registered users can access any way, then in the bean code contains additional security constraints to make sure that each user can only access himself. Account information. ▲ When the application contains only a small amount of role, use the illustrative security check mode; when each user needs to perform a security check separately, use the programming manner. Fourth, how to write primary key for entity beans, whether in permanent storage or EJB containers, EJB primary key classes play a unique identifier. The domain of the primary key class often maps directly to the primary key field of the database. If the primary key is just a single entity bean domain, and it belongs to the Java simple data type (such as java.lang.string), then Bean developers do not need to write custom primary key classes. Instead, Bean developers only need to specify the names of the class and the name of the primary key domain in the deployment descriptor. If the primary key is mapped to a user-defined type or multiple domains, the bean developer must write a custom primary key class. This primary key must implement java.io.serializable and contain each primary key domain. For the CMP entity bean, the domain name must match the name of the corresponding main key field in the bean class, which will enable the EJB container to assign the appropriate CMP domain to the corresponding domain in the primary key class. For example, we can define the primary key of the employee as a compound button, which consists of username, deptnumber, and officenumber, the primary key class code list is as follows:
public final class EmployeePK implements java.io.Serializable {public String deptNumber; public String userName; public int officeNumber; private int hash = -1; public EmployeePK () {} public int hashCode () {if (hash == -1) {hash = deptNumber.hashCode () ^ userName.hashCode () ^ officeNumber;} return hash;} public boolean equals (Object o) {if (o == this) return true; if (o instanceof EmployeePK) {EmployeePK other = (EmployeePK) o; return other.hashCode () == hashCode () && other.officeNumber == officeNumber && other.deptNumber.equals (deptNumber) && other.userName.equals (userName);} else {return false;}} } The primary key class contains the primary key domain. The primary keypad must be a public type; in addition, the primary key must also contain a constructor without parameters. The primary key must implement the HashCode and Equals methods. A large amount of data structure is used inside the EJB container, many of which are through the primary key class index. Therefore, it is critical to the primary key class, correct and efficient implementation of these two methods. The HashCode method returns an integer using the main key domain. The purpose of this function is to generate an integer that can be used to index tables. The HashCode value of the primary key will never change. Therefore, the HashCode value should be constructed from the invisible value. Implementing the Equals method may be slightly complicated. The first line of the Equals method should refer to the reference to the parameters in accordance with its own (THIS), which is checked for the call to the Equals method for its own. Although this is a bit strange from the surface, it is a common operation when the container has a specific primary key object in a data structure. Next, the Equals method should confirm that the reference to the parameter belongs to its own type. If the primary key class is a final type, here simply use the InstanceOf operator to check. If the primary key class is not a final type, reference to the parameter may belong to the derived type of the primary key class. At this time, the equals method must use getClass (). Equals ensures strict matching of the type. Compared with the comparative class, the overhead of the INSTANCEOF operator is smaller, so it is best to define the primary key class as a final type. ▲ The primary key class should be the final type. 5. When avoiding the status session bean stateful session bean represents a single customer and a single bean instance session between state information. There is a status session bean cannot be shared between multiple users. You should not simulate a shared buffer or any other shared resource in the form of a stateful session bean. If you want multiple customers to access a single EJB instance, use the entity bean. ▲ Stateful session beans cannot be shared by multiple users. Since each customer must have its own stateful session bean instance, the number of bean instances and the demand for related resources will grow quickly.
If the application allows stateless programming mode, the stateless session bean has better scalability than stateful session beans. After the application uses a status session bean instance, the REMOVE method should always be called. This allows the EJB container to release container resources as soon as possible. ▲ The stateless session bean has better scalability than stateful session beans. If you want to integrate stateful session beans in web applications, Bean developers should be cautious. Status Session Bean does not allow concurrency to call. As mentioned earlier, multiple requests may result in concurrent calls for stateful session beans. Unfortunately, this error is usually appearing in a normal load state, so it often overlooks during testing. For this reason, it is recommended to use stateful session beans within the request range; for applications that need to be saved between multiple requests, use entity beans or servlet sessions. Sixth, the relationship between the remote interface and EJB classes often makes the programmers developed by many beginner EJBs puzzles. The relationship between remote interfaces and EJB classes is necessary to make the container intercepted all the method calls to EJB. It is easy to be confused that the EJB class implements the method defined by the remote interface, but the EJB class does not implement the remote interface itself. In fact, the EJB class never implements a remote interface. Although the EJB specification allows EJB classes to implement remote interfaces in fact, this method will lead to severe and difficult to understand. The problem that enables the EJB class to implement the remote interface is that in this case, the EJB class may be passed as a parameter to any desired remote interface type as parameter. Keep in mind that the existence of remote interfaces enables the container to intercept method calls to provide services such as transactions. If the bean class is used, the method call will be done directly - thereby causing a risk that the container cannot intercept the method call, or the container cannot be intervened when an error occurs. If (as recommended) The EJB class does not implement a remote interface, this problem is displayed when compiling: When we pass the Bean class as a parameter of the remote interface type, the Java compiler will refuse to compile. ▲ Never implement a remote interface in the EJB class. WebLogic Server provides an EJB compliance inspector that can find all methods that have been defined in remote interfaces, but the EJB class is not implemented. Seven, transaction with message-driven bean message driver EJB integration EJB and JMS. Like other EJB types, the message-driven EJB is survived within the EJB container, and it also benefits from various services of the EJB container, such as transactions, security, and concurrent control. However, the message-driven EJB is not interacting with the customer. Instead, the message-driven EJB is a JMS message listener. The client publishes the message to the JMS destination, then, the JMS provider and EJB container collaborate to send the message to the message-driven EJB. Like other EJBs, the message-driven EJB can utilize the EJB container transaction service. However, since these beans will never interact with our customers, they will never participate in the customer's transaction. Like session beans, in the EJB-JAR.XML deployment descriptor, message-driven EJB can choose from BEAN management transactions or by container. For the latter, EJB can specify the Required or NotSupported property (because there is no customer transaction, there is no need to support other transaction attributes). If the properties of the transaction are NotSupported, the message-driven EJB will not participate in the transaction. If the Required property is specified, the EJB container automatically starts the transaction. The message received from JMS Queue or Topic is included in the transaction, and then the message-driven BEAN's OnMessage method is called in the transaction environment. When the OnMessage method returns, the EJB container is submitted to the transaction.
