Basic Architecture

As you can see from Figure 4-1, even the so-called basic architecture can be fairly intricate .

Figure 4-1. Basic Architecture

BEA Systems do not provide the firewall and load-balancer components . They don't even explicitly recommend vendors , though their Web site does contain some fairly subtle endorsements. Feel free to use anything that works for you. Also, it is important to note that all servers participating in a cluster must use the same version of WebLogic.

Firewall ₁

You will want to have a firewall somewhere between you and the outside world. This is more or less a no-brainer and has little impact on your WebLogic configuration per se. The only thing to keep in mind is that the ports that clients use to connect to your application front end (typically 80 and 443) need to be permitted through the firewall.

Load Balancer

A load balancer is optional but recommended for multiple-server configurations. Load balancer is a generic term referring to any piece of hardware or software that distributes incoming requests among a pool of server addresses. To the client, load balancing is transparentall requests appear to be handled by the same server.

In Figure 4-2 you can see more details of what the load balancer does. Say that the firewall permits a packet destined for port 80 of IP address 216.135.241.61 to pass through. That IP/port combination is actually handled by a cluster of WebLogic servers located on the private LAN. The load balancer sits between the firewall and the servers. Its job is to intercept incoming packets relayed by the firewall and translate the external IP address of the client request into the corresponding internal IP addresses of the server machines.

Figure 4-2. Load Balancer in Action

In this example, the external IP address 216.135.241.61 is actually handled by three servers located on the private LAN, 192.168.100.1, 192.168.100.2, and 192.168.100.3. The load balancer is configured with rules associating the two sets of IPs. When incoming packets are received, it uses some algorithm ^[2] to distribute the packets among the servers. Before outgoing packets are forwarded on to the client, the load balancer changes the originating IP of the packet (which now reads 192.168.0.something) to match the IP that the client thinks it is talking to (216.135.241.61). As far as the client is concerned , it is talking to a single fast server located at 216.135.241.61.

^[2] Typically round robin , but it could be some more exotic formula that takes the capabilities of the servers into account.

Load balancing can be achieved without special hardware. All of the supported HTTP servers (HttpClusterServlet, Apache, Netscape, and IIS) can be configured to distribute traffic to WebLogic Servers in round-robin order. This method is frequently cheaper than a dedicated hardware load balancer and may be suitable for some sites. For the most part, however, this chapter will assume the use of a dedicated hardware load balancer.

Load balancers that use active cookie persistence mechanisms may cause problems if you are using HTTP session state replication. Only hardware load balancers that insert additional cookies rather than overwriting the WebLogic HTTP session cookie will work with WebLogic Server 6.1. Those that overwrite the cookie used for HTTP session state replication will leave the client session in an undetermined state that, while wild and wacky, is probably not what you want.

Load balancers that use passive cookie persistence can add an identifier (a string constant) after the session ID and delimiter. By default the offset for starting the string constant is 52 bytes plus a 1-byte delimiter . However, it is possible that the value may be something else if the ID-length in the session descriptor XML Element is set to something other than the default of 52. If so, use as an offset the new ID-length plus 1 byte for the delimiter.

Administration Server

All WebLogic clusters need an Administration server. It should not handle client requests; it exists solely to manage the working servers in the cluster.

For security reasons, the Administration server should be placed on the same subnet as the servers it manages and behind the same firewall as well.

Managed Servers: Server ₁ . . . Server _N

The configuration of the servers is the attribute that distinguishes basic architecture from multiple- tier architecture. In basic architecture, all of the content-generating tiers of the application are found on each individual server. In particular, the EJBs and JDBC method calls are not handled by dedicated servers.

The main advantage of this configuration is the simplicity of administration. All servers should be configured identically so that the load balancer can route client requests to all the available servers. A single Administration server controls the entire server pool.

The down side is that with this configuration you cannot balance the method calls to EJBs. As shown above, the EJBs are deployed on each server in the cluster and thus are available locally. The optimal invocation method in such a situation is to utilize the local resource rather than incurring additional network overhead.

However, it is possible in this configuration that individual servers may be tasked with a disproportionately expensive chunk of the EJB invocations. While handling that, they are unable to service other requests, and overall cluster performance suffers. The solution is to balance the load between clustered EJBs. However, in order to do so you must split out your EJBs onto separate servers. This configuration is called multiple-tier architecture.

Database

On the back end of most enterprise applications you will find at least one database server. By design, this service should be located in the most inaccessible portion of the network, preferably behind at least one firewall. In the configurations shown in Figures 4-1, 4-3, 4-4, and 4-5 you will note that multiple databases are shown. While clustering of your database servers is, of course, optional, it is strongly recommended for enterprise applications. If the database goes down, there is typically very little for the Web, presentation, and object tiers to do.

Figure 4-3. Multiple-tier Architecture

Figure 4-4. Proxy Architecture

Figure 4-5. Proxy Architecture with Multitier WebLogic