20100723 (ejb study)

A session bean is similar to an interactive session. A session bean is not shared; it can have only one client, in the same way that an interactive session can have only one user. Like an interactive session, a session bean is not persistent. (That is, its data is not saved to a database.) When the client terminates, its session bean appears to terminate and is no longer associated with the client.

Stateful Session Beans
The state of an object consists of the values of its instance variables. In a stateful session bean, the instance variables represent the state of a unique client-bean session. Because the client interacts (“talks”) with its bean, this state is often called the conversational state.
The state is retained for the duration of the client-bean session. If the client removes the bean or terminates, the session ends and the state disappears. This transient nature of the state is not a problem, however, because when the conversation between the client and the bean ends there is no need to retain the state.

Stateless Session Beans
A stateless session bean does not maintain a conversational state with the client. When a client invokes the methods of a stateless bean, the bean’s instance variables may contain a state specific to that client, but only for the duration of the invocation. When the method is finished, the client-specific state should not be retained. Clients may, however, change the state of instance variables in pooled stateless beans, and this state is held over to the next invocation of the pooled stateless bean. Except during method invocation, all instances of a stateless bean are equivalent, allowing the EJB container to assign an instance to any client. That is, the state of a stateless session bean should apply accross all clients.
Because stateless session beans can support multiple clients, they can offer better scalability for applications that require large numbers of clients. Typically, an application requires fewer stateless session beans than stateful session beans to support the same number of clients.

A message-driven bean is an enterprise bean that allows Java EE applications to process messages asynchronously. It normally acts as a JMS message listener, which is similar to an event listener except that it receives JMS messages instead of events. The messages can be sent by any Java EE component (an application client, another enterprise bean, or a web component) or by a JMS application or system that does not use Java EE technology. Message-driven beans can process JMS messages or other kinds of messages.
When a message arrives, the container calls the message-driven bean’s onMessage method to process the message. The onMessage method normally casts the message to one of the five JMS message types and handles it in accordance with the application’s business logic. The onMessage method can call helper methods, or it can invoke a session bean to process the information in the message or to store it in a database.
When a message arrives, the container calls the message-driven bean’s onMessage method to process the message. The onMessage method normally casts the message to one of the five JMS message types and handles it in accordance with the application’s business logic. The onMessage method can call helper methods, or it can invoke a session bean to process the information in the message or to store it in a database.

To create an enterprise bean that allows remote access, you must do one of the following:
Decorate the business interface of the enterprise bean with the @Remote annotation:
@Remote
public interface InterfaceName { ... }
Decorate the bean class with @Remote, specifying the business interface or interfaces:
@Remote(InterfaceName.class)
public class BeanName implements InterfaceName { ... }

If the bean’s business interface is not decorated with @Local or @Remote, and the bean class does not specify the interface using @Local or @Remote, the business interface is by default a local interface. To build an enterprise bean that allows only local access, you may, but are not required to do one of the following:
Annotate the business interface of the enterprise bean as a @Local interface. For example:
@Local
public interface InterfaceName { ... }Specify the interface by decorating the bean class with @Local and specify the interface name. For example:
@Local(InterfaceName.class)
public class BeanName implements InterfaceName { ... }

Whether to allow local or remote access depends on the following factors.
 Tight or loose coupling of related beans: Tightly coupled beans depend on one another. For example, if a session bean that processes sales orders calls a session bean that emails a confirmation message to the customer, these beans are tightly coupled. Tightly coupled beans are good candidates for local access. Because they fit together as a logical unit, they typically call each other often and would benefit from the increased performance that is possible with local access.
 Type of client: If an enterprise bean is accessed by application clients, then it should allow remote access. In a production environment, these clients almost always run on different machines than the Application Server. If an enterprise bean’s clients are web components or other enterprise beans, then the type of access depends on how you want to distribute your components.
 Component distribution: Java EE applications are scalable because their server-side components can be distributed across multiple machines. In a distributed application, for example, the web components may run on a different server than do the enterprise beans they access. In this distributed scenario, the enterprise beans should allow remote access.
 Performance: Due to factors such as network latency, remote calls may be slower than local calls. On the other hand, if you distribute components among different servers, you may improve the application’s overall performance. Both of these statements are generalizations; actual performance can vary in different operational environments. Nevertheless, you should keep in mind how your
 application design might affect performance.
 
 
