Jintong EJB [2]

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

Develop beans
I. Introduction to session beans
EJB can be divided into two types by function: session beans and entity beans.
Enterprise Bean class
To enable bean to work in any container, Bean must be attached to the interface. In EJB, enterprise Bean class provides the implementation of enterprise Bean components. This is a simple Java class that follows the interface.
An enterprise Bean class contains the Implementation Details of components. The implementation of Session Bean is different from the implementation of Entity Bean,
A session beans completes a connection or session for a single customer until the customer completes the connection or session, or the system stops unexpectedly. When a new client accesses a session beans from the EJB server, the EJB container creates a new session beans instance until the session ends. session beans must implement the javax interface. EJB. sessionbean.
Entity beans implementation interface javax. EJB. entitybean describes the data in a specific data source, which can exist in the EJB iner for a long time. It does not disappear with the unexpected suspension of the system and can be accessed by multiple customers at the same time.
The EJB specification defines the standard interfaces that many bean classes can implement. Defines all the methods required by bean classes. Containers call these methods to manage beans.
The most basic interface that all bean classes (whether session bean or entity bean) must implement is the javax. EJB. iseisebean interface.
Public interface javax. EJB. enterprisebean extends java. Io. serializable
{
}
It inherits java. Io. serializable.
All session beans must implement javax. EJB. sessionbean,
All entity beans must implement javax. EJB. entitybean.
EJB object
When you want to use an enterprise Bean class instance, you do not have to call the method directly on the actual instance. The call process is intercepted by the EJB container, and the bean instance is represented by the objects in the container.
1. enterprise Bean class cannot be called directly through the network. We know that the EJB container can manipulate the network, so it packs beans into objects that can be used on the network through the container.
2. By intercepting requests, the container can automatically perform many necessary management tasks.
3. The EJB container can track which method is called and display its usage on the user interface of the system administrator.
Therefore, the EJB container can be seen as an indirect layer between the client code and the bean. This indirect layer uses a separate network object to represent itself. This object is called an EJB object.
The EJB object is the physical part of the container. All EJB objects have code that meets the special requirements of the container. Therefore, container providers provide specialized tools to automatically generate class files for EJB objects.
Remote Interface
As we have learned before, the bean client calls the method on the EJB object to call the bean. to execute it, The EJB object must copy every business method in the bean class. However, how can we make the automatically generated EJB object know which method to copy? This uses a special interface written by the bean provider, which copies all the business logic methods associated with the Bean class. This interface is called a remote interface.
This interface must comply with the definition of the EJB specification. All remote interfaces must be inherited from the general interface provided by Sun, that is, 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 preceding methods are required for all EJB objects. You do not need to implement these methods. The implementation of these methods is automatically generated by the container when an EJB object is generated.

The client code works with the bean by calling javax. EJB. ejbobject.

Java RMI and EJB objects
You should note that Java. EJB. ejbobject inherits java. RMI. Remote. Java. RMI. remote interface is part of Java remote method call (RMI). Any object implementing java. RMI. Remote is a rmote object and can be called by another Java virtual machine.
The EJB object provided by the container implements the remote interface and indirectly implements Java. RMI. remote, which means that your EJB object fully meets network requirements and can be called by other Java virtual machines on the network. Of course, the EJB interface must also comply with the EJB specification.
EJB remote interfaces must comply with Java RMI remote interface specifications. For example, for error handling, the two are the same.
Remote interfaces must also comply with the Java RMI parameter passing specifications. Nothing can be passed over the network through VM method calls. The passed parameters must comply with the RMI type.
EJB also inherits the advantages of RMI. For RMI, the physical address of the remote object you are calling is invisible. This feature also applies to EJB. The Customer Code does not need to care whether the EJB object being used is transmitted from the neighboring computer or from internat. In this way, the EJB object can be in the same Java VM as the client.
EJB ensures the transparency of local distributed components. This transparency is necessary for multi-layer configuration. Client code is very easy to transplant, not limited to special multi-layer configuration. The EJB container can be executed locally in an optimized manner.

