Service Locator is the superior pattern. First of all, unlike the Business Delegate, one Service Locator instance can support an entire application tier.

That’s true, but Service Locator needs to talk to only one remote entity. Business Delegate must handle many entity objects.

Service Locator is more efficient with network calls. It can cache references to stubs or service stubs once it has located them, reducing network traffic for subsequent calls.

With much respect, you are forgetting that Service Locator has a much easier task. The Business Delegate must carry the heavy burden of communicating with a dynamic object, whose data might change at any moment.

Heavy burden? Your simple business data does not impress me.

A Business Delegate gives web application programmers much more benefit than your Service Locator.

Ah, maybe programmers do benefit, but your simple pattern seems to forget that it often exists in a network environment. It will make many calls to business services with no restraint, no consideration for the overhead of remote calls.

Ah ha! The Business Delegate is not ashamed to form an alliance with the Transfer Object! Working as a team, they help the programmer AND minimize remote calls.

Yes, yes, your weak pattern needs assistance, we all know that. But when you partner with a Transfer Object other demons can haunt you... you haven’t forgotten your little problems with data staleness and concurrency, have you?

No, I haven’t forgotten. But when these issues come up they can be solved. You cannot expect to achieve great things without a little extra effort... nothing in J2EE is ever black and white.