Although it is uncommon, it is possible for an enterprise bean to allow both remote and local access. If this is the case, either the business interface of the bean must be explicitly designated as a business interface by being decorated with the @Remote or @Local annotations, or the bean class must explicitly designate the business interfaces by using the @Remote and @Local annotations. The same business interface cannot be both a local and remote business interface.

A web service client accesses a stateless session bean through the bean’s web service endpoint implementation class. By default, all public methods in the bean class are accessible to web service clients. The @WebMethod annotation may be used to customize the behavior of web service methods. If the @WebMethod annotation is used to decorate the bean class’s methods, only those methods decorated with @WebMethod are exposed to web service clients.

You package the files in the preceding list into an EJB JAR file, the module that stores the enterprise bean. An EJB JAR file is portable and can be used for different applications. To assemble a Java EE application, you package one or more modules (such as EJB JAR files) into an EAR file, the archive file that holds the application. When you deploy the EAR file that contains the bean’s EJB JAR file, you also deploy the enterprise bean to the Application Server. You can also deploy an EJB JAR that is not contained in an EAR file.

The Life Cycle of a Stateful Session Bean
 The client initiates the life cycle by obtaining a reference to a stateful session bean. The container performs any dependency injection and then invokes the method annotated with @PostConstruct, if any. The bean is now ready to have its business methods invoked by the client.
 While in the ready stage, the EJB container may decide to deactivate, or passivate, the bean by moving it from memory to secondary storage. (Typically, the EJB container uses a least-recently-used algorithm to select a bean for passivation.) The EJB container invokes the method annotated @PrePassivate, if any, immediately before passivating it. If a client invokes a business method on the bean while it is in the passive stage, the EJB container activates the bean, calls the method annotated @PostActivate, if any, and then moves it to the ready stage.
 At the end of the life cycle, the client invokes a method annotated @Remove, and the EJB container calls the method annotated @PreDestroy, if any. The bean’s instance is then ready for garbage collection.
 Your code controls the invocation of only one life-cycle method: the method annotated @Remove. All other methods  are invoked by the EJB container.
 
 
The Life Cycle of a Stateless Session Bean
 Because a stateless session bean is never passivated, its life cycle has only two stages: nonexistent and ready for the invocation of business methods.
 The client initiates the life cycle by obtaining a reference to a stateless session bean. The container performs any dependency injection and then invokes the method annotated @PostConstruct, if any. The bean is now ready to have its business methods invoked by the client.
 At the end of the life cycle, the EJB container calls the method annotated @PreDestroy, if any. The bean’s instance is then ready for garbage collection.

 
The Life Cycle of a Message-Driven Bean
 The EJB container usually creates a pool of message-driven bean instances. For each instance, the EJB container performs these tasks:
 If the message-driven bean uses dependency injection, the container injects these references before instantiating the instance.
 The container calls the method annotated @PostConstruct, if any.
 Like a stateless session bean, a message-driven bean is never passivated, and it has only two states: nonexistent and ready to receive messages.
 At the end of the life cycle, the container calls the method annotated @PreDestroy, if any. The bean’s instance is then ready for garbage collection.

Use @Stateless/@Stateful/@MessageDriven annotation decorating the enterprise bean class. This lets the container know that ConverterBean is a stateless/stateful/messagedriven bean.

Java EE application clients refer to enterprise bean instances by annotating static fields with the @EJB annotation.
@EJB
private static Converter converter;

