Stateless Session Bean (1) --- definition (not typographical)

Stateless Session Bean is used to complete operations within the lifecycle of a single method. Stateless beans can implement many business operations, but each method cannot be assumed that any other method will be called before it.

This sounds like a limitation of stateless beans. However, this is the most common form of business services so far. Unlike stateful session beans that are suitable for accumulating states in a conversation (such as the shopping cart of a retail application), stateless session beans are designed to perform independent operations very effectively. Stateless session beans can be extended to a large number of clients while minimizing the impact on the overall server resources.

The Session Bean definition is divided into the following two parts:

Zero or multiple business interfaces define methods that a client can call on bean. When no interface is defined, the public method set of bean implementation class forms a logical client interface.

Classes that implement these interfaces are called Bean classes and marked with @ stateless annotations.

Most session beans have a service interface, but there is no limit on the number of interfaces that a session bean can publish to its client. When the server encounters the @ stateless annotation, it knows to treat the Bean class as a session bean. It configures the bean in the EJB container so that other components of the application can use it. The @ stateless annotation and other annotations described in this chapter are defined in the javax. EJB or javax. annotation package.

The following Hello world example of this EJB version contains a service interface. This example contains a single method. There is no annotation or rich interface to indicate that this is a business interface. When Session Bean is implemented, it is automatically treated as a local service interface, and only clients on the same application server can access it. To emphasize that an interface is a local service interface, you can add the @ local annotation to the interface.

(Interface code)

Now we need to consider the implementation of interfaces. This is a general Java class that implements the above interface. The only special thing in this class is @ stateless annotation, marking it as a stateless Session Bean. There are no special restrictions or requirements for launching a business method. It is a normal class of EJB.

(Implementation code)

No interface View

When no-interface-view is introduced in ejb3.1, it is easier to define a local Session Bean and access the local Session Bean from the client. Using the interface-free view to define the same helloservicebean, bean developers only need to create implementation classes without implementing any business interfaces:

(CODE)

The logical interface of the Session Bean contains its public methods. In this example, it is the sayhello () method. The client uses the helloservicebean class as an interface and does not need to consider the details of any non-public methods or implementations. Implicitly, the Client extends the proxy interaction of bean classes and overwrites the business methods to provide standard container services.

One of the advantages of a non-interface view is that it is simple. It does not need to implement a redundant service interface, and further makes the EJB look like a regular JavaBean class. However, because the interface-free view is only applicable to local session beans, this example uses an independent interface of the traditional style to ensure that the stateless and stateful session beans are consistent.

Note only two points for the definition of the stateless Session Bean class. The first is that it requires a constructor without parameters, but when there are no other constructor, the compiler usually automatically generates this constructor. Second, static fields should not be used. This is mainly due to the re-deployment of internal beans.

Many EJB containers create a stateless Session Bean instance pool, and then select any instance to serve each client request. This does not guarantee that the same status will be used between calls, so it cannot depend on this.

 

 

Stateless Session Bean (1) --- definition (not typographical)