Command pattern Vs Session Facade.

[Phani Kumar]

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.

[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. 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

[kri shan]

Can i use statefull Session Bean in the Session Facade?

[Mark Spritzler]

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

[Kishore Dandu]

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.

[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.

[Kishore Dandu]

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]

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]

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