Javier Deniz wrote:
> I would expect EB being quite close to the object model and the session
> beans being more closed to the client needs. Different session beans may
> be used to match different kinds of clients needs. If we need to keep
> state in the server (stateful session bean), this is even more clear.
The flaw with EBs being close to the object model is that most business
logic involves traversal of the object graph and this becomes very
inefficient when each object is an EB. I was delighted to read Chris
Raber's notes acknowledging this. When the relational guys say it you may
argue self-interest, but when the OODBMS guys say it you really have to
start believing it.
I'd only disagree with Chris on one point, He proposed (if I understood
correctly) that EBs partition the object graph. I don't believe this is
practical or necessary.
It's not practical because different applications might want to make a
radically different use of the objects (eg order items would be in an order
bean for the purposes of order entry and fulfilment, but would be in a
stock-type bean for purpose of stock checking).
It's also not necessary, because we gain the benefit of AD-time reuse of
the objects when constructing EBs, and we get the additional benefit of
run-time reuse of EBs when we extend the application to enable another
channel for taking and fulfilling orders.
Ian McCallion
CICS Business Unit
IBM Hursley
[EMAIL PROTECTED]
Tel: ++44-1962-818065
Fax: ++44-1962-818069
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
