попробую по порядку.
нормально работают. распределённые приложения.
программка называется network deployment.
есть три типа обмена тем, что Вы назвали session persistent - memory, database и отдельно сессию обрабатывать на узле. далее - в мануалы
jvm конечно своя у каждого. jndi поможет
когда говорят
...кластерингом для EJB, но и его реализация в WS мне не понравилась видно что автор слегка не в теме.
резюме из этого такое - если разрабатывать J2EE приложение по всем правилам, то окажется, что для миграции на кластер или даже на другой сервер приложений нужно приложить минимум усилий. Например, SLSB в EJB идеальны для бизнес логики в кластере. Ну а если кто использует threads, пишет что-то в непонятные файлы, коннект к базе берет не из пула, и т.д. -то возможные проблемы не работы в кластере нужно искать не в особенностях этих кластеров, а в ДНК:-))

А вот схема работы в кластере BMPшек - не очень удачная, приходится все данные каждый раз (в начале каждой транзакции) загружать из базы, что очень неэффективно. Почему не сделали синхронизацию тех entity, что сидят в памяти между серверами кластера - не понятно.
не совсем понял.. Вас смущает вызов ejbLoad в жизненном цикле? Но ведь если колонка поменялась в базе, а у Вас в кэше сидит старый экземпляр, то понятно, что приложение будет работать неправильно.
Эта фраза тоже никакого отношения не имеет к вебсфере. Проблема отрасли. К примеру, на веблоджике тоже нельзя избавиться (параметр db-is-shared) в кластере. И решается она с использованием с шаблонов на основе fat key.