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.
in this post i wanna share info and comment on chapter 4: j2ee refactoring
PRESENTATION TIER REFACTORING
-- introducing controller
in j2ee, model 2 is preferred to model 1, which means that usually you need a servlet controller as point of contact (POC), the delegation point for controlling the request handling. partition the code with an eye toward modularity and reuse. the controller in turn calls command objects.
for example, if control logic appears in many jsp files, then it should go to controller; if only few jsp file need that logic, then custom tag helper is ok.
-- synchronizer token
basically same as in edition one (used to control reqeust flow). it repeated the point that struct actions are command objects taht extend the controller functionality.
-- localize disparate logic
the authors recommended view helpers to extract business logic from view. such logic includes content retrieval, access control, and adapts model state for display. helper classes can be implemented as java beans or custom tags.
-- hide presentaton tier-specific details from business tier
remove all references to request handling and protocol-related presentatoin tier data strcuture from business tier. for example, servlet/jsp api shouldnt appear in business tier.
for data transfer between tiers, use TO (transfer object).
for request: create a generic type of interface that mirrors the methods of the (presentation tier) framework-specific type.
-- remove conversions from view
extract all conversion code from view and encapsulate it in one or more helper classes.
-- hide resources from a client
e.g., /WEB-INF/ directory.
BUSINESS AND INTEGRATION TIER REFACTORING
-- wrap entities with session
this is a well known j2ee pattern.
-- use BD
BD are POJO that encapsulate the business tier details (lookup service, cache) and intercept service level exceptions on behalf of client.
--merge session beans
session beans represent corase-grained business service.
engity beans represent coarse-grained, transactional persistent data.
--reduce inter-entity bean communication
transform an entity-bean-to-entity-bean relationship into an entity-bean-to-dependent-object relationship.
-- move business logic to session
same as 'wrap entities with session'
-- separate data access code
-- refactory architecture by tiers
on page 105, it gave a architectural tiered system diagram.
-- use a connection pool
done by web/app containers.
here is what i think all critical points from chapter 4.
in this post i start part 2: j2ee pattern catalog
chapter 5 "j2ee patterns overview" is a good tutorial.
on page 135 it said 'there are architecture patterns, design patterns, analysis patterns, and programming patterns'. I think all of them are useful, but we shouldnt look for precise definitions for those patterns, becase they dont exist.
chapter 6: "presentation tier patterns".
first pattern talked is 'intercepting filter'. i think it is mostly based on servlet 2.3 servlet chains, and closely related to 'decorator' and 'chain of responsibility' GOF patterns. it's exact match is 'pipe' concept in unix.
the most important feature of filter is pluggable (preferrably declarative), which makes filters independent of main app code. filter manager and filter chain are optional management objects. in j2ee, the container fills the role of filter manager. a typical use of filter is logging/debugging.
the authors suggested use of standard filter, specified in servlet 2.3 whenever possible, with the bonus of wrapping request/object objects.
the main consequence of filter is 'centralize control with loose coupled handlers'.