SCEA之路--6. Enterprise JavaBeans

Each EJB session and entity bean must have the following classes and interfaces:
• Home (EJBHome) interface
• Remote (EJBObject) interface
• XML deployment descriptor
• Bean class
• Context objects

Home (EJBHome) Interface
The EJBHome object provides the lifecycle operations (create(), remove(), find()) for an EJB.

Remote (EJBObject) Interface
The remote (EJBObject) interface provides access to the business methods within the EJB. An EJBObject represents a client view of the EJB.

XML Deployment Descriptor
The deployment descriptor is an XML (Extensible Markup Language) file provided with each module and application that describes how the parts of a J2EE application should be deployed. The deployment descriptor configures specific container options in your deployment tool of choice.

Business Logic (Bean) Class
The bean class is developed by the bean developer and contains the implementation and the methods defined in the remote interface.

Context Objects for Session and Entity
For each active EJB instance, the EJB container generates an instance context object to maintain information about the management rules and the current state of the instance.

Distinguish Between Session and Entity Beans
A session bean is an EJB that is created by a client and usually exists only for the duration of a single client-server session. A session bean usually performs operations such as calculations or database access on behalf of the client.
An entity bean is an object representation of persistent data maintained in a permanent data store such as a database.

When to Use Entity and Session JavaBeans
• Use entity beans to persist data. An entity bean is a sharable enterprise data resource that can be accessed and updated by multiple users.
• Use stateful session beans when any one of the following conditions is true; otherwise use stateless session beans:
  • The session bean must retain data in its member variables across method invocations.
  • The state of the bean needs to be initialized when the session bean is instantiated.
  • The session bean must retain information about the client across multiple method invocations.
  • The session bean is servicing an interactive client whose presence must be known to the applications server or EJB container.

Stateful vs. Stateless Session Beans
A stateful session bean will maintain a conversational state with a client. The state of the session is maintained for the duration of the conversation between the client and the stateful session bean.
A stateless session bean will not maintain conversational states for specific clients longer than the period of an individual method invocation.

Stateless session bean has more beneficial attributes
• Bean pooling
Any stateless session bean method instance that is not currently invoked is equally available to be called by an EJB container or application server to service the request of a client. This allows the EJB container to pool stateless bean instances and increase performance.
• Scalability
Because stateless session beans are able to service multiple clients, they tend to be more scalable when applications have a large number of clients. When compared to stateful session beans, stateless session beans usually require less instantiation.
• Performance
An EJB container will never move a stateless session bean from RAM out to a secondary storage, which it may do with a stateful session bean; therefore, stateless session beans may offer greater performance than stateful session beans.

Entity Bean Lifecycle States
• Null
The bean instance doesn’t exist.
• Pooled
The bean exists but isn’t associated with any specific entity object.
• Ready
The bean instance has been assigned an entity object identity.

CMP Pros
• Database-independence The container, not the enterprise bean provider, maintains database access code to most popular databases.
• Container-specific features Features such as full text search are available for use by the enterprise bean provider.
CMP Cons
• Algorithms Only container-supported algorithms persistence can be used.
• Portability Portability to other EJB containers may be lost.
• Access The developer has no access to the view and cannot modify the actual code.
• Efficiency Sometimes the generated SQL is not the most efficient with respect to performance.

BMP Pros
• Container independent Entity bean code written for one EJB container should be easily portable to any other certified EJB container.
• Standards based The standard EJB and JDBC APIs can be used for data access calls.
• Datatype access The ability to access nonstandard datatypes and legacy applications is supported.
• Maximum flexibility Data validation logic of any complexity is supported.
• Database specific features The application is able to take advantage of nonstandard SQL features of different SQL servers.
BMP Cons
• Database specific Because entity bean code is database specific, if access to multiple databases is required, the enterprise bean provider will have to account for this in its data access methods.
• Knowledge of SQL The enterprise bean provider must have knowledge of SQL.
• Development time These beans on average take much longer time to develop—as much as five times longer.

Six transaction attributes are possible for container-managed transaction demarcation:
• NotSupported
The bean runs outside the context of a transaction. Existing transactions are suspended during method calls. The bean cannot be invoked within a transaction. An existing  transaction is suspended until the method called in this bean completes.
• Required
Method calls require a transaction context. If a transaction already exists, the bean will use it; if a transaction does not exist, it will be created. The container starts a new transaction if no transaction exists. • Supports
Method calls use the current transaction context if one exists but they don’t create one if none exists. The container will not start a new transaction. If a transaction already exists, the bean will be included in that transaction. Note that with this attribute, the bean can run without
a transaction.
• RequiresNew
Containers create new transactions before each method call  on the bean and commit transactions before returning. A new transaction is always started when the bean method is called. If a transaction already exists, that transaction is suspended until the new transaction completes.
• Mandatory
Method calls require a transaction context. If one does not exist, an exception is thrown. An active transaction must already exist. If no transaction exists, the javax.ejb.TransactionRequired exception is thrown.
• Never
Method calls require that no transaction context be present. If one exists, an exception is thrown. The bean must never run with a transaction. If a transaction exists, the java.rmi.RemoteException exception is thrown.