Editing EJB (section)

===Session Beans===
Session beans are typically used to model business processes or tasks. A session bean might model a set of e-mailing services or credit card validation service. Session beans are non persistent, can if neccessary be transactional, but that has to be implemented. Es gibt zwei Formen von session beans: stateful und stateless. An EJB 3.0 session bean is a POJO managed by the EJB container, which are annotated with @stateless or @stateful. Additionally the the business methods have to be specified in a Plain Old Java Interface (POJI).
By design, the EJB specification disallows the same Business interface to be marked as @Local as well as @Remote (this restriction has been added in a revision to the PFD). The reason for this is that remote interfaces have different semantics to local interfaces, and it is usually inappropriate for the same method to be exposed as a remote interface as well as local interface. The problems are two-fold:
#Remote interfaces must typically be designed to be coarse-grained.
#Remote interfaces do not support the pass-by-reference semantics of parameter passing as in local interfaces.
Having separate Remote and Local interfaces forces designers to think about how the interfaces will be used and ensure that the design is optimised for the use case. It also reduces the chances of errors caused by incorrect semantics, such as clients relying upon ability to pass parameters by reference.
Local Interfaces can only be uses in the same application (ear-file), not on the same server.

====Stateless Session Beans====
In a stateless session bean (SLSB), the client-side stub object can route your method call to any bean instance that happens to be available in the container-managed object pool. Hence, you should not have any field variables to store the bean state in the bean class.
To define a session bean, you first need to define the local and remote service interface containing all its business methods. The session bean interface is just plain old Java interface without any annotation e.g.

 public interface Calculator {
   public double calculate (int start, int end, double growthrate, double saving);
 }
 public interface RemoteCalculator {
   public double calculate (int start, int end, double growthrate, double saving);
   public String getServerInfo ();
 }

and the implementation class:
 import javax.ejb.*  // for annotations
 
 @javax.ejb.Stateless                                                     
 @javax.ejb.Local ({Calculator.class})                                    // specification of the local interface or direct at the interface
 @LocalBinding (jndiBinding="EJB3Trail/LocalCalculator")                  // optional
 @javax.ejb.Remote ({RemoteCalculator.class})                             // specification of the remote interface or direct at the interface
 @RemoteBinding (jndiBinding="EJB3Trail/RemoteCalculator")                // optional
 public class StatelessCalculator 
   implements Calculator, RemoteCalculator {
   public double calculate (int start, int end, double growthrate, double saving) {
     double tmp = Math.pow(1. + growthrate / 12., 12. * (end - start) + 1);
     return saving * 12. * (tmp - 1) / growthrate;
   }
 }

The default naming binding is <EAR-FILE-BASE-NAME>'''/'''<EJB-CLASS-NAME>'''/'''('''local'''|'''remote''').

=====Features=====
* not bound to a client, can be pooled
* multi-method transactions by client or within one method
* methods can be published as web service

====Stateful Session Beans====
If the client invokes method calls against the same bean stub, the calls are always tunneled to the same bean instance in the container. So, all field variables in the bean instance retain their values as long as the client application retains the bean stub (or reference for a local client). In a web application, the servlet (or JSP page) caches the bean stub as an attribute in the HttpSession object. It is very important to note that the stateful session bean class must implement the Serializable interface so that the container can serialize them and store them to preserve the state information when the bean instances are not in use.

=====Features=====
* bound to a client with a client specific state (conversational state)
* can be passivated, if not in transaction
* methods cannot be published as web service

====Message-Driven Beans====
They are used for implementing asynchronous communications. You can't call methods directly. A MDB is the endpoint of a communication. It can be called by JMS or a web service. MDBs can be transactional, but not persistent. They are useful for long-lasting use cases or services to non-block the client.