Home object
We can see that the client code processes the EJB object and never directly operates on beans. So how can the client obtain the reference of the EJB object?
The client does not directly instantiate the EJB object. Because EJB objects can exist on different machines. Similarly, EJB makes the local transparent, so the client does not know its exact location.
The client code obtains the reference of the EJB object through the EJB object factory. This factory is called the home object in the EJB specification. It mainly plays a role:
Create an EJB object.
Find an existing EJB object.
Delete an EJB object.
In some details, the EJB object factory has the same characteristics as the EJB object.

Home Interface
The home interface defines the methods for creating, deleting, and searching for EJB objects. The home object of the container implements the home interface.
Generally, EJB defines many methods that must be supported by all home interfaces. These required methods are defined on the javax. EJB. ejbhome interface. The home interface must inherit the java. EJB. ejbhome interface.
Public interface javax. EJB. ejbhome
Extends java. RMI. Remote
{
Public abstract ejbmetadata getejbmetadata ()
Throws java. RMI. RemoteException;
Public abstract void remove (handle)
Throws java. RMI. RemoteException
Javax. EJB. removeexception;
Public abstract void remove (Object primarykey)
Throws java. RMI. RemoteException,
Javax. EJB. removeexception;
}
Javax. EJB. ejbhome Interface
Note that javax. EJB. ejbhome inherits java. RMI. Remote, which means that the home interface also supports RMI remote objects, and the passed parameters are the same as those of RMI.

Home object

Methods required for all home objects
Configuration Descriptor
The configuration descriptor allows the EJB container to provide implicit middleware services to enterprise-level Bean components. Implicit middleware service is a service that bean can obtain automatically without decoding any middleware API.

Special attributes of bean
Finally, you need a Java-based bean property file. Bean reads these attributes at runtime. These attributes are used when bean functions are used.

EJB-JAR File
Once bean classes, home interfaces, remote interfaces, configuration descriptors, and bean attributes are generated, We can package them into an entity. This object is called an EJB-JAR file. This is a compressed file.

Create an EJB-JAR File

What is Session Bean?
A session beans completes a connection or session for a single customer until the customer completes the connection or session, or the system stops unexpectedly. Session beans must implement the javax. EJB. sessionbean interface.

Session Bean survival
The main difference between session beans and entity beans is their lifetime. The session bean has a short lifetime. The session time is the same as that of the customer. When the client is connected, the EJB container will destroy the Session Bean.
On the contrary, entity beans can survive for quite a long time. entity beans are a part of permanent access, such as databases.
Session Bean cannot store permanent data, but it can perform database operations.
All session beans need to manage the callback method, which is called by the container regularly to warn important events of the bean. This method can only be called by the container.

Conversational versus nonconversational session beans

How to Write a Session Bean
To write a Session Bean class, you must implement the javax. EJB. sessionbean interface.
Public interface javax. EJB. sessionbean
Extends javax. EJB. iseisebean
{
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;
}
Both Session Bean and Entity Bean inherit the javax. EJB. iseisebean interface.
Let's take a closer look at the various methods in the interface:
Setsessioncontext (sessioncontext CTX)
The container calls this method to connect to the bean through the session context. Bean can query the status and security status of the current transaction from the container through the session context.
Import javax. EJB .*;
Public class mybean implements sessionbean {
Private sessioncontext CTX;
Public void setsessioncontext (sessioncontext CTX ){
This. CTX = CTX;
}
...
}

Ejbcreate (...)
Used to initialize your session bean. You can define multiple ejbcreate () methods with different parameters to initialize the bean using different methods.
Import javax. EJB .*;
Public class mybean implements sessionbean {
Private int membervariable;
Public void ejbcreate (INT initialvalue ){
This. membervariable = initialvalue;
}
...
}
The ejbcreate () method is the callback method that the container can call. The client code cannot call it because the client cannot directly process beans ?? They must pass the parameters through the container, but the client must use some method to pass the parameters to the ejbcreate method. The client provides the initialization parameters. The home interface is the interface factory used by the client to initialize the call. You must copy every ejbcreate () method in the home interface. For example, if you have the following ejbcreate method in the bean class
Public void ejbcreate (int I) throws...
Then you must have the following create () method in your home interface
Public void create (int I) throws...
The client calls the CREATE () method in the home interface and passes the parameter to ejbcreate ().
Ejbpassivate ()
If there are too many instance beans, the EJB container can deactivate some of them and write them to a temporary storage space, such as a database or file system. Containers release the space they apply.
Import javax. EJB .*;
Public class mybean implements sessionbean {
Public void ejbpassivate (){
<Close socket connections, Etc...>
}
...
}
Ejbactivate ()
When the customer needs to use the passive beans, the container re-imports the passive beans into the memory to activate them.
The bean is caused by memory. In this case, you need to obtain the resources required by the bean again.
Import javax. EJB .*;
Public class mybean implements sessionbean {
Public void ejbactivate (){
<Open socket connections, Etc...>
}
...
}
Ejbremove ()
This method is called when the container removes the Session Bean instance. All beans have this method, and there is no parameter. It releases all resources to be allocated.
Import javax. EJB .*;
Public class mybean implements sessionbean {
Public void ejbremove (){
<Prepare for destruction>
}
...
}
The container can call the ejbremove () method at any time. However, if an exception occurs, the container may be prohibited from calling this method.

