Jing EJB [2] (reproduced)

Reprinted from: http://www.java-cn.com/technology/technology_detail.jsp? Id = 781

Developing Beans 1. Session Beans Introduction Press EJB into two categories: Session Beans and Entity Beans. Enterprise-class bean classes In order to make Beans can work in any container, Beans must be attached to the interface. In EJB, the implementation of enterprise-level bean components is provided in Enterprise Bean Class. This is a simple Java class that follows the interface. An Enterprise Bean class contains the implementation details of the components. The implementation of the session bean is different from the implementation of entity beans, and a session beans completes a connection or session for a single customer, which survives until the client completes the connection and session, or accidentally suspended. When a new customer is accessing from EJB Server, then EJB Container creates a new session beans instance that runs until the session ends, Session Beans must implement interface javax.ejb.sessionBean. Entity Beans implements interface javax.ejb.entityBean, which describes data in a particular data source, which can be existing in the EJB Container for a long time, and will not disappear with the accidental abortion of the system, and multiple customers can be accessed simultaneously. The EJB specification defines the standard interfaces that many Bean classes can implement. There must be a method that must have all Bean classes. Container calls these methods to manage Beans. All BEAN classes (whether conversation beans or entity beans) The most basic interface that must be implemented is the Javax.ejb.EnterpriseBean interface. Public interface javax.ejb.EnterpriseBean Extends java.io.serializable {} is worth noting: it inherits java.io.serializable. All session beans must implement javax.ejb.sessionBean, all entity beans must implement javax.ejb.entityBean. EJB object When customers want to use an instance of Enterprise Bean Class, customers don't have to call methods directly on the actual instance, call The process is intercepted by the EJB container, and the bean instance is represented by the object in the container. 1, Enterprise Bean Class cannot be called directly over the network, we know that the EJB container can manipulate the network, so it is packaged into objects that can be used on the network through the container. 2. By intercepting the request, the container can automatically perform many necessary management work. 3, the EJB container can track which method is called, displaying its usage, etc. on the system administrator's user interface. Therefore, the EJB container can be regarded as a layer existing between customer code and bean. This indirect layer uses a separate network object to represent yourself, this object is called an EJB object. EJB objects as part of the vessel physics; all EJB objects have code for special requirements for containers. Therefore, the container provider provides specialized tools to generate class files from the EJB object. Remote Interface We have learned that the BEAN customer calls the method on the EJB object instead of calling the bean, in order to perform it, the EJB object must copy each business method in the bean class. However, how can I make the automatically generated EJB object know which method is copied? This uses a special interface written by the bean provider, and this interface is copied to all business logic methods associated with the bean class. This interface is called a remote interface. This interface must follow the definition of the EJB specification, and all remote interfaces must inherit from the general interface provided by Sun, Javax.ejb.ejbObject.

