Business Delegate *is* a Facade. The Facade pattern is much more general, though - it is not at all restricted to be used as a layer between presentation and business layer, for example.
Many of the "J2EE patterns" are in fact variations and/or specializations of the original GoF patterns.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
A Facade is not a layer. Its a fake layer. Hence the name, facade. It only looks like a layer from the outside, but thats just an illusion. It has no insides but to merely relay calls onto another object.
I think we could define "layer" so Facade could be one. Or not.
The intent of Facade is to provide a unified and simplified API to a set of, well, less simple objects. My best experience with it was when we had several teams building components in parallel. When I needed a new API from the Contract team they could put a new method on their Facade and make it return some canned value that I could test with in minutes. Then they could huddle and design a real implementation at their leisure. I never had to see all the little implementation objects they had inside their component.
The intent of Business Delegate is to hide all the complexity of remote calls. They often double up as service locators. If I build an EJB server I can give clients a POJO delegate that they can call like any other object without knowing a thing about EJB remote calls. I use a vendor product with business delegates with multiple protocol implementations - local calls, remote EJB, proprietary raw socket protocol, XML/HTTP, etc.
Both are focused on making life easier for clients. If you write all the code from end to end that may not seem important. If you publish an API for everyone in the Enterprise to call, ease of ouse may make or break acceptance.
They're just good OO stuff some times, too. I would not be surprised if the "information hiding" value could make either or both worth while in many systems, even if I write the whole thing solo.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
I agree completely with Stan. Just a couple of my own thoughts to expand on this (please tell me if you disagree).
Facade presents a simplifed view of a subsystem. It does not have to expose all of the subsystem, and clients can still access the subsystem directly if they desire. The common way people think of Facades (in J2EE anyway) is a session bean.
Business delegate protects a client from aspects of the system that are not business logic, eg the remoteness of a session bean. This makes the business delegate a client side pattern. In terms of implementation it may well look very similar to the thing it is protecting the client from, but may layer in other services such as caching.