wood burning stoves 2.0*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Entity beans wrapped by Session beans Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Entity beans wrapped by Session beans" Watch "Entity beans wrapped by Session beans" New topic
Author

Entity beans wrapped by Session beans

Rich Veress
Greenhorn

Joined: Dec 26, 2006
Posts: 8
Hello Ranchers,
How does it sound wrapping entity beans such as Customer with stateless session beans to return TOs to session facade?

thanks in advance.
Rich
jay roy
Ranch Hand

Joined: Nov 16, 2006
Posts: 145
it is always a good idea to expose a session facade(stateless session bean) and hide your entity beans behind the session facade.

so i think its a good idea.

J
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968
    
    1

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.

-Cameron McKenzie
Ricardo Ferreira
Ranch Hand

Joined: Feb 13, 2006
Posts: 156
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).

Best Regards,


Ricardo Ferreira,<br /> <br />Sun Certified Enterprise Architect<br />IBM Certified SOA Solution Designer<br />IBM Certified RUP v7.0 Solution Designer<br />IBM Certified Specialist for RUP v2003
Rich Veress
Greenhorn

Joined: Dec 26, 2006
Posts: 8
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...

thanks,
/R
[ December 28, 2006: Message edited by: Rich Veress ]
Dan Drillich
Ranch Hand

Joined: Jul 09, 2001
Posts: 1169
Rich,

That's exactly the way I'm doing it.

Regards,
Dan


William Butler Yeats: All life is a preparation for something that probably will never happen. Unless you make it happen.
Ricardo Ferreira
Ranch Hand

Joined: Feb 13, 2006
Posts: 156
Hi Rich,

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.

Ok ?
Rich Veress
Greenhorn

Joined: Dec 26, 2006
Posts: 8
Ricardo,
There is no contradiction here, if you read carefully my post. Your point is perfectly valid.

thanks,
Rich
jay roy
Ranch Hand

Joined: Nov 16, 2006
Posts: 145
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 ]
Dan Drillich
Ranch Hand

Joined: Jul 09, 2001
Posts: 1169
Jay,

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.

Regards,
Dan
Rich Veress
Greenhorn

Joined: Dec 26, 2006
Posts: 8
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.

Rich
jay roy
Ranch Hand

Joined: Nov 16, 2006
Posts: 145
>>>>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.

thanks guys
J
saurabh suman
Greenhorn

Joined: Nov 01, 2006
Posts: 16
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


Sun Certified Enterprise Architect<br />Saurabh
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Entity beans wrapped by Session beans
 
Similar Threads
Pooling vs Instance Caches
Create method in entity and session bean
CMP vs BMP
Does SessionBeans act as Command Pattern
JNDI Lookup