In the old J2EE architecture, both remote and local business services, such as EJB, use a service locator mechanism. However, dependency injection is now used to access local EJBs (and the option for local services is increasingly being used). In many cases, using a Business Delegate to look for local services has become somewhat obsolete for this reason. Consequently, someone could question the use of a pattern, such as Business Delegate, only to handle remote communications. This is because, since JEE5, we have begun to use DI annotations to reference local EJB with ease. However, if we think of a Business Delegate as a bridge for Session Bean EJBs, for example, then we can change these EJBs (when necessary) without having to worry about whether or not the presentation tier will be broken. If something changes in the session EJB, it is the Business Delegate's job to handle this change and keep the presentation tier intact.

The following diagram shows the classic architecture of an application:

In some situations, this architecture was replaced by others, as shown in the following diagrams:

Looking at the two previous alternatives, we can see the way in which Business Delegate can be used when there is a need to change the business service layer. This can be done without impacting the presentation layer. In addition, when we need to handle business-service exceptions and we have a client other than a web browser, we can use a Business Delegate with a lookup mechanism (JNDI) for the business services (EJBs).

There are several other architectures that can be used in application building. We will see that the use of the Business Delegate pattern occurs along with some other patterns, especially the Session Façade pattern, as shown in the diagrams. Another common pattern is the business-object pattern, which represents a real-world business object with properties and methods, not necessarily getter and setter methods.