Here I wanna share my thought on chapter 3: business tier design considerations and bad practices

THE DESIGN CONSIDERATIONS FOCUS ON USING SESSION/ENTITY BEANS.

for session bean, the main consideration is when to use stateless and/or stateful session bean.  the authors repeated the familiar words: 

"a business process that needs multiple method calls to complete the service is a conversational business process.  it is suitably implemented using a stateful session bean."

for web-based applications, i'd rather replace 'business process' in the above words with 'user interaction'.  it is FINE for an unconversational business process to make multiple method calls within a SINGLE user interaction. a business process is conversational in the sense that multiple http request/response round trips are needed.  correct me if i am wrong.

For entity bean.  the authors claimed that they are best suited as coarse-grained business components.  inter-entity-bean dependencies should be avoided. the entity bean should contain bueiness logic that is self-contained to manage its data and ites depend object's data.

the primary key class must implement the optional java.lang.Object methods, such as equals, and hasCode.

the entity bean part of j2ee is the most bad mouthed.  and here I dont see an excellent idea either.  entity bean is a dead fish.


BUSINESS AND INTEGRATION TIERS BAD PRACTICES

-- mapping object model directly to entity bean model
problem: the entity-bean-to-entity-bean relationship ontroduce severe performance implications for remote entity beans.
solution: identify parent-depend object relationship in the object model and design them as coarse-granined entity beans.  each entity bean composes a group of related objects from the object model.

-- mapping relational model directly to entity bean model 
problem:it is bad practice to model each row in a table as an entity bean, this mapping results in a large number of fine-grained entity beans.
solution: design coarse-rained business objects by identifying parent-dependent objects.

-- mapping each use case to a session bean
problem: create fine-grained controllers responsible for servicing only one type of interaction.  the drawback is it can result in a large number of session beans.

-- exposing all ejb attributes via getter/setter methods
solution: user VO (TO) to transfer aggregate data to/from client.

--embedding service lookup in clients
solution: BD, which in turen calls service location

-- using entity bean as read-only object
prblem: result in unnecessary update transactions to the persistent store, due to invocation of ejbStore() method by container, cuz the container makes no distinction between read-only and read-write entity beans.

-- using entity beans as fine-grained objects
prblem: entity beans are meant to represent coarse-grained transactional persistent business components. fine-grained object has little meaning without its association to another object (typically a coarse-grained parent object).

-- storing entire entity bean-dependent object graph
problem: performance can degrade rapidly when loading/storing an entire tree of dependent objects.
solution: store optimization (dirty marker) strategy; lazy loading.

-- expose ejb-related exceptions to non-ejb clients
solution: business delegates (BD) intercept all servicd exception and may throw an application exception.  BD are POJO that are local to the client.

-- using entity bean finder methods to return a large result set
problem: notorious entity bean N+1 problem.
solution: use TO replace remote references.  use DAO to do search instead of ejb finder method.

-- client aggregate data from business components
problem: client actions introduce network overhead due to multiple onvocations.

-- use ejb for long-lived transactions
problem: ejb are suitable for synchronous processing.
solution: jms, mdb.