The web service endpoint implementation class has the following requirements:
The class must be annotated with either the javax.jws.WebService or javax.jws.WebServiceProvider annotations.
The implementing class may explicitly reference an SEI through the endpointInterface element of the @WebService annotation, but is not required to do so. If no endpointInterface is specified in @WebService, an SEI is implicitly defined for the implementing class.
The business methods of the implementing class must be public, and must not be declared static or final.
Business methods that are exposed to web service clients must be annotated with javax.jws.WebMethod.
Business methods that are exposed to web service clients must have JAXB-compatible parameters and return types. See Default Data Type Bindings.
The implementing class must not be declared final and must not be abstract.
The implementing class must have a default public constructor.
The endpoint class must be annotated @Stateless.
The implementing class must not define the finalize method.
The implementing class may use the javax.annotation.PostConstruct or javax.annotation.PreDestroy annotations on its methods for life-cycle event callbacks.
The @PostConstruct method is called by the container before the implementing class begins responding to web service clients.
The @PreDestroy method is called by the container before the endpoint is removed from operation.

Stateless session bean can use a timer, when method A is called by client, if there are some logic that would like to be executed asynchronizely after method A return, method A can create a timer, when the timer is timeout, ejb contatiner will find the method defined in the same bean that is marked using @Timeout and execute it.
Methods annotated @Timeout in the enterprise bean class must return void and take a javax.ejb.Timer object as the only parameter. They may not throw application exceptions.
An enterprise bean usually creates a timer within a transaction. If this transaction is rolled back, the timer creation is also rolled back. Similarly, if a bean cancels a timer within a transaction that gets rolled back, the timer cancellation is rolled back. In this case, the timer’s duration is reset as if the cancellation had never occurred.

A system exception indicates a problem with the services that support an application. Examples of these problems include the following: a connection to an external resource cannot be obtained or an injected resource cannot be found. If your enterprise bean encounters a system-level problem, it should throw a javax.ejb.EJBException. Because the EJBException is a subclass of the RuntimeException, you do not have to specify it in the throws clause of the method declaration. If a system exception is thrown, the EJB container might destroy the bean instance. Therefore, a system exception cannot be handled by the bean’s client program; it requires intervention by a system administrator.

An application exception signals an error in the business logic of an enterprise bean. Application exceptions are typically exceptions that you’ve coded yourself, such as the BookException thrown by the business methods of the CartBean example. When an enterprise bean throws an application exception, the container does not wrap it in another exception. The client should be able to handle any application exception it receives.

javax.ejb.TransactionManagement
Declares whether a session bean or message driven bean has container managed transactions or bean managed transactions.
javax.ejb.TransactionAttribute
When applied at the TYPE-level, designates the default transaction attribute for all business methods of the session or message driven bean. When applied at the method-level, designates the transaction attribute for only that method.

 

The EJB 3.0 spec added Dependency Injection as a main feature. The @Resource annotation can be used to inject several things including EntityManagers, DataSources, Topics, Queues, etc. Most of these are container supplied objects. It is possible, however, to supply your own values to be injected via an <env-entry> in your ejb-jar.xml deployment descriptor. EJB 3.0 supported env-entry types are limited to the following:
java.lang.String
java.lang.Integer
java.lang.Short
java.lang.Float
java.lang.Double
java.lang.Byte
java.lang.Character
java.lang.Boolean

@Inject
Configures a JNDI values for a field or method.
Inject relies heavily on defaults from the field or method name and type. If more information is required, use @Resource, @EJB, or @EJBHome.

@Resource
Configures a JNDI values for a field or method. @Resource is essentially the same as @Inject but provides more configurable options. @Resource can also be used at the Class level to declare a dependency in cases where the session bean loads the JNDI value by itself.
In the following exaple, Resin will call setDataSource method with the data source in "java:comp/env/jdbc/test" before the session is started. The "java:comp/env/jdbc" full name is inferred from the DataSource type.
@Resource(name="test")
private _dataSource;
default JNDI names  javax.sql.DataSource java:comp/env/jdbc 
javax.mail.* java:comp/env/mail 
javax.ejb.EntityManager java:comp/EntityManager 
javax.transaction.UserTransaction java:comp/UserTransaction 
javax.ejb.EJBHome java:comp/env/ejb 
javax.jms.* java:comp/env/jms