Hmm, wouldn't you at the very least set up a Business Delegate. You would never want
your Client calling an Entity Bean. You can also have a "Session Facade" not a
"Session Bean Facade." There is a big difference between those, correct? It seems
the Session Facade would keep network traffic down. A Session Bean Facade seems to
increase network traffic. I don't seem much need for the Session Bean Facade pattern
anymore. It seems to have been replaced with the Business Delegate and the Session
Facade.
>>> Bill Leonard <[EMAIL PROTECTED]> 09/05/01 03:34PM >>>
Some more information (this also serves as a summary/distillation of the
original post):
I tried to make sure that the reasons for using SB Facade to EB in the past
-- encapsulate interaction of multiple EBs, avoid long transactions, reduce
network overhead of client interacting with multiple entity beans -- were
not an issue here because the example uses a single entity bean. FOR THIS
EXAMPLE, whether the client interacts with a Session Bean facade or the
entity bean, it doesn't matter in terms of encapsulation, avoidance of long
transactions and reduction of network overhead because the client would be
interacting with a SINGLE entity or session bean.
So ... I'm trying to see if separation of responsibilites is a good enough
reason to provide a SB facade IN THIS CASE. With separation of
responsibilities, we get easier maintenance and the use of
object-to-relational tools for generation of the persistence code. But we
also get another bean. Are these enough of an advantage to use a SB Facade?
Again, the example case is not as straightforward because of the following:
1. The 'freshness mechanism' is closely associated with the object's
persistence.
2. The client is making a request to a single bean, whether it's an entity
bean or a session bean. It will not be making multiple requests that are
all part of the same transaction nor is it making requests to multiple beans
(this means that, again, we don't need to create a facade to reduce network
overhead or encapsulate interaction or avoid long transactions).
Thanks again,
Bill
===========================================================================
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".
==========================================================================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".
