Business Delegate works on the "client" side of
EJB. Say I operated an EJB server and you wrote a client (a web server or perhaps a
Java Windows app) that needed one of my services. I might give you a Business Delegate class. You would call methods on that class and get the results you desired from the service. Big smiles. You could do that without ever knowing my server was EJB. The delegate hides all that plumbing stuff - getting homes, handling remote exceptions and so on - and lets you concentrate on calling business methods. If one day I decided all my services should be web services instead of remote EJB objects, I could give you a new delegate that uses the new protocol, and you'd never have to know what changed. Neat, eh?
Session Facade is another way to make life easier for those who call services by making the services look simpler. If I also wrote the business delegate, I'd be making life easier for myself. If you wrote the delegate or if there was none, I'd be making life easier for you as you write your client. Say my service was pretty complex, and executed a series of steps against a series of objects. I don't want to have to explain all that and you don't want to code all that in your client, so I put up a simple facade with a single simple method and it does all the tricky work. Once again I am allowed to make drastic changes to the workings of my service - different steps against different objects - and you don't have to know. You just keep calling the same facade and it keeps working.
So both of these
patterns hide details from you and protect you from future changes I might make. These are good choices even if one person writes the whole system. We're not hiding information from a programmer (I once had a teammate who took information hiding personally) but rather hiding information from the code the programmer writes. Of course, if my server has proprietary trade secret algorithms, I just might be hiding it from you!
Did that help?