EJB object public interface javax.ejb.EJBObject extends java.rmi.Remote {public abstract javax.ejb.EJBHome getEJBHome () throws java.rmi.RemoteException; public abstract java.lang.Object getPrimaryKey () throws java.rmi.RemoteException; public abstract void remove () throws java.rmi.RemoteException, javax.ejb.RemoveException; public abstract javax.ejb.Handle getHandle () throws java.rmi.RemoteException; public abstract boolean isIdentical (javax.ejb.EJBObject) throws java. Rmi.RemoteException;} The above is the method that must have for all EJB objects, you don't need to implement these methods, the implementation of these methods, automatically generated by the container when generating an EJB object. The client code works with Bean by calling Javax.ejb.ejbobject. Java RMI and EJB objects You should notice: java.ejb.ejbobject inherits Java.rmi.Remote. The java.rmi.Remote interface is part of the Java Remote Method Call (RMI), any object that implements Java.rmi.Remote is the RMote object, which can be called by another Java virtual machine. The remote interface is implemented by the EJB object provided by the container, and also indirectly implements Java.rmi.Remote, which means that your EJB object is fully compliant with the network needs, can be called by other Java virtual machines on the network. Of course, the EJB interface must also comply with EJB specification. The EJB remote interface must comply with Java's RMI remote interface specification. For example: Error handling, the same is true. The remote interface must also follow the Java RMI parameter transfer specification. Not anything can be transferred to the network through the VM method, and the passing parameters must comply with the RMI type. EJB also inherits the advantage of RMI, for RMI, the physical address of the remote object you are calling is invisible. This feature also applies to EJB. Customer code does not have to care about the use of EJB objects that are passed on the neighboring computer or from the INTERNAT. In this way, the EJB object can be in the same Java VM at the client. EJB guarantees the transparency of local distributed components. This transparent is very necessary for multi-layer configurations. The client code is very easy to transplant, unrecorded to a special multi-layer configuration. The EJB container can be implemented locally in optimization. HOME object We see that the client code handles the EJB object, and does not directly operate Beans. So how do the client get the reference of the EJB object? The client does not instantiate the EJB object directly. Because the EJB object can exist in different machines. Similarly, EJB makes local transparency, so the client does not know the exact location. The client code gets the reference of the EJB object through the EJB object factory. This plant is a Home object in the EJB specification. It mainly plays the role: establish an EJB object. Find the existing EJB object. Delete the EJB object. In some details, the EJB object plant is the same as the EJB object. Home Interface Home Interface Simple Defines the method of establishing, deleting, and looking for EJB objects. The HOME object of the container implements the HOME interface. Typically, EJB defines many methods that all HOME interfaces must support, these must be defined on the Javax.ejb.ebHome interface, and the Home interface must inherit the java.ejb.ebhome interface.

public interface javax.ejb.EJBHome extends java.rmi.Remote {public abstract EJBMetaData getEJBMetaData () throws java.rmi.RemoteException; public abstract void remove (Handle handle) throws java.rmi.RemoteException javax.ejb.RemoveException; public abstract void remove (Object primaryKey) throws java.rmi.RemoteException, javax.ejb.RemoveException;} javax.ejb.EJBHome interfaces attention javax.ejb.EJBHome inherited java.rmi.Remote, which means home interface also supports remote RMI objects The passing parameters and RMI are also the same. HOME Objects All HOME objects The method configuration descriptor configuration descriptor allows the EJB container to provide an implicit middleware service to an enterprise-level Bean component. An implied middleware service is a service that Beans can get unwanted to decode any middleware API and automatically obtain a service. The special properties of Beans are ultimately, you also need to have a property file based on Java-based bean. BEAN reads these properties at runtime, which will be used when using the Bean function. Once the EJB-JAR file generates the class, HOME interface, remote interface, configuration descriptor, and bean properties, we can pack them into an entity. This entity is called an EJB-JAR file. This is a compressed file. Establishing an EJB-JAR file What is a session bean a session beans to complete a connection or session for a single customer, which survives until the client completes the connection and session, or accidentally abort. Session Beans must implement interface javax.ejb.sessionBean. The main difference between the session bean's survival session bean and entity beans is the length of their survival. The survival of the session bean is short. It is quite equivalent to the customer's session time. The EJB container destroy the session bean when the client is connected. In contrast, the entity bean can survive the time, and the entity bean is part of permanent access, such as a database. Session beans cannot save permanent storage data, but it can perform database operations. All session beans need to manage the Callback method, and the container timing calls it to make a warning for the important events of BEAN. This method can only be called by the container.

