318 Oracle WebLogic Server 11g Administration Handbook failover support by locating the replica of a client's HTTP session when a server instance fails. Using a proxy architecture with a client-facing web tier, you can combine your presentation and object tiers into one WebLogic cluster (similar to the basic architecture). Alternatively, in addition to the web tier, you can configure two separate WebLogic clusters, one for hosting the presentation tier (servlets) and the other for hosting the object tier (EJBs). You can use the same physical machine or two separate physical machines for hosting the presentation and object tiers. How Clusters Communicate The WebLogic Server instances that make up a WebLogic cluster communicate directly with one another so as to coordinate their activities. When each server is started, it advertises that fact to all the other members of the clusters, commonly referred to as "peers." Each of the cluster members keeps track of all of the other cluster members, and they all try to ensure that they have a consistent view of which servers are up and which are not. The members of the cluster combine the cluster configuration information as well as information about the current state of the cluster to negotiate who is the backup for whom. The members of a cluster constantly monitor one another with heartbeats. They use this information to determine when the primary server for a particular piece of state has become unavailable and whether its data needs to be replicated to some other instance. Instances within a cluster communicate through IP sockets using IP unicast or IP multicast. WebLogic Server cluster members use IP sockets for communicating with other members of the cluster, such as for transferring messages and data between two applications. For example, a clustered instance uses the IP sockets for replicating HTTP session states between a primary and a