Thanks, Dawn, for looking into this.
I'm having some trouble understanding how the Session Facade would keep
network traffic down:
We were thinking of using a wrapper/facade object on the client to hide the
EJB knowledge from the client -- and that's it -- meaning, it would just
delegate to the Session Bean or Entity Bean on the server. Another example
would be to create a Session Facade that contains the code for accessing the
entity beans and going to the device. In the first case, we get the same
network overhead whether we use the facade or not. In the second case, we
actually get additional network overhead because the client is making all
the calls.
first case:
class SessionFacade
{
int getNumCards()
{
// just delegate -- one network call
sessionBean.getNumCards() -OR- entityBean.getNumCards();
}
}
second case:
class SessionFacade
{
// client would use this local java object and now make multiple
network calls
int getNumCards()
{
if (freshnessEntityBean.isFresh() == STALE)
{
freshnessEntityBean.update();
etc.
}
}
}
-----Original Message-----
From: Dawn Lewis [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 05, 2001 4:57 PM
To: [EMAIL PROTECTED]
Subject: Re: Entity and Session Facade Design Debate
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".
===========================================================================
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".