Business Method
Some methods to solve business problems should be defined: for example:
Import javax. EJB .*;
Public class mybean implements sessionbean {
Public int add (int I, Int J ){
Return (I + J );
}
...
}
Because the client needs to call these methods, you must list these methods in the bean remote interface.

How to call session beans
Now let's look at the customer side. The customer side should solve some practical problems by using one or more beans.
There are two different clients:
Java RMI-Based Clients: this client uses JNDI to locate objects and JTA to control transactions.
Client: the client can also write data using the CORBA standard. The client of CORBA uses the COs Naming Service to locate objects on the network, and uses the OTs of CORBA to control transactions.
Whether using CORBA or RMI, typical client code must be implemented:
1. Locate the home interface
2. Use the home interface to create an EJB object
3. Call the business method on the EJB object
4. Clear the EJB object
Locate the home interface
The client uses jndl to locate the home object.
Roles of jndl in J2EE
One of the goals of J2EE is to enable the application to implement "write once, run anywhere ". Any Java code running on enterprise-level configurations should be unrestricted in the multi-layer structure. Therefore, the positioning must be transparent.
J2EE uses jndl To implement transparent positioning. Existing directory services such as Netscape Directory Server, Microsoft Active Directory, IBM Lotus Notes.
We usually use the directory service to store usernames, passwords, machine locations, and printer locations. The J2EE extended Directory Service stores local information about resources. These resources can also be home objects, enterprise-level bean environment attributes, database drivers, information service drivers, and other resources. When using the directory service, you do not have to worry about the exact machine name and machine address in some application code, which ensures code portability. No matter where the resource is, you do not need to re-compile the code.
Jndl adds value to enterprise-level configurations by providing a standard interface for local users, machines, networks, objects, and services.
To locate resources in J2EE, you must perform the following two steps:
1. Use the nickname in the configuration descriptor to associate the resource. J2EE binds the nickname to the resource.
2. The resource client uses the nickname in jndl to locate the resource.

How to Use jndl to locate the home object
The client does not have to care about the network of the home object. Jndl provides nicknames for the home object to locate the home object. The nickname can be used to obtain the reference of the home object.
Specifically, the client code must perform the following steps for reference through jndl.
1. Create an environment. You must configure the directory service to be used, including the user name and password required for identity authentication.
2. Create an initial context. The initial context is the local starting point for connecting the directory structure. Obtain the set environment attribute through the initial context.
3. Get the home object. Execute the Lookup () operation and return a remote RMI object.

Get reference of home object
/*
* Get System Properties for JNDI Initialization
*/
Properties props = system. getproperties ();
/*
* Form an initial context
*/
Context CTX = new initialcontext (props );
/*
* Get a reference to the home object-
* Factory for EJB objects
*/
Myhome home = (myhome) CTX. Lookup ("myhome ");
Create an EJB object
After obtaining the home object, you can use the home object as the factory for creating the EJB object. Call the CREATE () method to create an EJB object.
Myremoteinterface ejbobject = home. Create ();
No parameter is required because no initial parameter is required for stateless beans.
Call Method
After the client has an EJB object, it can call the method. When the client calls a method on the EJB object, the EJB object must select a bean instance to respond. An EJB object can be used to create a new instance or reuse an existing instance.
Ejbobject. Add ();
Destroy an EJB object
Call the remove () method on the EJB or home object to destroy the EJB object.
Ejbobject. Remove ();