|
|
Another crucial decision for J2EE architects is how to maintain server-side state. This will determine how an app behaves in a cluster of servers (clustering is the key to scalability) and what J2EE component types we should use. It's important to decide whether or not an app requires server-side state. Maintaining server-side state isn't a problem when an app runs on a single server, but when an app must scale by running in a cluster, server-side state must be replicated between servers in the cluster to allow failover and to avoid the problem of server affinity (in which a client becomes tied to a particular server). Good app servers provide sophisticated replication services, but this inevitably affects performance and scalability. If we do require server-side state, we should minimize the amount we hold.
| Important |
apps that do not maintain server-side state are more scalable than apps that do, and simpler to deploy in a clustered environment. |
If an app needs to maintain server-side state, we need to choose where to keep it. This depends partly on the kind of state that must be held: user interface state (such as the state of a user session in a web app), business object state, or both. Distributed EJB solutions produce maximum scalability with stateless session beans, regardless of the state held in the web tier.
J2EE provides two standard options for state management in web apps: HTTP session objects managed by the web container; and stateful session EJBs. Standalone clients must rely on stateful session beans if they need central state management, which is another reason why they are best supported by EJB architectures. Surprisingly, stateful session EJBs are not necessarily the more robust of the two options (we discuss this in ) and the need for state management does not necessarily indicate the use of EJB.
|
|