Well, the idea of the Proxy pattern is that you have an object that stays in front of another object and has the same interface as this object. So, if some operation has to be performed before another operation, you can make use of a proxy, to abstract the caller and simplify its code. For example, we have an object that has a getter method that retrieves a list of Strings, but we have to go to the database to retrieve this list. If there's a proxy, the caller simply invokes this getter method on the proxy object, and the proxy verifies whether the target object already has the list. If not, it goes to the database, retrieves the list, sets it on the target object and returns to the caller. Therefore, the proxy object can execute code before and after the code of the actual targeted object.
The original idea of the Business Delegate was to abstract the presentation layer from knowing how to look
EJB objects up. The presentation layer (i.e. a
Servlet) would have to know how to retrieve EJB objects that would execute business logic. You could then make use of a Business Delegate, so the Servlet could simply invoke a method on it, which would then retrieve the appropriate EJB object and delegate the execution of the business logic to it, simplifying the code of the presentation layer.
I have to confess that I have worked 95% of the time with Spring, but I believe that the Business Delegate pattern is retired nowadays. And yes, both patterns delegate the execution of things to other objects, but their purpose are different.
