Business Delegate/Session Facade fitting into an MVC application

If you have an application in which you've decided to use an MVC
design can anyone tell me how Business Delegate and Session Facade patterns
fit into this?

The Session Facade would fall in the Model's realm. The Front Controller would use the Business Delegate to call the Model. But from the Controller's point of view, the business delegate represents the model. So a typical call path would be (Servlet->Business Delegate->Session Facade), or (ActionHandler(Struts, Portlet, JSF Action Handler,Page Controller)->Business Delegate->Session Facade.

Barry, each of the patterns is used to hide details about how certain things are done. The Business Delegate is useful to hide how you are getting things done, for example how you are communicating with the server.
In my application, I use web services as well as RMI, depending on what I need to get. The business delegate simply provides a consistant face and throws only application specific errors and not things like RemoteException or SQLException. One call to a delegate might use RMI, the other might use a web service, and a 3rd might use a servlet.
With the Session Facade, the idea is to hide the database structure as well as the fact that you are using one or more entity beans. All of your business logic is handled at this layer. This is a great way to wrap groups that need to exist under the same database transaction, etc.
Hopefully this helps.
Regards,
Paul

Thanks. One other thing I didn't mention. The view portion of the application is java swing rather than web based (JSP, etc). I assume the
Business Delegate would reside where the client does?
Also, does this mean that the Business Delegate acts as the Controller in
the MVC design, or does the Controller reference the Business Delegate?
Thanks alot.

The view portion of the application is java swing rather than web based (JSP, etc). I assume the
Business Delegate would reside where the client does?
Also, does this mean that the Business Delegate acts as the Controller in
the MVC design, or does the Controller reference the Business Delegate?

Yes. The Business Delegate would reside on the client side and hide all of the communication marshal/unmarshal details. I look at the delegate a more of the model portion and the controller references the delegate.
Paul

Should the Business Delegate interface with an EJBHomeFactory object to
encapsulate home lookup logic?
Thanks.

Yes, the delegate will do whatever is necessary to communicate with the business logic wherever the business logic resides.
Paul

Originally posted by Barry Brashear:
Should the Business Delegate interface with an EJBHomeFactory object to
encapsulate home lookup logic?
Thanks.

Hi,
you can make your BD interface with a EJBHomeCache or ServiceLocator. The business delegate hides the complexity of talking to a remote object and the HomeCache/ServiceLocator hide the complexity of JNDI lookup and also can cache home interfaces and/or store home or component handles for your app.

A Business Delegate is something which wouldn't let you (if you are a client) bother about how complex it is to handle the request. For example, we use it in the following manner:
....
IComponentMaker componentMaker = ComponentMaker.makeComponentMaker();
IJobManager jobManager = (IJobManager)componentMaker.makeComponent("IJobManager");
//create a JobDTO and save it
jobManager.saveJob(jobDTO);
....
Now it's really the 'saveJob's responsibility to interact with the EJB stuff (which is behind the scenes). You, as a client of the BD, wouldn't bother much how all the work is going on behind the scenes. And you, as a provider of BD, will have to take all the pains to get a remote ejbobject, and talk to it (or whatever it takes to save the job).
HTH,
Kalyan.

The view portion of the application is java swing rather than web based (JSP, etc). I assume the Business Delegate would reside where the client does?

I've been working on some systems where we use the BD for client-side proxying. The Swing client invokes a business method which the local proxy takes care of by invoking a SOAP request. This request is received thousands of miles away by a web services servlet which invokes the corresponding business method on a stateless session bean. In due course, the return object is received by the proxy which passes it to the client.
Also, the proxy caches data and performs some data transformation.