I see one role of business delegate as hiding complexity from the client. Say I'm coding an EJB server and you're coding a Servlet client. Without the delegate I'd have to explain EJB home finders and caching homes and remote exceptions and all kinds of stuff. With the delegate, I just give you a jar and say you can use the java classes in that jar and they'll do all the tricky bits. If you aleady know all that stuff and you're willing to do the code to use them the delegate has a less value for making your life easy.
But it still has value as an abstraction. Without the delegate, if I change my server from EJB protocol to web services or REST protocols you would have to change every reference to my server. With the delegate, I could just give you a new jar and you'd never know what changed.
I work with a vendor product that generates business delegates from
Rose models. The client code has no idea they're dealing with an EJB server. In fact the delegates appear to the client to be identical to a previous release of the product that used sockets to talk to a Forte 4GL server.
For these benefits I don't think "business delegate" was a very good name. It looks more like some kinda abstract remote proxy thingy to me.
Oh, and regarding session facades ... business delegate simplifies and abstracts technical stuff about the protocol while a facade simplifies and abstracts the application objects and methods a client can see. You could surely use both - a business delegate to make it easy to code calls to a session facade.
[ January 18, 2005: Message edited by: Stan James ]