Deciding Whether to Use a Distributed Architecture

J2EE provides outstanding support for implementing distributed architectures. The components of a distributed J2EE app can be split across multiple JVMs running on one or more physical servers. Distributed J2EE apps are based on the use of EJBs with remote interfaces, which enable the app server to conceal much of the complexity of access to and management of distributed components. However, J2EE's excellent support for distributed apps has led to the misconception that J2EE is necessarily a distributed model.

Important

This is a crucial point, as distributed apps are complex, incur significant runtime overhead, and demand design workarounds to ensure satisfactory performance.

It's often thought that a distributed model provides the only way to achieve robust, scalable apps. This is questionable. It's possible to cluster apps that collocate all their components in a single JVM. Distributed architectures deliver the following benefits:

The ability to support many clients (possibly of different types) that require a shared "middle tier" of business objects. This consideration doesn't apply to web apps, as the web container provides a middle tier.
The ability to deploy any app component on any physical server. In some apps, this is important for load balancing. (Consider a scenario when a web interface does a modest amount of work, but business objects do intensive calculations. If we use a J2EE distributed model, we can run the web interface on one or two machines while many servers run the calculating EJBs. At the price of performance of each call, which will be slowed by the overhead of remote invocation, total throughput per hardware may be improved by eliminating bottlenecks.)

However, distributed architectures give rise to many tough problems, especially:

Performance problems
Remote invocations are many times slower than local invocations.
Complexity
Distributed apps are hard to develop, debug, deploy, and maintain.
Constraints on practicing OO design
This is an important point, which we'll discuss further shortly.

Distributed apps pose many interesting challenges. Due to their complexity, much of this tutorial (and J2EE literature in general) is devoted to distributed J2EE apps. However, given a choice it's best to avoid the complexities of distributed apps by opting for a non-distributed solution.

Important

In my experience, the deployment flexibility benefits of distributed apps are exaggerated. Distribution is not the only way to achieve scalable, robust apps. Most J2EE architectures using remote interfaces tend to be deployed with all components on the same servers, to avoid the performance overhead of true remote calling. This means that the complexity of a distributed app is unnecessary, since it results in no real benefit.

Previous Next

Comments