Tutorial for building J2EE applications using JBoss and eclipse Chapter 4

The statefule seesion bean and stateless session beand examples were all completed, and it was still a bit vague, so I read mastering EJB 2nd and Sun's training tutorial sl-351 and finally got a new understanding of EJB.

First look:

The entire request process of EJB

A complete description of the specific process of requesting the EJB method. The home interface of this process uses the ejbhome interface, and the remote ingerface uses the ejbobject interface. The reason for using the interfaces is that an efficient interface ejblocalhome and ejblocalobject are added in EJB 2.0. In fact, it corresponds to ejbhome and ejbobject. You can use ejblocalhome to obtain ejblocalobject references. The two different method calls are mainly different in efficiency, as described in mastering EJB.

Ejbhome-> ejbojbect
1. The client calla local stub.
2. The stub parameters als parameters into a form suitable for the network.
3. The stub goes over a network connection to the skeleton.
4. the skeleton demo-als parameters into a form suitable for Java.
5. the skeleton cballs the EJB object.
6. The EJB object performs needed middleware, such as Connection pooling, transactions, security, and lifecycle services.
7. Once the EJB object cballs the enterprise Bean instance, and the bean does
Its work, each of the preceding steps must be repeated for the return
Trip home.

Ejblocalhome-> ejblocalobject
1. The client calla local object.
2. The local object performs needed middleware, such as Connection pooling, transactions, security, and lifecycle services.
3. Once the enterprise Bean instance does its work, it returns control to the local object, which then returns control to the client.

You can see from the above process that using the local interface can save a few steps. For this interface, I have not figured out how to apply it for the time being. I will put it down for the time being and try it later.

The EJB model of shows all the interfaces available for ejb2.0.

For the example of stateless Session Bean and stateful Session Bean in Chapter 3 and chapter 4, I refer to the Sun sl-351 tutorial. The pictures of the two beans are good. I just copied them.

 Container creates a stateless Session Bean

In step 1, contariner instantiates an EJB object. This feature is used to save resources until the session bean is called or to directly retrieve the existing one from the pool. In mastering EJB p48, how many beans and how many ejbobject beans correspond to an ejbhome depend on the container in use, which may be 1: N, it may be M: N, which is transparent to bean writers and mainly chooses a high-performance container.
Step 2
1. The client calls a business method. If stateless bean cannot be found in the pool, perform the following steps:
A. The container initializes the session context. (Session Context hasn't figured out what it is, so I will study it later)
B. If the bean is found in the pool, move it to the working area. Otherwise, use the constructor parameter.
C. After the session context Initialization is complete, it is referenced to the new bean through setsessioncontext.
D. Use the create method to call ejbcreate in bean. These two methods correspond one by one, and
The bean must have an ejbcreate.
2. Call the business methods in the bean instance.

 Container creates a statelful Session Bean

When a client calls create of home, the following steps are performed.
1. The container initializes the EJB object.
2. The container initializes the session context.
3. Bean will be created with a default constructor (as long as no other constructor is defined)
4. After Session Context Initialization is complete, the reference is passed to bean through setsessioncontext.
5. The create parameter is transmitted by the client through the home object and then to the corresponding ejbcreate bean.

One obvious difference between the two bean types is that when the client calls the create method of the home object, statefule can include parameters, but stateless cannot contain parameters.

The remove of session bean can be performed either through the client or through the server.

Conclusion: A reference to mastering EJB

The enterprise Bean instanceIs a Java object instance of an enterprise Bean class. it contains business method implementations of the methods defined in the remote and/or local interface. the enterprise Bean instance is networkless in that it contains no networked logic.
The remote interfaceIs a Java interface that enumerates the business methods exposed by the enterprise Bean class. In EJB, client code always goes through the remote interface and never interacts with the enterprise Bean
Instance. The remote interface is network-aware in that interface obeys the rules for Java RMI-IIOP.
The local InterfaceIs the high-precision Ming version of the remote interface. use the local interface when you are calling Enterprise beans that live in the same process. your CILS will not undergo stubs, skeletons, network CILS, or financialing/demo-aling of parameters.
The EJB objectIs the container-generated Implementation of the remote interface. the EJB object is a network-aware intermediary between the client and the bean instance, handling necessary middleware issues. all client invocations go through the EJB object. the EJB object delegates callto enterprise Bean instances and implements the remote interface.
The local objectIs the high-precision Ming version of The EJB object. The local object implements the local interface.
The home interface is a Java interface that serves as a factory for EJB objects. client code that wants to work with EJB objects must use the home interface to generate them. the home interface is network-aware because clients
Use it Because SS the network.
The local home interfaceIs the high-precision Ming version of the home interface.
The home objectIs the container-generated Implementation of the home interface. The home object is also network-aware, and it obeys RMI-IIOP's rules.
The local home ObjectIs the high-precision Ming version of the home object. The local home object implements the local home interface.
The deployment descriptorIs an XML file that specifies the middleware requirements of your bean. you use the deployment descriptor to inform the container about the implicit middleware you want, such as how to manage your bean, your bean's lifecycle needs, your transactional needs, your persistence needs, and your security needs.
The vendor-specific filesAllow you to take advantage of vendor-specific features. These files are not portable between application servers.
The EJB-JAR FileIs the finished, complete. ZIP file that contains the above files. it is the unit of deployment and is given to the application server. the Application Server unpacks the EJB-JAR file and loads the bean.