But what happens if this is a large project, the no.of commands can become
very huge to manage may be thousands. Moreover you need these command
executor to be redeployed once you want to change something. This means
they have to be deployed in the same EAR files as that of other EJB's.
IMHO we can use the Business Delegate along with Session Facade because it
is easy to develop using Lightweight Session Beans like Command Pattern
than to maintain them over time
Regards
Ramesh Kesavanarayanan
* [EMAIL PROTECTED]
-----Original Message-----
From: Dmitri Colebatch [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 12, 2002 11:08 AM
To: [EMAIL PROTECTED]
Subject: Re: Stateful Session Beans
there's no reason why the command pattern couldn't be used to hide the SFSB
from the web tier.
just have the command executor as the sfsb.... the web tier creates the
command, uses the command executor, that extracts the sfsb from the session,
and passes the command to it for execution.
hth
dim
----- Original Message ----- From: Ashwani Kalra
<mailto:[EMAIL PROTECTED]> To: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> Sent: Thursday, September 12, 2002 3:33
PM Subject: Re: Stateful Session Beans
Normally it is said that access to ejb should be hidden by using
business delegate, facade, service locator. But for SFSB there is no such
solution as Glenn tried to find out. This is becuase maintaining reference
to the SFSB would be difficult if we use any of therse. So SFSB is exception
?
Comment ??
Ashwani
----- Original Message ----- From: GlennODickson
<mailto:[EMAIL PROTECTED]> To: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> Sent: Thursday, September 12, 2002 10:40
AM Subject: Re: Stateful Session Beans
Thanks Juan for your comments they very much in line with
Dmitri's and it really helps
So it seems that it normal practice to store a SFSB in a
session class for the during of client's session.
So if may paint a picture here in summation in regard to my
architecture I described:
1. the user logs in and WEB Tier controller creates a SFSB
and adds this reference to the session object of the request.
2. the client and other class may references this SFSB at
any time
Therefore the SFSB is not hidden by any facade such the
CustomerService?
Glenn
----- Original Message ----- From: Juan Pablo
Lorandi <mailto:[EMAIL PROTECTED]> To: 'GlennODickson'
<mailto:[EMAIL PROTECTED]> Sent: Thursday, September 12, 2002 12:55
PM Subject: RE: Stateful Session Beans
Handles... check out javax.ejb.Handle and
javax.ejb.HomeHandle.
to get the handle of an instance i, you use
i.getHandle(); this is defined in javax.ejb.EJBObject. Section 6.5 of the
spec refers to EJBObject in a Session Bean.
Handles are serializable and network transparent.
Basically, SFSB hold state, but you need to keep
track of the reference to the SFSB... that's what the handle is for
example (in jsp):
page1.jsp:
<%
....
mySFSB s = sHome.create();
s.setUsername("jpl");
session.setAttribute("CustomerSession",
s.getHandle() ) ;
...
%>
page2.jsp
<%
....
mySFSB s = (SFSB) ((Handle)
session.getAttribute("CustomerSession")).getEJBObject();
String username = s.getUsername();
....
%>
HTH,
Juan Pablo Lorandi
Chief Software Architect
Code Foundry Ltd.
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Barberstown, Straffan, Co. Kildare, Ireland.
Tel: +353-1-6012050 Fax: +353-1-6012051
Mobile: +353-86-2157900
www.codefoundry.com <http://www.codefoundry.com/>
Disclaimer:
Opinions expressed are entirely personal and bear no
relevance to opinions held by my employer.
Code Foundry Ltd.'s opinion is that I should get
back to work.
-----Original Message-----
From: A mailing list for Enterprise JavaBeans
development [mailto:[EMAIL PROTECTED]] On Behalf Of GlennODickson
Sent: Thursday, September 12, 2002 5:37 AM
To: [EMAIL PROTECTED]
Subject: Re: Stateful Session Beans
Hey thanks for your comments I would like to ask
then:
I do have this structure :
action class(struts) <---->webTier Controller
(class) <-------> EJB Business Delegate(SLSB) <--------> Customer Service
(SLSB) <------> Customer (Entity Bean)
1. Where would be an appropriate in this structure
to place a bean that holds the customers login details and session state ?
Would you create another bean called CustomerSession (SFSB) or make the
Customer Service a SFSB?
2. How would this SFSB be referenced ? I don't
understand how the SFSB can be retrieve at some time later to use the
session details.
TIA
Glenn
----- Original Message -----
From: Kesavanarayanan, Ramesh (Cognizant)
<mailto:[EMAIL PROTECTED]> To: 'GlennODickson'
<mailto:[EMAIL PROTECTED]> Sent: Wednesday, September 11, 2002 4:58
PM Subject: RE: Stateful Session Beans
Answers in line
? Ramesh Kesavanarayanan
? [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
Anger results in delusion, delusion leads to
loss in memory,
memory loss leads to knowledge loss, If
knowledge is lost
you perish
Can anyone tell me the following about
stateful session beans ?
1. Who calls them, I am to understand that
these beans should be called by the specific client (stub-client)?
Yes if you do not have any other design
pattern like session fa�ade(SLSB) or Business Pattern
2. Can a facade call these and hide its use?
Yes obviously you can refer any design
pattern books for these.
3. Do they have to be called from the client
and if not, what are the common ways in which these are used.
Yes if you do not have any other layer
between them and the client. These are basically to hold the state of your
bean in handles. Refer mastering EJB by Ed Roman for further studies on EJB.
4. Who exactly calls these (client side apps
etc) and how I structure they use properly (according to how that are to be
used correctly!)
I do not understand your question can you
come again please.
As I said earlier refer to the book by Ed
Roman from www.theserverside.com <http://www.theserverside.com/>
This e-mail and any files transmitted with it are for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient, please contact the sender by reply e-mail and
destroy all copies of the original message.
Any unauthorised review, use, disclosure, dissemination, forwarding, printing or
copying of this email or any action taken in reliance on this e-mail is strictly
prohibited and may be unlawful.
Visit us at http://www.cognizant.com
