And then, you could wrap your SLSB (stateless session bean) with a JavaBean.
Reminds me of the Turduken - a chicken stuffed in a duck, stuffed in a turkey. Popular in the American south.
I'm not a huge fan of a one to one wrapping. Perhaps the SLSB manages some aspect of the life of the entity bean?
One possibility is to handle all transactional stuff, such as interacting with multiple EJBs, in the SLSB. Also, you can make the SLSB remote, and make it available to distributed clients. Slap some security on it to. Then only expose the entity with a local interface. Now, that's a recipe I'm starting to like.
Check it out the 'Session Fa�ade' pattern, together with the 'Business Delegate' and 'Service Locator' patterns. Could be useful for understanding why abstract some Entity Bean behind a SLSB, and why abstract the SLSB from the client tier.
Just a tip: Remember that Entity Beans run more faster and better with local interfaces. And to provide location transparence, you should abstract those local interfaces object wrapping it with remote interfaces (SLSB).
Cameron, To be more concrete, I'm talking here about an architecture where I have 1 SFSB as session facade talking to business services implemented as SLSBs that in turn manage functions, such as login, account management, orders, etc. respectively. The SFSB Session Facade holds the session data and passes it on to the SLSBs, which in turn operate of entity beans. It is a general architecture, and in certain cases, such as logon management, these slsb-s are acting on a single entity bean. Do you still think it's a bad idea?
Ricardo, Just to make it clear, in my design all ejb-s except session facade are local...
William Butler Yeats: All life is a preparation for something that probably will never happen. Unless you make it happen.
Joined: Feb 13, 2006
You're right! All yours entity beans must have local interfaces. The shortest why is related to the fact that Entity Beans must use CMR (container managed relationships) that only work inside the EJB container JVM.
Entity beans must be local too, to achieve a little bit performance feature, since the objects are passed by reference and not by copy. Since performance is essential to any enterprise application, ensure local interfaces is a good approach.
Another key to defend entity local interfaces, resides on the fact that threading and concurrency could be monitored by the ejb container must more faster and better.
All this stuff must be exposed to the client tiers (web container or swing applications, corba applications) by another ejb with remote interfaces. And SLSB are appropriated for that.
Joined: Dec 26, 2006
Ricardo, There is no contradiction here, if you read carefully my post. Your point is perfectly valid.
Joined: Nov 16, 2006
sorry to jump in guys Rich , i am just curious.when you say: >>>SFSB Session Facade holds the session data and passes it on to the SLSBs Do you think there is any advantage of having both stateful and stateless session beans to impliment session facade. we are using only stateless session beans to impliment the session facade pattern. We tend to stay away from stateful session beans because stateful sesion beans have state maintainence and scalabiltiy problems
[ December 29, 2006: Message edited by: jay roy ] [ December 29, 2006: Message edited by: jay roy ]
Joined: Jul 09, 2001
Do you think there is any advantage of having both stateful and stateless session beans to impliment session facade.
We are talking about a session fa�ade implemented as a stateful session bean, which in turn calls the proper application service class implemented as a stateless session bean.
Joined: Dec 26, 2006
Jay, Dan answered the question.
This is just one of the many approaches you may take. In case you don't feel confortable with it you can go with the petstore design. Bottom line is that you have to keep session in business tier somehow. BTW, there are tons of postings about this on this forum. In my view it's one of the most crucial design decisions for the project...
Hope it helps.
Joined: Nov 16, 2006
>>>>We are talking about a session fa�ade implemented as a stateful session bean
yes i know that and my point is we dont really need stateful session beans because it has performance issues. Stateless session beans alone will do the job. Anyway, thats my opinion and thats what i am doing in my project.
I think there are some advantages of SFSB when we have many types of client like swing,html,WAP etc. In that case one request basis only the string representation of the SFSB will be passed to and fro but the session mangement is done at the server side and we do not need to maintain other attributes like username,cart etc at the client side.
SFSB has some overhead but I think this can be justified by the over head of writting custom code for maintaining session