2.4 Supported topologies

This topology consists of a web server, an application server, and a database server on the same node. This topology is the simplest one and must be used for development only.

This topology can be considered for production in case the load on the user interface (including the web tier) is minimal, with a small number of users.

Combining the web and application servers means that all Enterprise JavaBeans™ (EJB) look-ups are local, and therefore reduces the overhead of doing a remote look-up. Also, this topology reduces the network overhead of a round trip between the web tier and the application tier.

However, with both servers on the same node, if the web tier is compromised, both tiers are compromised. If the web tier experiences a heavy load, the application server processing is affected and vice versa. User response time is usually affected in situations when users need to wait a significant amount of time to get a page back due to all server resources (that is, CPU and/or memory) being consumed by the application server.

The simplest topology that should be considered for a production environment is a web server and combined application server with a database server. Use this topology only if you are sure that your database load will be minimal. In this scenario, the web server is providing a redirection to the application server. The advantages of this topology are low cost, low complexity, and no need for load balancing. The disadvantages of this topology are little redundancy, low scalability, inability to perform updates and upgrades, and possible low performance due to too many CPU processes.

This topology is the most common in production systems because it allows allocation of separate resources to each of the tiers. In this case, the web server acts as a proxy to the web tier on the application server that hosts the web components. This level of indirection provides additional security by securing the application server even if the web server is compromised.

You can add additional web servers for scalability and failover. When using multiple web servers, the WebLogic/WebSphere HTTP plug-in configuration file must be applied to each web server. Failure to do so after introducing a new application will likely cause a “404 File Not Found” error to occur when a user tries to access the web application.

This topology is used in most large-scale production systems where the application servers are clustered to provide high availability and, based on the topology, failover and load balancing.

Clustering application servers has these benefits:

• You can use cheaper hardware configurations and still achieve higher performance

• You can upgrade software on servers without down time

• Provides higher availability (that is, if one server fails, the other nodes in the cluster pick up the processing)

• Provides the ability to leverage load-balancing algorithms on the web server (by using load balancers) as well as on the EJB tier for processing requests

LiveCycle components are typically CPU-bound. As a result, performance gains are better achieved by adding more application servers than by adding more memory or disk space to an existing server.

Vertical scaling of multiple JVMs offers the following advantages:

Increased processing power efficiency: An instance of an application server runs in a single JVM process. However, the inherent concurrency limitations of a JVM process prevent it from fully using the memory and processing power of multi-CPU systems. Creating additional JVM processes provides multiple thread pools, each corresponding to the JVM process that is associated with each application server process. This correspondence avoids concurrency limitations and lets the application server use the full processing power of the computer.

Load balancing: Vertical scaling topologies can use the WebLogic Server or WebSphere Application Server workload management facility.

Process failover: A vertical scaling topology also provides failover support among application server cluster members. If one application server instance goes offline, the other instances on the computer continue to process client requests.