How Conversational versus Nonconversational Session Beans Session Bean write writing session bean class must implement the javax.ejb.SessionBean interface public interface javax.ejb.SessionBean extends javax.ejb.EnterpriseBean {public abstract void setSessionContext (SessionContext ctx) throws java.rmi. RemoteException; public abstract void ejbPassivate () throws java.rmi.RemoteException; public abstract void ejbActivate () throws java.rmi.RemoteException; public abstract void ejbRemove () throws java.rmi.RemoteException;} session bean and entity bean have inherited The Javax.ejb.EnterpriseBea interface allows us to look at various methods in the interface: SetSessionContext (SessionContext CTX) container calls this method to connect to the bean through session context. The bean can query the status of the current event and the current security status by session context to the container. import javax.ejb *;. public class MyBean implements SessionBean {private SessionContext ctx; public void setSessionContext (SessionContext ctx) {this.ctx = ctx;} ...} ejbCreate (...) is used to initialize your session bean, can be defined The ejbcreate () method of multiple different parameters is initialized in different ways. import javax.ejb *;. public class MyBean implements SessionBean {private int memberVariable; public void ejbCreate (int initialValue) {this.memberVariable = initialValue;} ...} ejbCreate () callback method is invoked may be a container, the client The code cannot call it, because the client cannot directly handle Beans ?? They must pass through the container, but the client must use some way to pass parameters to the EJBCREATE method, and the client provides initialization parameters. The HOME interface is an interface factory that the client is used to initialize the call. You must copy each ejbcreate () method in the Home interface, for example, if you have the following EJBCREATE Method in the Bean class, you have the following EJBCREATE (INT i) throws ... then you must have the following in your HOME interface CREATE () Method Public Void Create (INT i) THROWS ... Client calls the CREATE () method in the Home interface, pass the parameters to ejbcreate (). Ejbpassivate () If there are too many instance beans, the EJB container can pass some of them, write them to temporary export spaces such as databases or file systems. The container releases the space they apply.

Import javax.ejb. *; public class mybean imports sessionbean {public void ejbpassivate () {} ...} Ejbactivate () When the customer needs to use passivated beans, the container will Revolved by passivated Bean to activate them. BEAN is also caused by memory, and the resources needed to be re-received will be reached. Import javax.ejb. *; public class mybean implements sessionbean {public void ejbactivate () {} ...} ejbremove () calls this method when a session bean instance remove . All Beans have this method, it doesn't have a parameters, which will release all the resources to allocate. Import javax.ejb. *; public class mybean implements sessionBean {public void ejbremove () {} ...} Container can call EJBREMOVE () methods at any time, but if you encounter an exception, it is possible to prohibit Container calls this method. Business methods should define some methods to solve business problems: Import javax.ejb. *; Public class mybean imports sessionBean {public int Add (int i, int J) {Return (i j);} ...} The client wants to call these methods, so you must list these methods in the Remote interface of the bean. How to call session beans We now look at the client, and the client is to solve some realistic problems by using one or more beans. There are two different clients: Java Rmi-based clients: This client uses JTA control transactions by using JNDI positioning objects. CORBA Customer: The client can also use the CORBA standard to write. CORBA Customer uses CORBA Name Service (COS Naming) to locate objects on the network, using CORBA's OTS control transaction. Whether using CORBA or RMI, typical client code must implement: 1 Positioning home objects. One of J2EE's role J2EE's goal is to enable the application to implement "WRITE ONCE, RUN Anywhere". Any Java code running in an enterprise-configured Java code should be unconstrained in multiple layers. Therefore, the transparentization of positioning must be achieved. J2EE implements transparentization of positioning by using JNDL. Products for directory services such as Netscape Directory Server, Microsoft's Active Directory, IBM's Lotus Notes. Usually we use the directory service to store username, password, machine location, printer location, etc. J2EE Extended the local information of the directory service storage resource, which can also be Home objects, enterprise-level beans environment properties, database drivers, information service drivers, and other resources. With directory services, you can do not have to care about the exact machine name and machine address when you have some application code, which ensures the portability of the code. No matter where the resources are, do not need to recompile the code. JNDL adds a value to the enterprise-level configuration by providing a standard interface for local users, machines, networks, objects, and services.