Enterprise application "modalities":

Distribution
Scalability
Reliability
Concurrency
Security
Persistence

An EJB container provides many services to the EJB:

Persistence
Security
Transaction management
Lifecycle management (pooling)
Concurrency management
Remote communications

If you don't need any of this stuff, then don't use EJB.

Enterprise JavaBeans:

Decouple application semantics from infrastructure issues (such as transactions, distribution, and security)
Componentize server-side business logic and move it closer to the database
Declarative specification of: transactions, security, scalability, component and environment coupling
Simplifies development of middleware components that are transactional, scalable, and portable
Container provides a component execution system that handles system-level complexities such as threading, transactions, state management, and resource sharing.
Developers write business-logic components that automatically inherit the scalability and enterprise-oriented attributes of the container's component execution system.

An EJB cannot:

Access the local disk using the java.io package.
Create threads.
Use the synchronized key word.
Use the java.awt or javax.swing packages.
Listen to a socket or create a socket server.
Modify the Java SocketFactory.
Use native libraries.
Use read/write static variables

To perform these activities, you must put them on an external RMI or CORBA server.

Stateless SessionBean:

EJB's version of the traditional transaction processing application.
report generation, batch processing, credit card validation, any activity that can be accomplished in one method call
Code is simple (no state management)
Supports heavy loads (scalable)
Methods might need more parameters (uses more bandwidth)
Not synchronized with transactions

Stateful SessionBean:

An agent for the client that manages workflow (business logic and conversational state) and hides the details of many interdependent operations on databases and other beans
The biggest difference between the SFSB and the other bean types is that SFSBs don't use instance pooling. SFSBs are dedicated to one client for their entire life, so there is no swapping or pooling of instances. [Monson-Haefel, p265]
Unlike servlets, a single SFSB will exist per client
A buy/sell session on an e-commerce Web site
Conversational state can be synchronized with transactions
Usually for implementing a multi-page UI wizard, not for remembering long-term user or session info
If: thousands of concurrent users, or, shopping sessions that span weeks; then, Stateful SessionBean is not advisable

EntityBean:

an object view of transactional data in the database.
shared, persistent, independent lifecycle, business data
a transactional object (stateful SessionBean with SessionSynchronization is transactionally aware)

StateLESS Session Bean	StateFUL Session Bean	Entity Bean
More scalable, less powerful	Consumes more resources on the server	Overkill for read-only access to large data sets
Performs tasks independent of the client connected	Performs tasks for a single client	Controls shared access to transactional data
void ejbCreate()	void ejbCreate(arguments), can be overloaded	PrimaryKey ejbCreate(arguments), can be overloaded, void ejbPostCreate(arguments)
Remote create()	Remote create(arguments)	Remote create(arguments), Remote findByPrimaryKey(pk)
Never passivated and activated	Can only be passivated when they are not participating in a transaction	Can be passivated even during a transaction.
Get from pool, delegate method, put to pool	No swapping or pooling of instances - SFSBs are dedicated to one client for their entire life.	Cached (fast, instance maintains exclusive access), Stale (instance stays ready but data is stale), Pooled (scalable)
Can drive transactions, but not receive callbacks	Transactionally aware (SessionSynchronization interface)	Transactional object (ejbLoad and ejbStore)
SBs can use either CMTD or BMTD. Set transaction atttribute on business methods only.	SessionSynchronization interface only with CMTD.	EBs must use CMTD. Set transaction atttribute on most technical methods and all business methods.
Reentrant/loopback okay	Not allowed	Configurable
Container routes concurrent calls to different instances	Concurrent calls from one or more clients are illegal. Clients should not “share” their Stateful Session Beans.	Container manages concurrency through transactions

A transaction:

is a set of activities that relate to each other and must be completed together
is a "unit of work" that accesses one or more shared resources
usually involves an exchange between 2 parties

Transactions serve these functions in J2EE:

Group statements of work together
Isolate concurrent access to data
Control the caching of database data in the entity instances
Control the synchronization of data between the database and the entity bean instances

MVC (servlets talking to EJBs responding to clients through JSP)

A servlet integrates HTTP requests with per-client state (a session), and threads them as individual client requests. The servlet controls which EJBs are accessed and what methods are invoked. User intentions are communicated to the servlet through URL encoding (parameters).
EJBs with their solid transactional nature and their capacity to access back-end systems constitute the model part of the MVC pattern. "Servlet chaining" could be used to build up comparable functionality - but - it suffers from the same problem as piped commands: a one-size-fits-all interface for piping the output of one servlet to the input of another. EJBs provide a truly OO and transactional framework.
JSPs provide the "view" - dynamic content generation.

Read-only access to large data sets

On-line reservation systems, on-line catalogs, applications characterized by:
- read-only access to large data sets
- large number of queries from many users
- some of the query results are large, but all are short-lived
Using EntityBeans is overkill for this type of application, because they individually read each row of data and the server expects to keep that data in memory for a while.
Instead - embed SQL statements in JavaBeans, and use those Beans from JSPs.
- Significantly speeds up the application and reduces the complexity.
- This shortcut is acceptable because data access is read-only and there's little processing logic.
This approach is not suitable for applications that require complex processing or write access to the database.

Quotes:

"At their core, J2EE applications are Java programs that utilize a database."