As far as the front end tier goes, keep an eye on the session
variables, as they need to be serializable to be replicated across
managed servers in a cluster, and context parameters - for there is 1
servlet context per JVM per webapp.

-cheers,
Manish

If you application is a simple web application with no EJBs, JMS etc
then clustering should be relatively straightforward.

Essentially, you are concerned with the replication of HTTP sessions so
that if a user is served by a different server on each request, their
session information is available. You may also need to cluster your
database, but this is not a Java topic and I will consider it out of scope.

Somebody has already mentioned that any objects placed into the HTTP
session should be serializable, this will allow your application server
to stream the session data across your cluster.

It is also a good idea to keep session data light, when working in a
single node deployment it is very easy to 'abuse' the session by placing
lots of data there, but in a cluster, all this data will need to be
replicated so if you have megs of data in the session find a way to cut
this down.

On the whole, web application clustering is easy enough, when you get to
a point where you have state in other tiers it becomes much trickier.