* Implement local interface for EJB
The local interface is the new content of EJB 2.0 specification, which allows Bean to avoid overhead of remote calls. Consider the following code.
TestBeanhome Home = (TestBeanhome)
Javax.rmi.PortableRemoteObject.Narrow (CTX.lookup ("TestBeanhome"), TestBeanhome.class;
TestBean Bean = (TestBean)
Javax.rmi.PortableRemoteObject.narrow
Home.create (), TestBean.class;
The first statement means that we have to look for the Home interface. This lookup is made through JNDI, it is an RMI call. Then, we locate the remote object, return to the proxy reference, which is also a RMI call. The second statement demonstrates how to create an instance, involving the Stub program that creates a IIOP request and transmits the request on the network, which is also a RMI call.
To achieve a local interface, we must make the following modifications:
The method can no longer throw a java.rmi.RemoteException, including exceptions derived from RemoteException, such as TransactionRequiredException, TransactionRolledBackexception, and NosuChobjectException. EJB provides equivalent local exception, such as TransactionRequiredLocalexception, TransactionRolledBackLocalexception, and NosuchobjectLocalexception.
All data and return values are passed in a reference, not the transmission value.
The local interface must be used on the machine deployed by the EJB. In short, the client and components of the service must run on the same JVM.
If the bean implements a local interface, its reference is not serialized.
* Improve EJB access efficiency with local reference
The EJB 1.0 and 1.1 specification only define a method of reference another component in the EJB component, that is, through the Remote interface of the bean. If both beans are within the same container, this network overhead is unnecessary. To solve this problem, the EJB 2.0 specification defines a new EJB reference type, namely local reference.
First, two reference types
In order to access a bean from other EJB components, the container provides a special mechanism. This mechanism allows a BEAN provider to reference another EJB home by reference to the "logical name" referenced by EJB. EJB containers use the application deployment descriptor as an EJB constructor, and these references are declared as special projects in the deployment descriptor. In the deployment descriptor, the deployer binds the EJB reference to the component code to other referenced EJBs.
As mentioned earlier, before the EJB 2.0 specification, only one way is referenced in an EJB, that is, through a remote interface, it requires a remote procedure call to the network. If a transaction is completed by multiple bean collaboration, the collection and release of multiple objects over the network will be a considerable job.
The EJB 2.0 specification has added a local interface type that allows Beans to be directly cited to each other in the same container to avoid network overhead of remote interfaces. The local interface is a standard JAVA interface instead of inheriting from RMI. The definition of the EJB component can contain a local interface or a remote interface, or both are defined.
The specified mode of the local reference is the same as the traditional remote reference, that is, specified in the deployment descriptor. In fact, the deployment of the local reference is completely corresponding to the description elements of the remote reference.
Second, create a local interface, access EJB through local interface
To change an existing remote interface to a local interface, there are three places to modify: deployment descriptor, bean interface, and call to EJB. As we introduce how to specify a local reference through the deployment descriptor, now we have to convert the remote interface to the interface, then modify the JNDI lookup call, let it use the new local interface. HOME interface
When you specify the Home interface, you must now import "javax.eb.ejblocalhome instead of" javax.ejb.ejbhome ". The declaration of the interface must also change to inherit it from "EjBlocalHome" (a standard Java interface) instead of inheriting from "EJBHOME". At the same time, the only abnormality that should be thrown from the interface defined by this interface is Javax.ejb.createException, while java.rmi.RemoteException is no longer necessary.
Local interface
When specifying a local interface, you must now import "javax.eb.eblocalobject" instead of "javax.ejb.ebobject". Interface declarations must also be changed to inherit it from "EjBlocalobject" (a local interface) instead of inheriting from "EJBOBJECT".
Execute call
Creating a good interface, after setting the deployment descriptor, the remaining job is to perform JNDI calls to find references to other EJBs. When calling the Remote Interface of the bean, the "Narrow ()" method of javax.rmi.portableremoteObject brings together the RMI call. For local references, this overhead will no longer be necessary, and simply simply perform JNDI to find and appropriate types of type. Below is an example:
Home = (ProductHome) INitctX.lookup ("Java: Comp / ENV / EJB / Product");
It not only improves efficiency, but also the code is more intuitive than the code used to get a remote interface.
The local interface allows two EJB components in the same container to communicate more efficiently. This technology is especially useful for entity beans, because in practice, in practice, in practice, in practice, through the session bean Access entity bean has been more widely recognized.
If you are ready to use a local reference, check if your application server platform supports it. Perhaps we have to wait for a while before the EJB 2.0 specification is wrapped.
*to sum up:
1. The remote interface is the ability to achieve distributed EJB through loss execution, and the local interface is to achieve good execution performance in disabling distributed EJB.
2. WAR to which the JSP or Servlet to call the EJB local interface must be uniformly packaged with EJB JAR.
Document in the file. When the EAR is deployed to WebLogic, JSP, or servlets can call EJB's local interface.
If WAR and JAR are separately deployed, the JSP or Servlet will not call the local interface of EJB.
