• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

Command pattern Vs Session Facade.

 
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What is the difference between Command pattern and Session Facade? Please correct me if I go wrong. As per my knowledge, both of them aim at reducing the number of remote calls from client and executing all the methods inside a single transaction. Moreover, command calls a SLSB to make contact to the remote server. Then whats the need to have two patterns that serve the same purpose? Anybody please elaborate.
 
ranger
Posts: 17346
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hmm. OK a Session Facade will have multiple methods for a client to call, and will basically act as a pass through to a Plain Old Java Object to do the actual work. The Command Pattern is an Object that has a "execute" method that is passed to some object, that will call the execute method on that object.

If you have a Command Object that you pass to a Session Bean, the Session Bean might only have one method in it that accepts a Command Object. This Session bean could be a facade if you wanted it to be.

They are really two different concepts. You can use the Command pattern without any EJBs. But a Session Facade, based on the name, can only be a Session EJB. If it is anything else, then it is just a Facade.

Hope that helps.

Mark
 
Ranch Hand
Posts: 1491
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can i use statefull Session Bean in the Session Facade?
 
Mark Spritzler
ranger
Posts: 17346
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by kri shan:
Can i use statefull Session Bean in the Session Facade?



Yes you can, if you want.

I have yet to find a process that I needed to have a stateful bean. I try to avoid them.

Mark
 
Ranch Hand
Posts: 1934
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Mark Spritzler:
Hmm. OK a Session Facade will have multiple methods for a client to call, and will basically act as a pass through to a Plain Old Java Object to do the actual work.

Mark



Is n't it the case that more than some times, session facade invokes other EJBs(rather than POJOs). I wanted to correct ur statement if possible.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You certainly could call other EJBs behind your facade, but make sure you have a good reason to suffer the overhead. I've done a couple systems with session bean facades to take advantage of remote access, security, transactions, bean pooling, load balancing, etc but rarely found a need to make another EJB call within the service. I use a vendor framework with a single "gateway" session bean and the rest is POJO.
 
Kishore Dandu
Ranch Hand
Posts: 1934
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Stan James:
You certainly could call other EJBs behind your facade, but make sure you have a good reason to suffer the overhead. I've done a couple systems with session bean facades to take advantage of remote access, security, transactions, bean pooling, load balancing, etc but rarely found a need to make another EJB call within the service. I use a vendor framework with a single "gateway" session bean and the rest is POJO.



Well if there are Entity beans in the system(in case) you would be calling them from your session facade right? Can't we call the local interface of the other EJB(if both reside in the same app server/jvm) so that the overheads talked here are minimal??
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I haven't worked with Entity beans but I agree you'd have to use real EJB calls to them. Yes, the local interface is quite fast. Actually the remote interface within a container is pretty darned quick nowadays and has some advantages.

I did one system with lots of beans and lots of bean-to-bean EJB calls. We got it done, stepped back and looked, and there was really no reason for anything past the first layer to be EJBs. We were all EJB novices and just did what they told us in class. That's my excuse and I'm stickin with it.

Since then I've used two versions of a vendor framework with this gateway concept - a single public component that all calls go through. They built a proprietary protocol and dispatcher with a sort of a Business Delegate and it all works pretty slick. I wouldn't recommend a big investment like that, but a smallish set of session facades and a bunch of POJOs sound good to me.
 
Mark Spritzler
ranger
Posts: 17346
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Kishore Dandu:


Well if there are Entity beans in the system(in case) you would be calling them from your session facade right? Can't we call the local interface of the other EJB(if both reside in the same app server/jvm) so that the overheads talked here are minimal??



In My Opinion, no, the session facade shouldn't call other Session Beans or Entity Beans, you POJO's can use the local interface to call them on your behalf. Again, my session facades are completely pass through, basically there is no logic in the facade, execpt getting the call, maybe a quick setup of a class or context, then passing the call to the worker POJO. If you need Entity Beans then you call them through your POJO. Since all my session facades are pass-through, calling another session bean from my session bean is extra overhead that I don't need, I just call the POJO that handles the other session bean stuff directly from my POJO that is handling the first session bean. In EJB 3.0 you will find there are no more Session or Entity beans, just POJOs.

Mark
    Bookmark Topic Watch Topic
  • New Topic